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

Here be the branch: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1795906-queue-position-calculation-parity

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.

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.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gmcharlt/lp1795906_hold_queue_position

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.

Galen,

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?

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.

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

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

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp1795906-hold_queue_pos_by_depth

I had a possible default-behavior thought for this bug. If we lack a setting value, we could default to using the selection depth of the hold in question, which would take into account any soft or hard boundaries in play for the hold. The drawback is that soft boundaries could make the queue position seem higher that it actually is, because it would further restrict the set of holds we consider peers in the situation where there was an extant copy at, say, a branch when the hold was placed, but that can be overridden by the proposed setting.

NOTE for our future selves: we can't just use the hard boundary setting directly, instead of the new proposed setting, because that does not have to exist in order to get a distance-restricted hold -- the hold transit restrictions can also do that -- and would be both more likely to vary and would not necessarily hold (heh) from hold request to hold request.

Branch doesn't merge onto master easily. Stupid seed data.