Release date: April 25, 2022
...
ReShare now stores and validates a patron’s profile (patron type) returned in the NCIP LookUpUser response. These patron profiles can be managed by staff in Settings>Resource Sharing>Host LMS patron profiles. New profiles can be manually created and updated by staff to indicate whether the profile is allowed to submit requests ✔ or not ✖ in ReShare.
Both the description and actual patron profile code value in the Host LMS patron profile list. The description field is editable but the code remains uneditable.
Note: When adding a new patron profile manually, staff must ensure that the profile code matches the code used in their ILS exactly in order for it to match the value returned in the NCIP LookUpUser response.
When a request is submitted by a patron whose profile has not been configured in your institution’s settings the new patron profile will be added to your list of Host LMS patron profiles. The request will be allowed to be submitted. An email indicating a new patron profile has been added will be sent to the main email address configured in your institution’s root Directory entry. The new profile will display without a ✔ or ✖ beside it to help users visually identify new entries that have been automatically added.
A new Notice policy called 'New patron profile' and a corresponding Notice template called 'New patron profile' have been added in Settings>Resource Sharing to support the notification of staff to newly added profiles as mentioned above.
If staff submit a request on behalf of a patron using the Request app AND the profile returned for the patron is configured to not submit requests into ReShare, the request will be assigned a state of Invalid patron. The reason for the Invalid patron state will be written to the audit log for staff to review. If staff wish to allow the request to be submitted, a new Override borrower check action is available on the Flow screen for the request.
Note: In Release 1.8 the check on patron profile will only occur when staff submit a request on behalf of patron through the Request app. Release 1.9 will support the validation of a patron’s profile / blocking of placing a request when a patron attempts to place a request through discovery (e.g. VuFind).
...
In addition to an item’s location (Host LMS location), ReShare now stores and validates an item’s shelving location returned in the z39.50 response when the Auto responder status is turned on. These shelving locations can be managed by staff in Settings>Resource Sharing>Host LMS shelving locations. New shelving locations can also be manually created and updated by staff to indicate whether the shelving location is requestable by adjusting the shelving location’s supplying priority.
The auto responder will now take into consideration both the Host LMS location and the Host LMS shelving location when determining if an item is requestable when assigning the request to a supplier. If either the location or the shelving location have a supplying priority of -1 the item will not be considered requestable.
If a shelving location value in Host LMS shelving locations (e.g Stacks) is requestable in combination with one Host LMS location but not another, staff have the ability to assign an override for the Host LMS location in Settings>Resource Sharing>Host LMS locations to render that combination of locations unrequestable. Using the
action staff can create the shelving override by selecting the shelving location and assign a supplying priority of -1 .A new column called Shelving override now displays in the list of Host LMS locations. Those locations with a ✔ indicate that there is an override configured for it.
Both the description and actual location/shelving location value now display in both the Host LMS location and Host LMS shelving location lists. The description field for a given location/shelving location are now editable but the code remains uneditable.
Note: When adding a new Host LMS location or Host LMS shelving location manually, staff must ensure that the location value matches the value returned in the z39.50 response from their ILS exactly in order for the Auto responder to correctly match it.
...
have been added to Settings>Resource Sharing>Auto responder settings to allow tenants in a consortium to turn on the 1. enable the forwarding of stale requests after 2. the number of configured days and 3. whether or not to include weekends when determining when to pass a request on to the next supplier.
Note: For this new feature to work effectively, the three configurable values should be identical across all tenants in the consortium.
...