Requests (UXPROD-790)

[UXPROD-1409] Rush Recalls: Staff/Admin/Rush Recalls/Requests Created: 07/Jan/19  Updated: 10/Jan/23

Status: Draft
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Requests

Type: New Feature Priority: P3
Reporter: Cate Boerema (Inactive) Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: requests, round_iv
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Potential Workaround: Cate Boerema: You can speed up a recall if we have the ability to manually reorder the request queue (UXPROD-1242). Just move the critical recall to the top of the queue. That said, this isn't going to result in as fast of a return, as regular recalls respect the minimum guaranteed loan period. You could manually change the due date on the loan and send an email to the current borrower asking them to return the item asap. We also now have a patron notice trigger for due date change so the patron notice could be automatic in this case. Change due date seems like it would work fine if there is no request queue. When there is a request queue, it's not an ideal solution.
Epic Link: Requests
Front-End Confidence factor: Low
Back End Estimate: XXL < 30 days
Back End Estimator: Marc Johnson
Estimation Notes and Assumptions: We don't have a way of restricting activities to only staff or patrons, except via permissions
Development Team: Vega
Kiwi Planning Points (DO NOT CHANGE): 3
PO Rank: 62
PO Ranking Note: 2020-10-04 - CB: Making my PO rank same as the calculated total rank for now.
2019-07-12: Keeping PO rank same as calculated rank (with potential minor adjustments to avoid having two features with same rank)
Rank: Chalmers (Impl Aut 2019): R5
Rank: Chicago (MVP Sum 2020): R2
Rank: Cornell (Full Sum 2021): R2
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R2
Rank: FLO (MVP Sum 2020): R1
Rank: GBV (MVP Sum 2020): R4
Rank: Grand Valley (Full Sum 2021): R4
Rank: hbz (TBD): R4
Rank: Hungary (MVP End 2020): R1
Rank: Lehigh (MVP Summer 2020): R2
Rank: MO State (MVP June 2020): R2
Rank: TAMU (MVP Jan 2021): R4
Rank: U of AL (MVP Oct 2020): R2

 Description   

How are rush recalls different from regular recalls?

  • They override the minimum loan period
  • Basically, they say ignore min loan period and make it due in X days
  • Patrons are not able to create rush recalls (need to be able to make this a staff-only function)

When are rush recalls used?

  • When something is needed for course reserves (most common)
  • Or a special event which requires an item
  • Or if something is loaned accidentally (should actually have been in a non-circulating collection)

Current thinking on design:

  • Must have:
    • Should be its own request type (like recall, hold, page)
    • Should automatically go to the top of the request queue and there should only be one allowed in each queue
      • Need to think about the impact when there is already a page request at the top of the queue
        • This could be useful if there is a Paged item with a queue of requests on it and you want to prioritize Professor Jones' request so it's at the top of the queue
        • By their nature, page requests are usually in position 1. If a rush recall goes into position 1, do we need to require the request type for the page request to be changed to something else?
        • Rule could be: If a request is moved above a page request (which is always in position one), the user will be prompted to change the request type of the page request to a recall or hold
        • What should happen to item status in this case? Can/should it stay "Paged"? It will change to Awaiting pickup as soon as it's checked in anyway. Should there be a special status for items that have been rush recalled?
      • Should it be possible for a rush recall to go above an existing request for which fulfillment has already begun? Normally we prevent that (probably should in this case too)
      • I am guessing that, since rush recalls will be infrequent and rush recalls on paged items even less frequent, it might be okay to just leave the item status "paged"
    • Should show the current due date of the loan being recalled (so you can see if it is due tomorrow, you don't need to create a rush recall)
    • Staff manually enters new due date at request creation
    • Needs to have the ability to trigger a specific patron notice template at rush recall creation
    • Only certain staff should be able to make these (so need permission for this)
  • Nice-to-have (please exclude from the dev estimates)
    • If there is a rush request on an item, it would be good if no one else could place requests/recalls on it (could be a setting/configuration)
    • In current systems, you have to create dummy patrons to create the request (e.g. “Course reserves”). Would be nice to have the option to have the option to go to an actual patron account OR go into some kind of internal process. Could use the “needed for” item state and/or workflow engine. This would have to come after Item States in 3 Parts ( UXPROD-1037 Closed )
  • Additional thoughts from SIG meeting:
    • If we offer the ability to manually manipulate the request queue ( UXPROD-1242 Closed ) plus the ability to change the due date in a request (no feature created), people would not need Rush recalls
    • If we went this route, SIG would like to see the current due date and, possibly, the due date that would be calculated if a regular recall was applied
    • BUT All of this displaying and changing due dates only makes sense when you are looking at the top request in the queue (because, otherwise, you don't know what loan you are modifying)
    • Given this, it seems a separate Rush recall type makes the most sense (see comments below from discussion with Marc Johnson in which we reached this conclusion)

Thoughts on priority/value:

  • A couple of institutions said they could probably do without this feature
  • But an institution that uses these says they have been able to extend the minimum loan period for recalls because they have the option to do a rush recall
  • Need to work with the SIG to understand if this is needed in addition to the ability to manually re-order the request queue ( UXPROD-1242 Closed ) or if we only need one


 Comments   
Comment by Cate Boerema (Inactive) [ 05/Mar/19 ]

Discussion with Marc Johnson. What we need for this to work:

  • auto reordering of queue so rush recalls are at the top of the queue
  • notification that can be triggered at creation of rush recalls
  • we could add a rule that says you can have only one rush recall in the queue
  • show the current due date for the loan
Comment by Cate Boerema (Inactive) [ 20/May/19 ]

Marc Johnson and Michal Kuklis could you estimate this feature please? Thanks!

Comment by Holly Mistlebauer [ 07/Mar/22 ]

This feature is marked DRAFT until Brooks Travis has a chance to review it for validity.

Generated at Fri Feb 09 00:15:22 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.