Holds stalling should capture equivalent items at targeted library
Bug #1903749 reported by
Michele Morgan
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Confirmed
|
Medium
|
Unassigned |
Bug Description
When the org unit setting circ.hold_
To make the best use of staff time, and fill holds most efficiently, equivalent copies at the pull list library should also be captured for the hold.
Relevant IRC discussion:
tags: | added: holds |
Changed in evergreen: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
tags: |
added: circ-holds removed: holds wishlist |
To post a comment you must log in.
Here's one way we could address this:
https:/ /git.evergreen- ils.org/ ?p=working/ Evergreen. git;a=shortlog; h=refs/ heads/user/ miker/lp- 1902937- adjacent- hold-capture- when-stalling
Note: this does not currently contain a db-level upgrade script to add the YAOUS (though that can be added by hand in the staff client) and could stand some thought about copy conditions (such as, more than just status=0?). From the commit message:
Currently, setting a stalling interval disable all opportunistic capture except at the pickup library. It would be helpful to allow, optionally, a mode where holds that target a copy physically adjacent to the copy that staff pull from the shelf to fill the hold, all else being equal.
This commit does that by:
1) confirming that hold stalling and the a new setting are both in use copy-targetted holds, they can still capture
2) gathering shelf-adjacent copies that are available
3) gathering holds that directly target those adjacent copies
4) filtering those hold to only those that the copy in hand could fill
5) adding that filtered list to the end of the $old_holds list for last-resort capture testing
6) avoiding retargetting of adjacent-