Wishlist: Background targeting of holds when items are edited into a holdable state
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Confirmed
|
Wishlist
|
Unassigned |
Bug Description
When an item is in a non-holdable state due to attributes like current status, the holdable flag set to false in the copy record, or the holdable flag set to false in the copy location, it will not be captured for a hold at checkin.
If the item is edited such that it is no longer in a non-holdable state, it will not be captured for a hold at checkin unless the hold targeter runs, the hold is manually retargeted, or the retargeting checkin modifiers are employed.
If a retarget or some similar process could happen in the background when an item is edited into a holdable state, it would eliminate the need for extra actions to be taken to capture holds on newly added or newly holdable items.
Changed in evergreen: | |
importance: | Undecided → Wishlist |
status: | New → Confirmed |
tags: |
added: circ-holds removed: holds |
How soon after a copy status, etc. update would we expect staff to check the item in for capture?
Since this could result in re-targeting hundreds of holds for a single copy update, the re-targeting process will have to run in the background after the copy update has completed. It could take (say) a minute before the copy could be op-capturable by all affected holds via checkin.
We'll probably want to use the new soft_retarget_ interval option (e.g. "0s") so the copy maps for the affected holds are updated to pick up the newly available copy, without modifying the already-targeted (viable) copies. That should make is slightly faster as well.