Requests (UXPROD-790)

[UXPROD-1242] Manually Reorder Request Queue (Dedicated Request Queue Page with Re-Order Capabilities) Created: 12/Oct/18  Updated: 16/Sep/20  Resolved: 11/Dec/19

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: Q4 2019
Parent: Requests

Type: New Feature Priority: P3
Reporter: Cate Boerema (Inactive) Assignee: Cate Boerema (Inactive)
Resolution: Done Votes: 0
Labels: cap-mvp, po-mvp, requests
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
is defined by CIRC-446 UIREQ-112: Backend for Dedicated Requ... Closed
is defined by STCOM-585 Spike: UIREQ-112: Drag and drop table... Closed
is defined by UIREQ-112 Dedicated Request Queue Page with Reo... Closed
is defined by UIREQ-318 Permissions - Requests: Reorder queue Closed
is defined by UIREQ-334 When Moving Request from One Item to ... Closed
Relates
relates to UXPROD-1558 Auto Ordering of Requests Queue Based... Draft
relates to CIRC-579 Open requests in snapshot with no que... Closed
Potential Workaround: Cate Boerema: Cancel and re-create requests in order that they should be fulfilled. This is not a good workaround if the institution has patron notices being sent to the requester when requests are created and/or cancelled. Getting these emails could be confusing to patron.
Epic Link: Requests
Front End Estimate: XL < 15 days
Front End Estimator: Michal Kuklis
Front-End Confidence factor: Low
Back End Estimate: XL < 15 days
Back End Estimator: Marc Johnson
Estimation Notes and Assumptions: Low confidence because I think there could be some complexity around how we handle whether only a single request swap is done at a time or whether multiple requests can be reordered together
Development Team: Prokopovych
PO Rank: 96.1
PO Ranking Note: 2019-07-12: Increased priority a bit relative to calculated to put this higher than Assign Patron default pick-up service point for requests (UXPROD-4) which seems more easily worked around. I also marked this po-mvp because this feature is, in itself, going to be used as a workaround for the fact that we won't have rush recalls (UXPROD-1409) or auto-ordering of recalls above holds (UXPROD-1558). If something is needed asap (for an instructor, course reserves, a special event), a workaround could be for the librarian to manually change the due date on the current loan and send an email to the current borrower, BUT if the requests are out of order when the item comes back to the library, FOLIO will fulfill the wrong request.
Rank: Chalmers (Impl Aut 2019): R2
Rank: Chicago (MVP Sum 2020): R2
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R2
Rank: FLO (MVP Sum 2020): R4
Rank: GBV (MVP Sum 2020): R2
Rank: hbz (TBD): R2
Rank: Hungary (MVP End 2020): R1
Rank: Lehigh (MVP Summer 2020): R1
Rank: Leipzig (Full TBD): R1
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R4

 Description   

The initial implementation of the Request queue ( UXPROD-263 Closed ) was not re-orderable. The purpose of this feature is to make the queue re-orderable. This may also involve switching to a dedicated page for the request queue (as opposed to a pre-filtered list of requests)

Details (from SIG meeting)

  • Manual queue management is also essential so you can manually prioritize some recalls over other recalls or some holds over other holds requests above others in the queue (requests are currently FIFO regardless of request type) CB: If we do this before we do UXPROD-1558 Draft , we will allow sorting of any request above another request regardless of type
  • 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 CB: See above comment - we may in fact do this before the auto sorting of recalls above holds ( UXPROD-1558 Draft ). Furthermore, testing has indicated we aren't seeing system problems when a hold is prioritized above a recall
  • If a request is awaiting pickup, nothing should be able to jump it in the queue (because a notification has already gone out to the requester)
  • Need permission to control the ability to re-order queue (requires action-based permission architecture). CB: requirement moved from UXPROD-236 Closed

Current mockup: https://drive.google.com/drive/folders/1ADrLDD09Ub9AKL7Vu704viS8EVPSB8xv

  • Please ignore the auto-sorting of recalls above holds when estimating, as that's covered in UXPROD-1558 Draft
  • Ignore the bulk move request capability shown in the mockups, as this will change. We have decided to begin with just moving individual requests and that functionality is covered by UXPROD-1653 Closed


 Comments   
Comment by Cate Boerema (Inactive) [ 12/Oct/18 ]

This feature was split off from UXPROD-263 Closed

Looks like we have the mockup and story for the dedicated request queue page but no mockups or stories for the ability to re-order. Marking this feature DRAFT.

Comment by Cate Boerema (Inactive) [ 25/Apr/19 ]

The auto-ordering of recalls above holds really should happen prior to this feature. Marking blocked on UXPROD-1558 Draft

Comment by Cate Boerema (Inactive) [ 15/May/19 ]

Michal Kuklis and Marc Johnson can you please add tshirt estimates for this feature? Thanks much!

Comment by Cate Boerema (Inactive) [ 02/Jul/19 ]

Discussed with the RA SIG during the feature re-ranking exercise. See discussion at 55:19 of https://drive.google.com/file/d/15RbACU90Ln4JAazWSz0iM4ZSYia6mIaK/view?usp=sharing

  • Per Andrea, Duke needs this if Auto-ordering of recalls above holds ( UXPROD-1558 Draft ) is not going to be prioritized
  • We need to make sure that, without this feature, things are not, essentially broken. Some questions that come to mind that need testing:
    • What happens/should happen when a recall is placed after a hold request? Is the due date of the current loan shortened? Is a notice sent to the current borrower? Since this is apparently an edge case, it might not matter too much if the answer to these questions is yes or no, but they should be both yes or both no. Cate will test.
Comment by David Bottorff [ 02/Jul/19 ]

This is a rare enough occurrence at Chicago, with relatively few requests on a specific item, that we could live without it for up to 1 quarter by cancelling and then recreating requests as needed.

Comment by Cate Boerema (Inactive) [ 09/Jul/19 ]

Follow up on above comment. I tested what currently happens when a recall is placed after a hold request.

  • The due date for the current loan will change according to the recall settings in the loan policy even though the recall is not at the top of the request queue
  • A patron notice will be triggered (assuming one has been set up) to let the current borrower know their item has been recalled

So, under normal circumstances, the current borrower will get the recall notice and return the item quickly at which point it will be checked in and the hold request will begin fulfillment (since it's first in the queue). When that requester picks the item up, the loan period for the new loan will be shortened if the applied loan policy has made use of the "minimum guaranteed loan period for recalled items". When the item is subsequently returned, it will be checked in and the recall request will begin fulfillment.

Comment by Cate Boerema (Inactive) [ 26/Aug/19 ]

Marking blocked as there are some design and priority questions. See UIREQ-314 Closed for notes)

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