Release date: August 29, 2022
Summary: This release includes four new features, six enhancements, several bug fixes and a number of non-functional changes to improve database integrity and the rolling out of new releases.
ILS integration with Horizon via NCIP is now available. ReShare can send and receive the following four messages with Horizon: LookUpUser, CheckoutItem, AcceptItem and CheckinItem.
In addition to an item’s location (Host LMS location) and shelving location (Host LMS shelving location), ReShare now automatically stores and validates an item’s loan policy if returned in the Z39.50 response when the “Will supply” auto responder is enabled. These item loan policies can be then managed by staff in Settings>Resource Sharing>Host LMS item loan policies. New item loan policies can also be manually created and updated by staff to indicate which item loan policy values are requestable.
The auto responder will now take into consideration the Host LMS location, Host LMS shelving location and Host LMS item loan policy (if returned in the Z39.50 response) when determining if an item is requestable when assigning the request to a supplier. If no item loan policy is returned in the z39.50 response, then the item will be considered requestable.
A new action titled 'Undo last action performed' will display in the Supply app when a request is filled and the state of the request is changed to 'Awaiting shipping'. This will allow staff to undo the action if they scanned in the wrong barcode for the item. If the supplying library has NCIP Check In Item message turned on, an NCIP Check In Item message will be sent when the Undo last action is performed.
Note: If a tenant has the ‘“Combine supplier actions ‘fill request' and 'mark shipped’ '' set, the ability to undo a filled request is not possible. Once the request changes to a state of 'Shipped' the ISO18626 protocol does not support the sending an undo message to the requester.
The foundation to support the storage of external request IDs is now in place. With Release 1.10, ReShare can now ingest, store and search on ILLiad TNs when requests are passed into ReShare from ILLiad.
If a request is sent to ReShare from an external system, the external ID associated with the request will be displayed in the Detail screen of the request in the Request information section.
Users will be able to search and filter on External ID or External ID source when searching for requests in the Request app.
If set to ‘Yes', the combined actions “Combine supplier actions 'fill request' and 'mark shipped' “ and “Combine requester actions 'mark returned by patron' and 'mark return shipped’ '' will appear as options in the Update app. Previously they only appeared in the Supply or Request app to be applied on a request by request basis.
New notice policies and templates have been created to allow tenants to set up an email notice when a new Host LMS location and/or new Host LMS shelving location is added to the system. This will allow staff to be aware of when new locations are added to their tenant configuration and allow then to quickly go in and manage whether the newly added location is requestable or not.
With the ability to track/store the shelving location associated with a request in release 1.8, a new filter has been added to the Supply app to allow staff to filter the list of requests by shelving location.
A new sortable column for Shelving location has been added to the right of the Location column in the Supply app. This will allow staff to see the shelving location associated with a request and be able to sort on this column if needed.
Prior to release 1.10, the item barcode associated with a request was only stored and displayed on the pull slip once the lending library filled the request. Now the item barcode (returned with the location from which the item is expected to be filled) will be stored and displayed on the pull slip before the request is filled. This will improve the ability to find items in a closed or remote stack environment.
The service type was not displaying in the Type field in the Request app. This has been corrected so the service type associated with the request now displays.
When additions, updates of deletion of data were made in the contact section of a directory record those changes were not propagating to the other tenants. This has been addressed and changes are now propagating to the other tenants in the consortium.
The cancellation auto-responder was not failing to cancel requests at some statuses that should have been cancelled. It is now checking that the status is “active and shipped” before it rejects a cancellation request. If the request status is not “shipped” the request will be cancelled.
When unable to connect to the NCIP server to validate the patron id of a request, the system was assuming the patron id was valid. Now the system puts the request in an 'Invalid patron' state. The audit trail in the request will record the following to indicate that there was an issue connecting to the NCIP server vs getting a true “unknown user” response:
Host LMS integration: lookupPatron call failed. Review configuration and try again or deconfigure host LMS integration in settings. [{"detail":"tenant's IP address","type":"NCIP1 with socket Client failed to call NCIP server or parse returned results"}]
When marking a request returned by patron as the borrowing library, the message confirmation that appears has been changed to read 'Successfully marked returned by patron' or 'Successfully marked returned by patron and return shipped' (if combined action is enabled in Settings), instead of 'Request successfully filled' which is the confirmation request when filling a request on the supplier side.
Adding an address to a directory record caused an error. A rebuild of ui-rs corrected the issue.
With the status changes being in the code it is hard to understand what can happen when a state changes and does not cleanly support alternative state models. By moving state changes to the database we should be able to more easily support different types of items being requested (e.g. Loan, CDL and Non-Returnable) that may introduce different state changes in their respective request flows.
The Z39.50 metaproxy address used within ReShare was hard-coded. This address can now be configured within Settings>Resource Sharing>Z39.50 settings>Z39.50 proxy address. This setting will typically be set by a consortium’s service provider for all tenants and will not need to be updated or changed once a consortium has been implemented.
To keep in sync with FOLIO versions, the ReShare UI was upgraded to the Lotus version of Stripes.
A test was created that creates a request and runs it through a typical workflow. This will allow for faster testing of updates to the ReShare code before being released to ensure that updates do not affect other areas of the request flow.