Batch Editing of Patron Records

There is a now a new interface analogous to the Copy Bucket interface to select and group a set of users into a User Bucket. The addition of users to a User Bucket is possible from the Patron Search interface by the use of a new grid Action, and directly on the User Bucket interface by user barcode. It is also possible to add users to a User Bucket by uploading a text file that contains a list of user barcodes.

From this interface it is possible to perform a set of specific batch update operations on user records.

Editing Users

These fields can now be changed in batch via an action on the User Bucket grid if the staff user has the UPDATE_USER permission:

  • Active flag
  • Primary Permission Group (group application permissions consulted)
  • Juvenile flag
  • Home Library (UPDATE_USER checked against both old and new value)
  • Privilege Expiration Date
  • Barred flag (BAR_PATRON permission consulted)
  • Internet Access Level

Changes made in this interface can be rolled back.

As a batch process, rather than a direct edit, this mechanism explicitly skips processing of Action/Trigger event definitions for user update.

Deleting Users

The batch edit mechanism also allows for the batch deletion of user. The staff user must have both the UPDATE_USER and DELETE_USER permissions.

Changes made in this interface can be rolled back.

As a batch process, rather than a direct edit, this mechanism explicitly skips processing of Action/Trigger event definitions for user deletion.

This mechanism does not use the Purge User functionality, but instead simply marks the users as deleted.

Editing Statistical Category Entries

All users in the bucket can have their Statistical Category Entries modified. Unlike user data field updates, modification of Statistical Category Entries is permanent and cannot be rolled back.

As a batch process, rather than a direct edit, this mechanism explicitly skips processing of Action/Trigger event definitions for user update.

New Service Requirement

This new functionality makes use of the QStore service (open-ils.qstore), which was previously unused in production. If this service has been removed from the configuration of a live Evergreen instances, it will need to be added back in order for batch user editing to succeed.

Honor Timezone of the Acting Library


  • Display day-granular due dates in the circulating library’s timezone.
  • Only display the date portion of the due date for day-granular circulations.
  • Display the full timestamp, in the client’s timezone rather than the circulation library’s, for hourly circulations.
  • Provide infrastructure for more advanced formatting of timestamps.
  • Override the built-in AngularJS date filter with an implementation that uses moment.js, providing consistency and better standards compliance.


This is a followup to the work done for 2.12, where we added the ability for the client to specify a timezone in which timestamps should be interpreted in business logic and the database.

Most specifically, this work focuses on circulation due dates and the closed date editor. Due dates, where displayed using stock templates (including receipt templates) and used for fine calculation, are now manipulated in the library’s configured timezone. This is controlled by the new lib.timezone setting available via the Library Settings Editor, loaded from the server when required. Additionally, closings are recorded in the library’s timezone so that due date calculation is more accurate. The closed date editor is also taught how to display closings in the closed library’s timezone. Closed date entries also explicitly record if they are a full day closing, or a multi-day closing. This significantly simplifies the editor, and may be useful in other contexts.

To accomplish this, we use the moment.js library and the moment-timezone addon. This is necessary because the stock AngularJS date filter does not understand locale-aware timezone values, which are required to support DST. A simple mapper translates the differences in format values from AngularJS date to moment.js.

Of special note are a set of new filters used for formatting timestamps under certain circumstances. The new egOrgDateInContext, egOrgDate, and egDueDate filters provide the functionality, and autogrid is enhanced to make use of these where applicable. egGrid and egGridField are also taught to accept default and field-specific options for applying date filters. These filters may be useful in other or related contexts.

The egDueDate filter, used for all existing displays of due date via Angular code, intentionally interprets timestamps in two different ways WRT timezone, based on the circulation duration. If the duration is day-granular (that is, the number of seconds in the duration is divisible by 86,400, or 24 hours worth of seconds) then the date is interpreted as being in the circulation library’s timezone. If it is an hourly loan (any duration that does not meet the day-granular criterium) then it is instead displayed in the client’s timezone, just as all other timestamps currently are, because of the previous Evergreen timezone work.

The public catalog is adjusted to always display the due date in the circulating library’s timezone. Because the public catalog displays only the date portion of the due date field, this difference is currently considered acceptable. If this proves to be a problem in the future, a minor adjustment can be made to match the egDueDate filter logic.

Now that due dates are globally stored in the configured timezone of the circulating library, the automatic adjustment to day-granular due dates needs to take those timezones into account.

An optional SQL command is provided by the upgrade script to retroactively adjust existing due dates after library configuration is complete.

Enhancements to Hard Due Date Functionality

It will now be possible to delete Hard Due Date Values for dates that have passed. Also, the Hard Due Date updater will no longer change Ceiling Dates to a past date. This allows editing Ceiling Dates directly in a Hard Due Date as well as scheduling Ceiling Date changes via Hard Due Date Values.

Patron Search by Birth Date

  • Now you can include the patron birth year and/or birth month and/or birth day when searching for patrons using the web staff client.
  • Day and month values are exact matches. E.g. month "1" (or "01") matches January, "12" matches December.
  • Year searches are "contains" searches. E.g. year "15" matches 2015, 1915, 1599, etc. For exact matches use the full 4-digit year.

Patron Search from Place Hold

This feature allows staff members, when placing a hold on behalf of a patron in the web staff client, to search for patrons by names and other searchable patron information, rather than relying on barcode alone. In particular, after performing a catalog search or going to a specific bib record and clicking the Place Hold button, the form now includes a Patron Search button. This button will open a dialog allowing the staff member search for and select a patron record.

Retrieve Recent Patrons

Adds a new library setting Number of Retrievable Recent Patrons (ui.staff.max_recent_patrons) that specifies the number of recently retrieved patrons that can be re-fetched from the staff client.

A value of 0 means no recent patrons can be retrieved. A value greater than 1 means staff will be able to retrieve multiple recent patrons via a new Circulation Retrieve Recent Patrons menu entry.

The default value is 1 for backwards compatibility.

Fuller title in XUL client Simplified Pull List

The Simplified Pull List in the XUL client will now display subfields 245$n and $p in the title field. The addition will make it easier for staff to distinguish between different parts or seasons in a series.

Transit Cancel Time and Terminology Change

Transit Cancel Time

Previously, Evergreen deleted canceled (aborted) transits from the database. Now the rows in action.transit_copy, action.hold_transit_copy, and action.reservation_transit_copy are preserved in the database, though still not visible to the end user in the staff client. This allows for better tracking of when transits are canceled for the purposes of knowing which staff member canceled the transit, etc.


This change may require the re-creation of transit reports to filter out canceled transits from the results. Cloning the template and adding a Base Filter of Cancel Time Is NULL will suffice.

"Canceled Transit" Terminology Change

The term "abort" has been replaced with "cancel" in all of the affected user interfaces. For internal continuity, however, the following permission codes have not changed: