Bring parity to the estimated queue position in OPAC and Record -> View Holds UIs

Bug #1795906 reported by Mike Rylander on 2018-10-03
This bug affects 3 people
Affects Status Importance Assigned to Milestone

Bug Description

With the performance driven changes to Hold Shelf and Record -> View Holds UIs, and backing APIs, there is a discrepancy between conception of queue position in those UIs and that of others. A simple change will bring other UIs in line with the new calculation without sacrificing performance in any of them. In fact, other UIs will be (slightly) faster in most cases.

The change will make all queue position calculations relative to the context hold's pickup library. This retains the order relative to other directly relevant holds, though does not show the global position. The initial driver of this request is parity between the My OPAC queue position, which can optionally be displayed to patrons, and the Record -> View Holds staff UI.

NOTE: All queue position values are FIFO-based estimates and do not perfectly model reality, especially in a resource sharing consortium and even for instances using FIFO hold capture across the board, due to transits, exceptions, and human staff interaction with the hold queue.

Branch forthcoming.

Scott Thomas (scott-thomas-9) wrote :

Even with the caveats, this is something we really need. The big issue for us right now is in the My Account portion of the OPAC where the only choice to display the consortial queue position. Since we do not yet resource share across the consortium, Pickup Library queue position would be preferable.

Galen Charlton (gmc) on 2018-10-05
Changed in evergreen:
assignee: Mike Rylander (mrylander) → Galen Charlton (gmc)
Galen Charlton (gmc) wrote :

Another caveat: restricting the hold queue position set to holds that match the pickup library can produce misleading results. For example, consider a library with two branches, A and B, whose patrons mostly use branch A for hold pickup. Suppose a title has 100 holds, with the first 99 placed to be picked up at branch A and the last one to be picked up at branch B.

With this patch, the patron who placed the hold at branch B would see that their request is #1, when it may way be the case that they'll have to wait for the 99 patrons picking up at branch A to get their requests filled first.

To work around this, the branch user/gmcharlt/lp1795906_hold_queue_position signs off on Mike's patch but also adds a new global flag, circ.holds.queue_position_relative_to_pickup_lib, that controls whether or not the pickup library is used to restrict the hold queue set. That global flag defaults to TRUE (restricting to the pickup library set, and thereby matching the staff interface), but can be turned off if that restrict would be two misleading for a given Evergreen site's situation. It's noted that this entire branch is necessarily a trade-off; the field remains open for a general solution that better expresses how long a patron can wait to receive a requested item while still being performant.;a=shortlog;h=refs/heads/user/gmcharlt/lp1795906_hold_queue_position

Changed in evergreen:
importance: Undecided → Medium
assignee: Galen Charlton (gmc) → nobody
Scott Thomas (scott-thomas-9) wrote :

From our perspective, here are the options from least desirable to most desirable:

1. Queue position number is consortial. This is, of course, what we currently have and a customer service problem for us.

2. Choice between consortial and pickup library. I believe this is what is being proposed. If given the choice, we would choose Pickup Library.

3. Choice between consortial, pickup library, and "system." If a group of libraries, under the same parent in the org unit tree, function as a library system and resource share, the queue position number, if "system" were selected, would be the number within that system.

I assume #2 would be easier to implement (and we hope it can be done as a hot fix frankly), but #3 should be, in our view, the ultimate goal.

Kathy Lussier (klussier) wrote :


If an Evergreen site sets the global flag to False, will it only affect the queue position in the public catalog but leave the staff client queue position as is? Or will both queue positions pay attention to this flag?

Scott Thomas (scott-thomas-9) wrote :

We are testing this one of our test servers. In My Account, the queue position is indeed the Pickup Library position and not the consortial position. This is peferable. However, the number of copies is consortial.

Changed in evergreen:
milestone: 3.2.1 → 3.2.2
Scott Thomas (scott-thomas-9) wrote :

From a management perspective, we would prefer a Library Setting wherein we could choose a Pickup Library or Consortial queue position per org unit.

Changed in evergreen:
milestone: 3.2.2 → 3.2.3
Changed in evergreen:
milestone: 3.2.3 → 3.3-beta1
Mike Rylander (mrylander) wrote :

I've pushed a branch that converts Galen's global flag into a YAOUS to allow some more control over what "resource sharing" means for patron-visible hold queue position calculation. From the commit message:

Here we convert the global flag to a YAOUS that allows each library to specify
a "sharing depth" for hold queue position as shown to the patron. Staff
retain direct control over the context of this calculation by means of an org
selector in the relevant UIs.

Values of note for the YAOUS:
 * Completely unset: restrict peer holds to the context hold's pickup library
 * Depth == 0: Treat all holds as queue peers, regardless of pickup library;a=shortlog;h=refs/heads/user/miker/lp1795906-hold_queue_pos_by_depth

Changed in evergreen:
milestone: 3.3-beta1 → 3.3-rc
Changed in evergreen:
milestone: 3.3-rc → 3.3.1
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers