Checkins for age protected items on Bib Records with many holds can take a long time

One simple way to pre-filter would be to hook into the best hold selection sort.

To keep non R and F holds from being evaluated for non holdable copies, something like this could be done.

And the following to the best hold selection sort query - http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/Publisher/action.pm#l581

AND (h.hold_type IN ('R','F') or exists (select 1 from asset.copy acp where acp.id=hm.target_copy and acp.holdable) )

That would result in only Recall and Force holds being included when a copy isn't holdable because of the asset.copy holdable field.

The performance impact of that addition seems to be minor when I try it out, but I think that would take care of the above issue with a rental item that isn't holdable.

This wouldn't help if an item isn't holdable because of shelving location, but that could also be added. I wouldn't think that status would apply in this instance, since this isn't for targeting.

An age hold protection filter can probably also be added this way, but that has more variables to pull in.

I don't know if this is really a good solution though, since it moves permit hold logic into the nearest hold section. It may make things less understandable in the future.

Josh

related:

bug 1508208

I see why this is a hard problem. The age hold protection determination depends on the hold matrix matchpoint to know if the owning lib or the circ lib is used to pull the active date use setting and to choose where to measure the distance from. Maybe we could just look at all the variations and include the hold if any of them are true? There would still be a chance that holds would be included that will fail the hold permit test later, but I cannot picture a situation where the owning lib and circ lib would be different where they would be in different age hold protection scopes.

Description edited to remove the part about non-holdable items. Turns out that if targeting is up to date, non-holdable items will not exhibit the checkin delay because there will be no entries for the item in the hold_copy_map.

That said, age protected items are still a problem. A recent IRC discussion raised the question of whether items under age based hold protection should have entries in the hold copy map for holds that they cannot fill until their age hold protection expires. That approach seems like it should resolve this issue, as well as bug 1508208.

Here's a link to that IRC discussion:

http://irc.evergreen-ils.org/evergreen/2019-03-28#i_400725

Is there any benefit to having rows in the hold_copy_map that map age protected items to holds that they cannot fill?

I have had many reports of delayed checkin of items with long list of holds. The process of seeing if the item is on hold takes longer than it should. This causes problems when staff are checking in a stack of items. They continue scanning and don't realize the system is still working on the item with a hold. I know they should watch the screen to be sure the process has finished but they don't. We have categorized this as staff training for the most part but if the timing could be faster it would be wonderful. Confirming this behavior.

FWIW, I've updated my branch proposing to fix bug 1508208, and I agree with Michele that it would address both that one and this -- I think they're the same bug.

Based on Michele's and Mike's comments I'm marking this a duplicate of bug 1508208