[OPEN-ILS-GENERAL] Missing item check-in - handling holds

[Josh Stompro]

Hello, does anyone have any suggestions with how to best handle missing/lost items with holds at check-in?  What I think is happening is that the missing items don't have any entries in action.hold_copy_map since they were not holdable.  Now that they are available again, there will be no entries in the hold copy map until the first hold gets retargeted.  So the check-in either sends the item to re-shelving or in-transit back to the circ lib, even though there may be holds waiting locally or at a closer location than the circ lib.

The copy will show up on the pull list after at least one of the holds gets retargeted, but it won't necessarily be the correct hold that is next in line until 24 hours later.

The work arounds that I know of are to use the Retarget Local Holds & Retarget all statuses check in modifiers, which will help if there are any local holds.  But if there are no local holds then this won't address the issue.  The second work around is to manually select holds to retarget from the holds list.

Has anyone worked out a way for this to happen automatically, so that at a status change from a non-holdable to holdable status the copy gets added to the hold copy map for all active holds, so opportunistic capture works with the expected results without needing work arounds?

I've looked at the check-in modifiers that tsbere added, looking to see how feasible it would be to have a "Retarget All Holds" mode, which looks possible, but could lead to long pauses during check-in while all the holds are re-targeted for titles with many holds.  Or maybe the re-target local holds could have a depth setting, so it would grab all the holds in a branch or system, or consortium.

I wonder if it would be possible to attack the problem based on the copy vs calling the retarget function for each hold?  I wonder if a simpler process would work, one that just tries to add the copy to the hold copy map for each hold, without trying to figure out which hold should have the current_copy set to that copy.  Then the opportunistic capture process can make the final decision.   But I guess that could delay capture unnecessarily if stalling is in use.  Or maybe stalling could be ignored when no holds are targeting a copy.

Thanks
Josh

Lake Agassiz Regional Library - Moorhead MN larl.org
Josh Stompro     | Office 218.233.3757 EXT-139
LARL IT Director | Cell 218.790.2110

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20160325/e6254f9a/attachment.html>