-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve messaging for failed requests on items in particular FOLIO statuses #2006
Comments
Further analysis on this. We're failing badly when the item has all of the following:
If all of the above are true, and the user clicks the Location level Request button, they see the following error: Example records with Item status = Aged to lost in both folio prod & folio-test:
We should definitely change this. Options include:
I'll review this with @dbranchini. Note: In Fall 2023 we did a "quick fix" and elected to suppress item level request links (e.g. Item was in a non-pageable location like GRE-STACKS or SCI-STACKS) if the item had a FOLIO Item status = Aged to Lost. Here's an example: https://searchworks.stanford.edu/view/13179345 A savvy user (or library public services staffer) may be confused why a request link doesn't appear. Also, with no request link, we can't route the request to ILL for fulfillment. I would vote that we have the same solution for Item level & title level request links for items that are in an Item status = Aged to lost. |
Capturing this response (from Chris on Slack) on whether we currently route any requests directly to Illiad now:
A few thoughts about this... if we go this route, we'd have to change the default behavior of the Aged to lost item status to allow hold/recalls in SW code because it's hardcoded in FOLIO to not allow for hold/recalls. It actually wouldn't become a hold/recall anyway because it would be routed to Illiad. Here's a few questions:
|
In a call, we discovered that we're showing the "System down" message if the item is:
Example of an item record with a FOLIO status = Claimed returned: https://searchworks.stanford.edu/view/10378547 Here's a list of the FOLIO Item Statuses that don't allow requests: NOTE: Items in these statuses may not be discoverable in SearchWorks because they have been suppressed from discovery (or we don't pick them up in the indexer for other reasons.) |
While analyzing ways to improve requests, it was discovered that several requests are failing on aged to lost items. @saseestone
estimated that this might be because we place the request button at the location level based on the circulation rule for the item, but we don't know that there is just one copy in a non-pageable state (because it's aged to lost). So when it goes off to requests, it fails, but not gracefully. We need a developer to confirm this.
Is there a better way to determine whether the request button should be displayed and, then, in these scenarios, NOT give users the option to request the item? If not, then we need to fail more gracefully and provide better information to the user, such as
H1: "Apologies, there's been an error."
p: "[Title] cannot be requested at this time. If you have questions or need help finding an item, please contact us by email at [email address] or call at [number]."
The text was updated successfully, but these errors were encountered: