No capture for items checked in from unholdable statuses

[Dan Guarracino]

Tested on Evergreen 3.6 and 3.7.2

When an item with an unholdable status (such as missing) is checked in and could fulfill a hold, Evergreen does not capture it for the hold. This seems to happen both when the item is one of several items that could fulfill the hold and when the item is the only potential copy for a hold.

This was tested with items with missing, damaged, and lost statuses; I suspect that this behavior is the same for items with any other status that is not holdable. This was tested at a consortium without any hold stalling on workstations with both the "Retarget Local Holds" and "Retarget All Statuses" checkin modifiers enabled.

To replicate:
1. Scenario 1 (opportunistic capture):
- Place a title hold on a title with several available items.
- Mark one of the items missing (ideally one that isn't the currently targeted copy).
- Check in the missing item. The item will not be captured for the hold.

With that above, you could also try to check in another copy of the title that isn't currently targeted. Despite not being targeted, it should still be opportunistically captured for the hold.

2. Scenario 2 (hopeless hold):
- Find or create a hopeless hold on a title with a single item.
- Check in the item that could fulfill the hopeless hold. The item will not be captured for the hold.

Ideally, an item shouldn't go to Reshelving / Available if it could fulfill a hold, no matter what status it's coming out of. The item will eventually be targeted the next time the targeter runs on the hold.

[Michele Morgan (mmorgan)]

Adding a link to related Wishlist bug 1686463, which was created some time ago.

I considered marking this as a duplicate of the wishlist, but this report is clearly written as a bug, and the behavior definitely is buggy. There is some discussion on 1686463 about ways to address these issues, but I didn't really want to bury this new report of the longstanding issue under the old wishlist bug.

In our consortium, we have been working around the issue of newly holdable items not capturing for years.

We changed many of the item statuses to holdable=TRUE from the default holdable=FALSE, so that, for example, Missing items WILL capture for holds when they are checked in. This can allow hopeless holds to be created, however, which need to be managed.

We employ the "retarget" checkin modifiers, often more than necessary, but these only act on local holds and are overkill for the vast majority of checkins.

We still see issues, an example is when age protection expires or is removed from an item. This makes that item now holdable for many additional holds. The next hold that gets placed (or retargeted) will target the item, and this is often not the hold that should next be filled.

Marking this Confirmed.