Cancel transits on checkin screen cancels wrong transit

[Dan Guarracino]

I've had a report of this on 3.11.3 and replicated it on a 3.11.1 test server. Chrome 123.0.6312.59.

Library A owns an item. The item is returned at Library B and put in transit to its home at Library A.

While the item is in transit (Transit 1), a patron places a hold on the title for pickup at Library C. When the item is checked in at Library A, Evergreen opportunistically grabs the item to capture it for the hold for pickup at Library C and puts it in transit to Library C (Transit 2!).

However, the staff member at Library A notices that the item has damage that needs to be repaired. The staff member uses the Cancel Transits function from the Actions menu on the Checkin Items screen.

When this happens, Evergreen cancels the transit that had just been received rather than the transit that had just been created to fulfill the hold at Library C. This means that Transit 1 (the inbound transit to Library A) has both a received time and then a cancel time some number of seconds / minutes later. This also means that Transit 2 (the outbound transit from Library A to Library C) has a send time, but not a cancel time. This means that Evergreen still believes the item is still in transit to fulfill the hold at Library C, though the hold still ends up targeting another copy.

This appears to happen only when the transit is cancelled from the checkin screen, not from other pages.

A few days later, after another item has fulfilled the hold at Library C, if Library A's item is checked in again at Library A, it will attempt to complete Transit 2 to fulfill the hold at Library C, exhibiting the behavior described in 2053255.

[Terran McCanna (tmccanna)]

This would definitely explain some really strange transit behavior we've seen but weren't able to determine the cause of!

[Galen Charlton (gmc)]

Also confirmed. Looks like it affects the AngularJS renewal page as well, but if you're using that page, you are probably less likely to end up in a situation where you need to cancel a newly-created transit.

The problem appears to be that the variant of open-ils.circ.transit.abort that accepts one or more transit IDs is being used, but is passed the older transit (instead of or in addition to) the new one. When given a transit_id, open-ils.circ.transit.abort does not verify whether the transit has been received before marking it as cancelled.

Looks like fix would be to send the item ID, not the transit ID(s), to open-ils.circ.transit.abort. That variant will look for transits that are actually open.

Noting a couple other things for consideration, possibly as separate bugs:

[1] It is possible for open-ils.circ.transit.abort to fail due to a permissions or policy exception, but the AngularJS interfaces don't catch that.
[2] All invocations of open-ils.circ.transit.abort that are called with a transit_id list should be checked.

[Galen Charlton (gmc)]

I also checked and verified that this bug is not present when cancelling transits from the item status page (though, annoying, it looks like that there are two different implementations of the item transit cancel action depending on whether you are in list view or item details view; however, both avoid cancelling a closed transit).