ReShare 1.9 release notes
Release date: August 2, 2022
Summary: This release includes one new features, several enhancements and a number of non-functional changes to improve database integrity and prevent message timeouts.
New features
Horizon Host LMS adapter - Z39.50 integration
ILS integration with Horizon via Z39.50 is now available allowing the auto-responder to do real time availability checks for material held at institutions using Horizon for their ILS.
Enhancements
Temporary item barcodes for multi-volume requests shortened
When multi-volume requests are received in ReShare, the temporary item barcode assigned to the items being received were a combination of the request number + the supplier’s item barcode. The combination of these two elements created a barcode that was too long for many ILSs to accept via the AcceptItem message when the brief item(s) are created in their system. Temporary item barcodes for multi-volume requests are now a combination of the request number + the last 4 digits of the supplier’s item barcode.
Updated column
An ‘Updated’ column has been added to the list of requests in the Request app to allow staff to sort on recently processed requests.
Prevent users from accidentally creating duplicate root entries in Directory
Each tenant should have one root institution entry in Directory, and all branches should be children of that entry. To prevent the accidental creation of a duplicate consortia or root entry in the Directory, a warning message will appear when a duplicate consortium or root entry is created to allow the user to back out of the process before committing it to the database.
Ability to retry sending a failed ISO18626 message
If ReShare fails to send a message, there will be the ability to retry sending the request before the request is moved on to the next rota location or end of rota. Note: While the request is in retry mode, users will be blocked from performing any actions on the request.
Verify whether a received ISO18626 message is for the current lender
Prior to release 1.9 when an incoming ISO18626 message was received for a request there was no check that it was for the current lender. This could be problematic if the request was moved on in the rota and an earlier lender in the rota responded. That could cause a problem with the status of the request, as the state of the request is in relation with the current responder not an earlier responder. Now ReShare will verify that the message received is for the current lender and if not the message will be rejected.
Verify whether an ISO18626 message has been received if a timeout occurs
If a timeout is returned when sending an ISO18626 message, ReShare will attempt to verify whether the message has been received or not. This prevents the request message from moving on to the next location in the rota when in actual fact a responder may have already been assigned who can supply or who has already supplied the material.
Validate the incoming status of an ISO18626 message
When an ISO18626 message is received (which indicates the state to set the request to) its state will be validated and the request’s state will only be updated if makes sense in the flow of the request.
Non-functional changes
UI updated to use react-intl
The {{@folio/react-intl-safe-html}} package used in the ReShare user interface (UI) has been removed and its functionality is now provided by react-intl and the configuration of same in stripes-core.
Address plug-in build refactored
The underlying plug-in used in managing address information in Directory has been refactored to:
Move all to single monorepo
Build each module as a public npm under the k-int namespace
Tweak ReShare build dependencies to use these new modules
Clean up code as you go – refactor to functional components and make use of Hooks and better knowledge of Final Form
Operated as a Community Resource by the Open Library Foundation