Wishlist: Background targeting of holds when items are edited into a holdable state

[Michele Morgan]

When an item is in a non-holdable state due to attributes like current status, the holdable flag set to false in the copy record, or the holdable flag set to false in the copy location, it will not be captured for a hold at checkin.

If the item is edited such that it is no longer in a non-holdable state, it will not be captured for a hold at checkin unless the hold targeter runs, the hold is manually retargeted, or the retargeting checkin modifiers are employed.

If a retarget or some similar process could happen in the background when an item is edited into a holdable state, it would eliminate the need for extra actions to be taken to capture holds on newly added or newly holdable items.

[Bill Erickson (berick)]

How soon after a copy status, etc. update would we expect staff to check the item in for capture?

Since this could result in re-targeting hundreds of holds for a single copy update, the re-targeting process will have to run in the background after the copy update has completed. It could take (say) a minute before the copy could be op-capturable by all affected holds via checkin.

We'll probably want to use the new soft_retarget_interval option (e.g. "0s") so the copy maps for the affected holds are updated to pick up the newly available copy, without modifying the already-targeted (viable) copies. That should make is slightly faster as well.

[Mike Rylander (mrylander)]

Another option which could work for existing, but not new, copies would be to record untargettable copies an a peer table to action.hold_copy_map. Then we would have a definitive list of holds to retarget, and a potential short-circuit path for adding copies directly to the potentials list if it can be proven that they would now be targettable, all else being equal.

[Michele Morgan (mmorgan)]

I can conceive of a checkin with hold capture expected happening quite soon after the update that makes the item holdable. There's also the frequent situation where a checkin IS the edit that puts the item into a holdable status. Ideally, the hold would just capture in that case.

But even retargeting in the background that could take a minute or so would be a great improvement.

Mike's idea is intriguing, too, and if there could be a way to get new copies into the peer table in the background as they're added, that might cover all the bases.

Here are a few use cases:

A library is processing their pull list. They are unable to locate an item on the list so they change its status to Missing. Shortly thereafter, they locate the item and check it in. The hold should capture.

A library has some items in a "Summer Reading" copy location which are offsite during much of the year. While offsite, the copy location is set as not holdable. When the boxed items arrive at the library, the copy location attribute is changed to holdable, and the items are unpacked and checked in. Any existing holds on the titles to which these items are attached should capture.

A library receives a gift of a very popular item with multiple holds. Cataloging staff quickly enters it into the system and checks it in. The appropriate next existing hold on the title should capture the item.

[Michele Morgan (mmorgan)]

Another situation that came up today was an item whose age hold protection expired while there were still a number of open holds for pickup at various libraries.

A new hold was placed shortly after expiration of the age-hold protection, and the new hold immediately targeted that item, even though many holds up to two months older were still waiting for copies.

[Bill Erickson (berick)]

So in addition to copies being put into a holdable state by staff action (copy edit, checkin, etc.) we are also talking about copies becoming holdable simply by the passage of time (copy age protection).

[Michele Morgan (mmorgan)]

Apparently so, based on the latest observation.

And in addition to directly editing the copy, editing the Copy Location holdable flag will also make a previously not-holdable copy holdable.

So we have:

Item is edited into a holdable state
Copy Location is edited to be holdable
Copy Age hold protection expires

Status attributes and Hold policies can also change but IMO, those situations wouldn't need to be addressed here.

[Jane Sandberg (sandbergja)]

Just a note that new item creation should ideally also cause relevant holds to be re-targeted. This would be very helpful for cases in which catalogers add a new copy of an already popular item. Requiring catalogers to manually retarget holds adds an extra step to the process.

[Michele Morgan (mmorgan)]

This has just come up again in our consortium, in regards to newly created items.

I'm wondering what would be involved in kicking off a process for created or updated items that's similar to the "Retarget ..." checkin modifiers processing available at checkin. And if this could be a reasonable approach.

While it would not solve the age-hold protection expiration, or the change in attributes of status or copy location, it would address the situations related directly to adding and updating items.

It is quite common in our consortium for a newly added or updated item to be expected to capture a hold. Less common for changes that affect the items indirectly.

[Jessica Woolford (jwoolford)]

Adding a usability tag here, as the "Retarget Local Holds" and "Retarget All Statuses" checkin modifiers are confusing to the majority of library staff. I just had a conversation with a director about this yesterday.