Uploaded image for project: 'UX Product'
  1. UX Product
  2. UXPROD-1242

Manually Reorder Request Queue (Dedicated Request Queue Page with Re-Order Capabilities)

    XMLWordPrintable

    Details

    • Template:
    • Potential Workaround:
      Hide
      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.
      Show
      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:
    • Front End Estimate:
      XL < 15 days
    • Back End Estimate:
      XL < 15 days
    • Confidence factor:
      Low
    • 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
    • Calculated Total Rank:
      87
    • PO Rank:
      96.1
    • PO Ranking Note:
      Hide
      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.
      Show
      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) 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, 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). 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

      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
      • 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

        TestRail: Results

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                cboerema Cate Boerema
                Reporter:
                cboerema Cate Boerema
                Front End Estimator:
                Michal Kuklis Michal Kuklis
                Back End Estimator:
                Marc Johnson Marc Johnson
                Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved:

                    TestRail: Runs

                      TestRail: Cases