Circulation


Home Prev	Chapter 12. 3.2.0 New Features	Next

Autorenewal of Loans

Circulation policies in Evergreen can now be configured to automatically renew certain items checked out on patron accounts. Circulations will be renewed automatically up to a custom limit (the max_auto_renewal field) and patrons will not need to log in to their OPAC accounts or ask library staff to manually renew materials.

Two new action triggers have been added to Evergreen that permit the Auto-Renew feature. They can be found, configured, and enabled in Administration>Local Administration>Notifications/Action Triggers. They are named Autorenew and AutorenewNotify.

The Autorenew A/T definition uses the checkout.due hook to automatically validate and renew (in the reactor) circulations on the day they are due, grouped by user. The output events of this definition is is the input used by the related AutorenewNotify A/T that simply uses a new hook called autorenewal to notify patrons via email of their currently due or auto-renewed items.

In the webstaff’s Patron Items Out page, the new column AutoRenewalsRemaining indicates how many autorenewals are available for a particular circulation.

Emergency Closing Handler

Staff are provided with interfaces and mechanisms to create library closings that, in addition to affecting future circulation and booking due dates, and hold shelf expirations, will automatically move existing circulation and booking due dates and hold shelf expiration times. This new functionality is conceptually described as Emergency Closings and business logic implementing it as the Emergency Closing Handler. It contains additions and adjustments to the user interface, business logic, and database layers. Access to this functionality is available through the Closed Dates Editor interface in the staff client which has been ported to AngularJS.

Overview

This development has created new business logic code to inspect, in real time, existing circulation, booking, and hold records, and modify such date and time stamps so that the circulation, booking, or hold will end in the same state it would have if the closing had existed at the time the circulation or booking occurred, or the hold was placed and captured. Of specific note, hourly loans will have their due date adjusted to be the end of the day following the closing.

When the Emergency Closing is saved, any fines accrued during the closing may be voided, as settings dictate, with the exception of circulations that have been marked as LOST or LONG OVERDUE. That is, even for LOST and LONG OVERDUE circulations with due dates that fall within the Emergency Closing, no fine adjustment will be applied. Emergency Closing processing is permanent, and cannot be rolled back.

This functionality is explicitly initiated by staff action. If staff do not request an Emergency Closing, existing circulations, bookings, and holds will not be processed and adjusted. However, if staff request any Closing that starts nearer in time than the length of the longest circulation duration configured for use in the Evergreen instance they will be prompted with the option to create the closing as an Emergency Closing.

Action/Trigger hooks have been created for circulations and bookings that are adjusted by the Emergency Closing Handler. These will facilitate the creation of notifications to patrons that the due date has changed and to alert them to potential changes in accrued fines.

Booking start dates are explicitly ignored in this implementation. Because an Emergency Closing is, by its nature, an unexpected event, it will be up to staff to address any bookings which intersect with a new Emergency Closings. Reports can be used to identify booking start dates that overlap with a closing and that may require staff intervention.

Staff requesting and Emergency Closing must have the new EMERGENCY_CLOSING permission. Some text describing the feature.

Patron Preferred Name and Name Search Keywords

Preferred Name

Adds a new set of patron preferred name fields for prefix, first, middle, last, and suffix allowing patrons to provide preferred name information. Preferred names are optional and each acts as an overlay to the analogous primary name field, making it possible to provide preferred name values for individual fields.

For example, a patron named William Erickson may have a preferred first name (pref_first_given_name) of Bill, in which case the preferred name would be Bill Erickson. Note a preferred last name is not required in this case as the code uses primary name values as defaults when not replaced with a preferred version.

Patrons will see primary names displayed in the catalog when set.
Staff will see both primary name and preferred name in the patron summary side bar.
Patron searches for any given name field will search both the primary and preferred name data.
Preferred name fields are available in Action/Trigger templates and are present in various patron-focused print templates.

Name Keywords

Adds a new field to store miscellaneous patron name search terms. These values are only for searching and do not appear in any interfaces, apart from the patron summary side bar and the patron edit UI.

Included is a new search field in the patron search UI which searches keyword values and all other name fields. It’s essentially a global patron name keyword search.