 |   | |
| HomePrev | Chapter 18. 3.0.0 New Features | Next |
|---|
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.
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:
UPDATE_USER checked against both old and new value)
BAR_PATRON permission consulted)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
To report a problem with this documentation or provide feedback, please contact the DIG mailing list.
© 2008-2015 GPLS and others. The Evergreen Project is a member of the Software Freedom Conservancy.
