Wishlist: Holds Soft Stalling Interval Based on Pickup Library and Availability
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Wishlist
|
Unassigned |
Bug Description
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.
Changed in evergreen: | |
status: | New → Confirmed |
milestone: | none → 3.8-beta |
importance: | Undecided → Wishlist |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
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.