Release date: June 7, 2023
Summary: This release includes three new features, two enhancements, a few bug fixes and a number of non-functional changes.
New features
Major overhaul of pull slip functionality
Pull slips are now generated from a Jasper Report .jrxml file in ReShare. A default pullslip.jrxml file will be provided upon upgrade to release 1.12 that will replace the current hard-coded pull slip in ReShare.
The existing pull slip generation from the Supply app now calls an endpoint to get a PDF of the pull slip(s).
Staff can save the pull slip(s) prior to printing.
Staff will need to explicitly click “Mark pull slips printed” when generating pull slip(s) for printing, in order to have their state updated from “Awaiting pull slip printing” to “Searching”.
ReShare users would like the ability to have their pull slips batched together and emailed to them as a PDF, to be printed from that PDF without having to log into ReShare to do that.
Added a flag “Attach PDF” to the pull slip notification table to allow staff to indicate that they wish to have the pull slips attached to the email notification as a PDF, rather than simply including a link to those requests in the ReShare UI.
If “Attach PDF” is enabled for a pull slip notification, the pull slips in the batch will automatically have their state updated from “Awaiting pull slip printing” to “Searching”. This will allow staff to print their pull slips from the email notification directly. When they next sign into ReShare, they will be in a position to directly fill the request when they call it up.
A maximum of 100 pull slips can be created in one batch. If a pull slip notification contains greater than 100 pull slips, multiple emails will be sent. The email subject line will clearly indicate this, e.g. You have 104 new ReShare pull slips - requests 1-100, You have 104 new ReShare pull slips - requests 101-104.
ReShare users would like the ability to customize their pull slips and configure their ReShare systems to use their customized pull slip
A new “Pull slip configuration” setting has been added to Settings>Resource Sharing
In the Pull slip configuration setting, tenants can upload a different logo to use on their pull slips.
Note: the default logo for the consortium will be uploaded at upgrade time and staff do not have to update this setting.
In the Pull slip configuration setting, tenants can upload a custom pull slip .jrxml file to generate a different pull slip from the default.
Note: the default pullslip.jrxml for the consortium will be uploaded at upgrade time and staff do not have to update this setting.
A new “Batch” filter has been added to the Supply and Request app to allow staff to call up and reprint a batch of pull slips.
ReShare now stores the batch ID, description and date when a batch of pull slips was produced, in both the supplier and requester apps, respectively. Staff can use the Batch filter to call up a given batch and reprint one or more of the pull slips, if needed.
FOLIO temporary location now analyzed for requestability by the autoresponder
If a value is returned in the temporary location field in the z39.50 response from FOLIO, this location will now be analyzed for requestability by the autoresponder.
Note that the first time a new temporary location is encountered by the autoresponder, the system will allow requests to be placed against it. If the temporary location added to the Host LMS shelving location table in Settings > Resource Sharing is not requestable, please update the entry to set its Supplying priority to -1.
Voyager API calls Voyager system to pull item barcode to replace itemId
The Voyager ILS system returns the actual item ID in the item ID field returned in the z39.50 response instead of the item barcode. Calling the Voyager API first allows ReShare to pull back the actual item barcode for the selected item being requested and replace the item ID with this barcode.
Enhancements/Improvements
Manual editing of pickup location does not reflect updates on either the requester or supplier side
If staff updated the pickup location assigned to a request via the staff tenant, the change was not reflected in the request data for either the requester or the supplier. The request data is now updated to reflect the addition or update to the pickup location field.
New ‘Updated’ column displays in the Supply app list of requests
The date updated column now displays in the Supply app list of requests, allowing staff to sort on this column like they can do in the Request app.
Bug Fixes
Corrected issue with supplierUniqueRecordId not being populated for local requests
The value for supplierUniqueRecordId is assigned in logic that does not get reached if the request is flagged as going to local review. This is causing lookup by id to fail in these cases. This has been corrected.
'Is active' value is not displaying in the list of pull slip notifications
The ‘Is active’ field does not display a value in the list of pull slip notifications in Settings > Resource Sharing > Pull slip notifications, making it difficult to see which ones are or are not active. This has been corrected to display the check mark for active pull slip notifications.
When staff click the action “Redo borrower check” even if the check fails again, they are told that it was successful
If the validation of a patron fails, the request is put into a state of “Invalid patron”. If staff use the action “Redo borrower check” and the check fails again, they are currently being presented with a confirmation that the check was successful. This has been corrected to display the proper response.
The action “Override borrower check” is not working in release 1.11.1
With the Borrower Check = NCIP turned on in Host LMS integration settings, if a request was initially in a state of “Invalid patron” and staff use the “Override borrower check” to override the check, the system returns a “Success: Override borrower check” message but the action is NOT actually successful. The request stays at a state of “Invalid patron” when it should move on to the next state. This has been corrected to move the request to the next state.
Non-functional changes
Completed the changes required to support different state models within ReShare. (This will enable ReShare to support non-returnables and Controlled Digital Lending workflows in future releases.)
Upgraded stripes and other UI dependencies
GenerateRequestsByState had been duplicated in the StatisticsController and ExternalApiController. It has been moved to a shared location so if a bug occurs it will be fixed in both.
The mod-rs rs/directoryEntry API now returns a complete directory entry that matches the format returned by the mod-directory /directory/entry API
Extended logging so that it outputs the information in a structured format
Added an endpoint to allow dynamically changing of the log level
0 Comments