e.g. loans, fees/fines | Name | e.g. Q4 2018, Q1 2019 | Clearly stated decision | | e.g. mock-up, JIRA issue |
|
Requests (ASRs) | Cate Boerema (Deactivated) | Unknown | Cate will reach out to David Bottorff and Cheryl Malmborg for more requirements for ASR integration | - 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
|
Requests (Offsite Storage Requests) | Cate Boerema (Deactivated) | Unknown | RA SIG will revisit this topic as a group | - Everyone has offsite/remote storage
|
| - The solution for this and ASRs may be the same
- At Lehigh, some of the remote storage is special collections and there are workflows needed for approvals
- Will come back to this discussion later
|
Requests (Request Queue Management) | | Unknown | - 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.
|
| JIRAs created: Jira Legacy |
---|
server | System JIRA |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
key | UIREQ-226 |
---|
|
Jira Legacy |
---|
server | System JIRA |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
key | UXPROD-1558 |
---|
|
JIRAs edited: Jira Legacy |
---|
server | System JIRA |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
key | UXPROD-1242 |
---|
|
| - 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
|