Wishlist: Option to cancel hold transits when a hold is canceled

[Bill Erickson]

Evergreen 3.1

When a patron or staff cancel a hold that is already in transit, the transit remains open. The original idea behind this decision was likely based on retaining information about why an item was in transit, even though the hold itself was no longer active.

Now that we have the ability to cancel transits in lieu of deleting them, I propose a new org unit setting which causes hold transits to be cancelled when a hold is canceled.

Note that hold transits are already canceled when a hold is "reset".

Two benefits of this:

1. For sites using intermediate sorting facilities, a transit canceled before the item is sorted means it can be routed home by the sorter, instead of having to complete its journey to the pickup library and then, in many cases, go right back home again.

2. Scenarios where copies in transit end up at some other location other than the pickup library will no longer have to take extra steps to clear the transit before checking the item in.

[Bill Erickson (berick)]

For future reference, I'm referring to the "open-ils.circ.hold.cancel" API.

Note the code comments:

# Leave the transit alive, but set the copy status to
# reshelving so it will be properly reshelved when it gets back home

[Terran McCanna (tmccanna)]

+1 to this proposal

[Anna Goben (agoben)]

Related bug: #1780315

[Anna Goben (agoben)]

https://bugs.launchpad.net/evergreen/+bug/1780315

[Josh Stompro (u-launchpad-stompro-org)]

EG 3.11.1 - Related situation to this bug, I'm not sure if this should be it's own bug.

When an item that is in transit, has it's hold canceled, then uncanceled and suspended. The check in interface gets confused and reshelves the items at the pickup location.

We run into this occasionally. Staff places a bunch of holds for a book club and intends to suspend them and set an activation date in the future for the date the book club needs them. If they forget to suspend the items, and notice it a few days later then the following can occur. Staff cancels the holds. Then Uncancels them and suspends them. When the items arrive and are checked in, they don't go back in transit, they go into reshelving status and potentially can get shelved in the pickup location, causing them to get lost to evergreen.

Steps to reproduce:
1. Place a hold for a title with items at branch B and pickup at branch A.
2. Check in item at branch B to put an item in transit.
3. Switch workstation to Branch A.
4. Cancel the hold, then uncancel the hold and then suspend the hold.
5. Check in the item at Branch A. Observe that it just shows up as reshelving.
6. Check in again, and watch the item go back in transit to branch B.

This would probably get fixed by canceling the transit when the hold gets canceled... but some extra checking on checkin with a hold transit would also help the problem go away.

Debugging info:

Transit looks like this when it first goes in transit.

-[ RECORD 1 ]-------+------------------------------
id | 1768496
source_send_time | 2023-12-13 08:11:03.297338-06
dest_recv_time |
target_copy | 3120539
source | 129
dest | 102
prev_hop |
copy_status | 8
persistant_transfer | f
prev_dest |
cancel_time |
hold | 1560998

After the hold is canceled, the transit isn't touched, and looks the same. The hold transit.copy status is still in transit.... oh, there are multiple transits due to my testing, a different transit gets it's copy_status set to 7 for reshelving. I now have 3 hold transits, 2 for one item, 1 for another, all on the same hold. The one that got set to reshelving 7 status was already received, it has a dest_recv_time set.

The code just looks for the first non canceled transit for the hold that gets returned, but maybe that should be the first non canceled, non received hold transit? And maybe it should also limit to the transit for the current copy also? Or maybe it should sort by something to get the newest transit also.

            $logger->warn("! canceling hold [$hid] that is in transit");
            my $transid = $e->search_action_hold_transit_copy({hold=>$hold->id,cancel_time=>undef},{idlist=>1})->[0];

[Michele Morgan (mmorgan)]

Josh, the behavior you describe is definitely buggy, but I wonder if a slightly different workflow would be smoother.

Instead of canceling, uncanceling, then suspending the hold, retargeting may be a better option:

Choose "Find another target", then suspend the hold.

Find another target cancels the transit on the captured item.

That said, there should definitely be at least an option to cancel the transit when the hold is canceled, or the transit should just be canceled as it is when the hold is retargeted. Behavior should be consistent for both situations.

[Terran McCanna (tmccanna)]

Noting that this behavior existed in the XUL client - see: https://bugs.launchpad.net/evergreen/+bug/1780315