Proximity Adjustment, Hold Stalling and Best Hold Order
Bug #1277697 reported by
Mike Rylander
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Medium
|
Unassigned | ||
2.5 |
Fix Released
|
Medium
|
Unassigned |
Bug Description
One use of Proximity Adjustment is to allow a set of libraries to be seen as truly equivalent in terms of hold-related proximity. Until the linked branch, this was not true during the hold stalling interval. However, during the hold stalling interval, only the actual pickup library (defined by its 0-proximity distance from "here") is considered for non-pull-list op cpature of a hold. If configuration has specified that the adjusted proximity should be considered 0 then those libraries should be consider equivalent to the pickup library, and the custom sort order for the item's owning library should be allowed to make the best-hold decision.
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
no longer affects: | evergreen/2.4 |
To post a comment you must log in.
Been testing this on one of our test servers. So far, so good, hold stalling was definitely tripping us up, and this seems to resolve it.
Picked to master and rel_2_5. For rel_2_4, there were whitespace vs. tab issues, but it was a simple tweak to apply it there as well.
Thanks Mike!