We're going to hold off on Thursday meetings for the next couple of weeks while our POs finish up with their push for Q1. Please leave them on your calendars, because they'll be back.
Determine if ASR requesting is Chicago specific or applies to offsite requesting in general.
As I understand it, Chicago (and perhaps others) need automated storage requests (?) before they can go live. I would like to understand enough of the concept to populate the new UXPROD feature so early implementers can rank. https://issues.folio.org/browse/UXPROD-1516
- Should recall requests automatically go to the top of the queue (probably below rush recalls, when we have them) behind any existing recall requests? - What happens if the request queue is manually re-ordered and a hold is put above a recall in the queue?
- Considerations:
-- We've said renewals should be blocked on items that have been recalled - do we only look to see if a recall is in position 1 of the queue or should we block renewals if there is a recall anywhere in the queue? -- What about shortening of the loan period that usually occurs when an item has been recalled (based on the recall return interval and minimum guaranteed loan period)? Do we only do this when the request in position 1 of the queue is a recall? - Current thinking is that only looking at position 1 of the queue is the simplest and most understandable - What use cases should we consider? -- A request was originally created as a hold but is now more urgent. -- A request was originally created as a recall but is now less urgent. -- Other uses cases? What are the use cases for manual request queue re-ordering?
Because only Chicago has an automated storage facility
Integration with automated storage facility
Typically there is a DB outside the ILS
ASR vendor has done some custom programming for integration
The requests table is polled for ASR requests
It might work to poll for page requests with an ASR location
Really something is needed to identify that this is a request for ASR
But ideally it's a separate request type
The discovery layer looks at the status of an item (at Chicago, there is a status "Available at auto storage" and, if the item has that status, the discovery system knows to create the ASR request
If something is awaiting pickup, nothing should be able to jump it in the queue (because a notification has already gone out to the requester)
You shouldn't be able to request something you currently have on loan (users game this loophole for recall wars)
If the top item is a recall and it's cancelled, it would be great if FOLIO would extend the due date again for the current borrower (nice to have feature that many systems don't have today)
Yes, recall requests should automatically be prioritized over holds in the requests queue
This automatic queue management is essential
Manual queue management is also essential so you can manually prioritize some recalls over other recalls or some holds over other holds
The system doesn't need to support prioritizing a hold above a recall as that would be extremely rare could cause problems and they could find a workaround
If we offer the ability to manually manipulate the request queue plus the ability to change the due date in a request, people would not need Rush recalls
Manual manipulation of the request queue is higher priority than rush recalls.
FIFO queue management actually works for Chicago, but they are an outlier
Patron requests all for ILL
Circ staff manually converts to recalls only if item not avilable via ILL
Holds are only done on On order or In progress items
Five Colleges doesn't have a request type distinction in their current system and doesn't understand how the patron should know which type of request they want
Cate said this sounded like Chalmers' current setup
They plan to implement only Pages and Recalls so there is never a choice to be made by the patron (the system knows which one to create based on item status)
Cornell lets patrons choose whether they want to create a hold or recall by asking them whether they need it right away or can wait until it becomes next available