Cancel transits on checkin screen cancels wrong transit
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Confirmed
|
Medium
|
Unassigned |
Bug Description
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.
This would definitely explain some really strange transit behavior we've seen but weren't able to determine the cause of!