Wishlist: Holds Soft Stalling Interval Based on Pickup Library and Availability

[John Amundson]

Evergreen 3.2.10ish.

There is currently a Library Setting called "Soft stalling interval". When set, items checked in will NOT opportunistically capture foreign holds if they were placed within the set interval. There are some more caveats to it, but that appears to be how it generally works based on my testing.

We do not have this traditionally set in our network because it has not worked well in the past. In my current testing, I've come to realize that the setting is based on the library that checks in the item to be captured and NOT the pickup library.

For example, let's say the setting is set for an interval at BR3. If a hold is set for pickup at BR1, and a staff member checks in at item at BR3, the item won't capture the BR1 hold since the setting was set to BR3.

I cannot think of any scenario where the checkin library would matter, but perhaps I am not thinking of the full picture. At least in our network, the setting would have to be set at the CONS level for it to do any good.

So, step 1 would be an updated or new soft stalling interval that is based on PICKUP library and not CHECKIN library.

Step 2 is where the wishlist part comes in. Currently, the setting does NOT take into account the availability of items at the pickup library. Holds will be skipped regardless of if there is an available item at the pickup library.

While deciding if we should try out the soft stalling interval at the network level, I ran some stats to see how many holds would be positively affected, (i.e. there was an available copy at the pickup library), and how many would be negatively affected, (i.e. no available copies but the hold was still skipped). I tested the interval and 1, 2, and 3 days.

At all settings, more holds would have been negatively affected than positively affected. For example, when set to '3 days', 7,500 more holds would have had a chance to be captured locally over the last month, but 15,000 holds would have been skipped for no reason, increasing the amount of time patrons would have to wait for their holds.

During previous conversations regarding this setting in our network, there was also a desire to have stalling prevent hold retargeting during the stalling interval. This would allow a little extra time for libraries that want it, to pull their local holds. Many of our libraries are only open for a small portion of the week, and their local holds have moved onto other items before they ever get a chance to pull.

The technical logic may be more difficult, but the "human" logic seems pretty straightforward. If there is a copy in action.hold_copy_map where the circ_lib is the pickup_lib and the copy's status is Recently Returned/Available, then do not allow foreign opportunistic capture, (and optionally, do not auto-retarget), during the entered interval. If this item does not exist, allow foreign opportunistic capture and allow the hold to retarget.

[Elaine Hardy (ehardy)]

From our testing, currently, stalling occurs whether or not there is a copy at the pickup library, so adding that it checks for ownership and availability would be helpful.

It would also be helpful if stall could apply to holds targeting as well.

[John Amundson (jamundson)]

See also Bug #1903749

[Mike Rylander (mrylander)]

I have pushed a branch that adds two new YAOUSen that control this new pickup library oriented stalling. The new settings can work in conjunction with the existing soft stalling setting. Branch coordinates: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1895052-pickup-library-controlled-stalling-rebased

From the commit messages:

First:

This commit provides a new YAOUS that, when set, takes precedence over the current "soft stalling interval" YAOUS. Instead of limiting capture to items owned by the pickup library (or the directly targeted item) based on the context of scanned item's circulating library, it instead
restricts op capture to holds that have a pickup library of the scanning location when the hold is younger that the interval, base on the context of the pickup location of each hold.

tl;dr: It allows the pickup library to control op capture stalling rather than the circulating library of an arbitrary scanned item.

Second:

This commit adds a new YAOUS that allows a pickup library to specify that it does not want its holds to have foreign (prox > 0) copies directly targeted if there is a local copy in an available status (on the shelf). The setting is an interval, and after the age of the hold
has passed that interval, foreign direct targetting is allowed.

This does not change the calculation of the potential list, so op-capture will be available (all else being equal) without retargetting.

This setting (circ.pickup_hold_stalling.hard) is meant to be used in concert with the other new setting in the parent commit (circ.pickup_hold_stalling.soft), and should generally have a value the same or smaller than the soft setting. Doing this allows tiered targetting, where no remote items are targeted via the hard setting for, say, 3 days, where all capture is restricted to only the pickup, and then, with a soft setting of 5 days, the next 2 days allow only direct target capture of foreign copies. After 5 days, normal, global targetting and op-capture resumes.

An alternative use for this setting is to ignore the parent-commit soft setting and allow op-capture everywhere, but only direct targetting at the pickup library. The effect of this, if used globally throughout an entire Evergreen instance, would be that the pull list would only
represent pickup-local holds, but serendipitous scans of items that could fill remote holds could capture for transit.

Thank you to CW MARS for funding this effort!

[Jason Stephenson (jstephenson)]

We have tested this at CW MARS and are satisfied with the functionality.

I have added my signoff to a branch here: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp-1895052-pickup-library-controlled-stalling-signoff

[Jason Stephenson (jstephenson)]

After an internal conversation at CW MARS, I rebased the signoff branch on master and added John Amundson's signoff this morning. It's in the same location and force updated.

[Galen Charlton (gmc)]

Pushed to master for inclusion in 3.8. Thanks, Mike, John, and Jason!