Dedicated Request Queue Page with Reorder Capabilities

Purpose: We already have a very simple request queue view in Requests (a pre-filtered view of the request search results developed in UIREQ-122). The purpose of this story is to develop a dedicated request queue page for staff with permissions to view the queue AND re-order it.

User story:

• As a circulation staff member (usually those with elevated permissions)
• I want to be able to reorder request queues when they need to be filled in a different order than they came in
• So I can fulfill in the desired order without having to cancel and recreate requests (which would trigger confusing emails to patrons)

Scenarios

1. Scenario
   • Given the view mode of the Request form for any request that is open (Open - Awaiting pickup, Open - In transit, Open - Not yet filled, Open - awaiting delivery (being added as part of CIRC-508))
   • When the pane header dropdown is opened
   • Then a new "Reorder queue" option should be visible to users with the appropriate permission (permissions story UIREQ-318)
2. Scenario
   • Given the Reorder queue option
   • When clicked
   • Then the Request queue screen, listing the request queue for this item (a ranked list of the number of Open requests for this item) should be displayed, as shown in the linked wireframe
     • Header: "Request queue: <InstanceTitle>"
     • Subheader: "N records found" where n = number of requests in the queue (will always be 1 or more)
     • Metadata:
       • Item barcode: "<ItemBarcode>" with hyperlink to item record
       • Item status: "<ItemStatus>"
       • Current due date: "<DueDateCurrentLoan>", if applicable, otherwise "-"
       • Shelving location: "<EffectiveLocationforItem>"
       • Call number: Display <ItemCallNumber> from item record, if populated, otherwise display<HoldingCallNumber>. If neither are populated, display "-" CB: This would be consistent with what we are doing on the Requests form these days. This may need to be revisited later to incorporate other elements of the call number (type, prefix, suffix) and there are features in the backlog to address that (UXPROD-1626 and UXPROD-2002). For now, we will just do what we are doing on the Request record.
       • Volume: "<VolumefromItem>"
       • Enumeration: "<EnumerationfromItem>"
       • Copy: Display copy from item, if populated, otherwise display from holding. If neither are populated, display "-"
3. Scenario
   • Given the Request queue page
   • When viewed
   • Then the following columns should display (values to be populated should be self-explanatory or specified):
     • Position
     • Request type Type shows, but much further down in the list of columns abreaux the type is further down in the mockup so I'm going to keep it as it is for now. cboerema is that ok? cboerema sure this is fine
     • Request status
     • Pickup/Delivery: Should display the "<PickupServicePoint>" or "Delivery: <AddressType>" (e.g. "Delivery: Campus")
     • Requester
     • Requester barcode
     • Patron group
     • Request date: Date and time of request creation in locale-driven format and according to FOLIO time zone (both in Settings > Tenant)
     • Request expiration
     • Hold shelf expiration: Date and time of request expiration. If null, display "-"
4. Scenario
   • Given the Request queue page
   • When viewed
   • Then a close X should display in the upper left (closing page will return you to the previous page (the view mode of request details)
5. Scenario
   • Given the new dedicated Request queue page (UIREQ-112)
   • When I attempt to drag a request to change its position in the queue
   • Then I should be able to drag-and-drop requests into new positions
6. Scenario
   • Given the request in position 1 has already begun fulfillment (so has any status other than Open - Not yet filled)
   • When I try to drag and drop another request into position 1
   • Then:
     • Request should be dropped into position 2 of the queue
     • The following popup should display:
       
     • Question - why are there 2 buttons (Cancell/Confirm) on this modal instead of just one? Should I be able to do 2 different things, e.g. leave the sequence as is if I press cancel, vs. drop the moved one into position 2 if I press confirm?
     • CB: Good point, abreaux. It does look like the buttons have different functions, but that isn't clear from the wording of the popup or the buttons. Maybe we should change the wording to "Requests cannot be displaced from position 1 when fulfillment has begun. This request will be moved to position 2 in the request queue." and have the buttons read "Leave in current position" and "Confirm"
7. Scenario (NEW 2019-09-09)
   • Given the request in position 1 has already begun fulfillment (so has any status other than Open - Not yet filled)
   • When I try to drag and drop that request to another position
   • Then I shouldn't be able to (freeze the row so it can't be moved? or allow moving but snap back into position one when dropping and add a popup message?) MK: Cate I plan to freeze the row in this case so it can't be moved
8. Scenario
   • Given the request in position 1 is a page request (even one for which fulfillment hasn't already begun)
   • When I try to drag and drop another request into position 1
   • Then:
     • Request should be dropped into position 2 of the queue
     • The following popup should display:
       
     • Question - why are there 2 buttons (Cancel/Confirm) on this modal instead of just one? Should I be able to do 2 different things, e.g. leave the sequence as is if I press cancel, vs. drop the moved one into position 2 if I press confirm?
     • CB: Good point, abreaux. It does look like the buttons have different functions, but that isn't clear from the wording of the popup or the buttons. Maybe we should change the wording to "Requests cannot be moved above page requests, even when fulfillment hasn't begun. This request will be moved to position 2 in the request queue." and have the buttons read "Leave in current position" and "Confirm"
9. Scenario (NEW 2019-09-09)
   • Given the request in position 1 is a page request (even one for which fulfillment hasn't already begun)
   • When I try to move it into another position
   • Then I shouldn't be able to (freeze the row so it can't be moved? allow moving but snap back into position one when dropping and add a popup message?)MK: Same here I plan to freeze the row in this case so it can't be moved
10. Scenario
    • Given a request move is not prevented per scenarios 2 and 3
    • When moved
    • Then:
      • Move should be successful
      • Queue position numbers should be updated accordingly
      • No patron notices should be sent
      • Success message should display:
        

Mockup: https://drive.google.com/file/d/1VBGboSPqwuaZH5k0k4dH5xWdPEjVCG8y/view?usp=sharing