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

Auto Ordering of Requests Queue Based on Type (i.e. Recalls Filled Before Holds)

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Open (View Workflow)
    • Priority: P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Template:
      UXPROD features
    • Potential Workaround:
      Hide
      Cate Boerema: Discussed with SIG one potential workaround, once we have implemented UXPROD-1242, would be to require staff to manually reorder the queue so recalls are above holds. This isn't an ideal solution because there is no obvious way to know that a queue needs reordering.
      Show
      Cate Boerema: Discussed with SIG one potential workaround, once we have implemented UXPROD-1242 , would be to require staff to manually reorder the queue so recalls are above holds. This isn't an ideal solution because there is no obvious way to know that a queue needs reordering.
    • Epic Link:
    • Front End Estimate:
      Large < 10 days
    • Back End Estimate:
      XL < 15 days
    • Confidence factor:
      Low
    • Estimation Notes and Assumptions:
      Hide
      CB: Per discussion with the cap planning team, some of use non-developers are estimating features to avoid disrupting development. I will tag this as "swag" so we know to come back and revisit later when we have more info and are closer to development.
      Show
      CB: Per discussion with the cap planning team, some of use non-developers are estimating features to avoid disrupting development. I will tag this as "swag" so we know to come back and revisit later when we have more info and are closer to development.
    • Development Team:
      Prokopovych
    • Calculated Total Rank:
      31
    • PO Rank:
      29
    • PO Ranking Note:
      Hide
      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)
      Show
      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):
      R4
    • Rank: Cornell (Full Sum 2021):
      R4
    • Rank: Duke (Full Sum 2021):
      R1
    • Rank: 5Colleges (Full Jul 2021):
      R4
    • Rank: FLO (MVP Sum 2020):
      R4
    • Rank: GBV (MVP Sum 2020):
      R4
    • Rank: Grand Valley (Full Sum 2021):
      R4
    • Rank: hbz (TBD):
      R4
    • Rank: Hungary (MVP End 2020):
      R4
    • Rank: Lehigh (MVP Summer 2020):
      R4
    • Rank: MO State (MVP June 2020):
      R4
    • Rank: TAMU (MVP Jan 2021):
      R1
    • Rank: U of AL (MVP Oct 2020):
      R4

      Description

      FOLIO has several different request types so far: page, recall and hold. Currently, the request queue is ordered first-in-first-out (FIFO). This means that a hold request ("I'd like this when it's available") could be higher in the queue than a recall requests ("I need this as soon as possible"). This is not going to work for (most) institutions that plan to use both recalls and holds.

      We do plan to implement the ability to manually re-order the request queue (UXPROD-1242) but the system should also do sensible auto-ordering, as manual reordering requires that staff is aware that re-ordering is needed (and this may not be obvious, especially if the requests are patron-generated). The scope of this feature is implementing the sensible auto-ordering of recalls above holds.

      NOTE 1: This feature is only necessary when there are both recalls and holds in a request queue for a single item (with a hold above a recall). If your institution doesn't expect to be in this situation (because you only use recalls or holds OR because it's rare to have both recalls and holds on a single item, you might not rank this high).

      NOTE 2: I tested how FOLIO works without this feature implemented and here's what happens if a recall is made for a loaned item which already has a hold request on it:

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

      -------------------------------------------------------------------------
      Details (from SIG meeting):

      • Recall and hold requests can exist together in the request queue for an item
      • Recall requests should automatically be prioritized over holds in the requests queue so that the requests that were identified as recalls (meaning "I need this right away") take priority over those identified as holds ("I'd like this when it's available")
      • 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)
      • Page requests are only created for items that have no other requests on them. It is possible to put a hold on an item that has been paged, but there is no need for the system to prioritize holds over pages or vice versa

      For more info on the differences between request types, see this document: https://docs.google.com/spreadsheets/d/1jaID-HGft3q4YzJq6Ycy2ejWByAIvou3Zyyw4ko87YI/edit#gid=0

        TestRail: Results

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                brookstravis Brooks Travis
                Reporter:
                cboerema Cate Boerema
                Front End Estimator:
                Cate Boerema Cate Boerema
                Back End Estimator:
                Cate Boerema Cate Boerema
                Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                  Dates

                  Created:
                  Updated:

                    TestRail: Runs

                      TestRail: Cases