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

[Josh Stompro]

Michele,

Thanks for the suggestion.  We will look into trying this out.

Josh Stompro - LARL IT Director

From: Open-ils-general [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of Morgan, Michele
Sent: Wednesday, March 30, 2016 10:05 AM
To: Evergreen Discussion Group
Subject: Re: [OPEN-ILS-GENERAL] Missing item check-in - handling holds

Josh,
To avoid the issues with Missing copies not capturing holds, we changed the config.copy_status.holdable flag for the Missing status to TRUE. This means that items with status Missing get entries in the hold_copy_map and can be captured when checked in.
We did this with a handful of the more transient statuses that were not holdable by default and that has worked well to help with the checkin issues.

It's true that making these statuses holdable can result in holds being placed on records with no items currently available, but we provide reports to help our libraries follow up on these.
That said, I like your idea of attacking the problem based on the copy that's being checked in without forcing all that retargeting.

Hope this helps,
Michele

--
Michele M. Morgan, Technical Assistant
North of Boston Library Exchange, Danvers Massachusetts
mmorgan at noblenet.org<mailto:mmorgan at noblenet.org>


On Fri, Mar 25, 2016 at 11:48 AM, Josh Stompro <stomproj at exchange.larl.org<mailto:stomproj at exchange.larl.org>> wrote:
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<http://larl.org>
Josh Stompro     | Office 218.233.3757 EXT-139<tel:218.233.3757%20EXT-139>
LARL IT Director | Cell 218.790.2110<tel:218.790.2110>


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