Michele, I’ve been thinking about your recommendation off and on, and now a year later I’m looking back into making this change, but I want to make sure I understand all the issues created from this change.
· Pull list shouldn’t be effected; only available/reshelving items should show up on the pull list. · Missing items could still be hidden from the catalog, so public users wouldn’t place holds on titles that have no visible copies. · Patrons may be able to place holds on titles that have non-holdable visible copies along with invisible holdable copies. · Staff will be able to place holds on titles that have only missing copies. · Any reports that make use of config.copy_status.holdable may need to manually exclude missing status, for purchase alert/high demand holds reports for instance. We wouldn’t want a missing copy to count towards a hold/copy ratio. It may not be possible to use the built in reporter hold/copy ratio data sources at all since they would consider all Missing copies holdable and count them as holdable copies. · We already have a report that goes twice a month with lists of holds on titles that have no holdable copies so staff can deal with them, so that should cover the ones that slip through. Does that seem to cover it? Could you also let me know what the other statuses were that you changed. How about lost status? We move things to lost fairly quickly (14 days overdue) so we have quite a few lost items. I wonder if there has ever been any thought on having a new copy status flag, something like ‘capture allowed’. Something that would allow copies to be captured to fill holds, but wouldn’t count as holdable. Maybe action.hold_copy map could have a flag so when targeting or looking for holdable copies only holdable copies would be considered, but during check in captureable copies would be considered for opportunistic capture. That way certain statuses (lost/missing/long overdue/cataloging) might work a little smoother at check in. Thanks Josh Stompro - LARL IT Director From: Open-ils-general [mailto:[email protected]] On Behalf Of Josh Stompro Sent: Thursday, March 31, 2016 1:45 PM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Missing item check-in - handling holds Michele, Thanks for the suggestion. We will look into trying this out. Josh Stompro - LARL IT Director From: Open-ils-general [mailto:[email protected]] 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 [email protected]<mailto:[email protected]> On Fri, Mar 25, 2016 at 11:48 AM, Josh Stompro <[email protected]<mailto:[email protected]>> 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>
