Webby: Transit slip printing with wrong information

[Blake GH]

Spawning a new bug because bug 1740537 is finished. We have upgraded to 3.0.9 which included the code for bug 1740537 and we are still getting transits to the wrong library and/or second checkin scan resulting in the correct information on the printed slip.

See comment https://bugs.launchpad.net/evergreen/+bug/1740537/comments/21

"Upgraded to 3.0.9 July 4th. We are still seeing transit slips getting printed with the wrong information. The second scan results in the correct information."

[John Amundson (jamundson)]

We are seeing way more items with multiple active transits in the web client. I was working on pinpointing why and I discovered a scenario that produced the wrong information on the transit dialog/slip even after the fix for bug 1740537.

I found that if an item has multiple active transits, and the newest transit belongs to a targeted/captured hold, the transit dialog and slip contain the following:
The library name of the newest destination and the holds address of the oldest destination.

Obviously I can't guarantee this is the only time this information becomes mismatched, but hopefully it's a step closer to solving the problem.

I ran this query to find items in my system that meet this criteria:

SELECT distinct copy.id as "Copy ID", copy.barcode as "Copy Barcode",
 ou1.name as "Destination 1", ou2.name as "Destination 2"
FROM action.transit_copy trans
 JOIN action.hold_transit_copy trans2 ON trans2.target_copy=trans.target_copy
 JOIN actor.org_unit ou1 ON ou1.id=trans.dest
 JOIN actor.org_unit ou2 ON ou2.id=trans2.dest
 JOIN asset.copy ON copy.id=trans.target_copy
 JOIN action.hold_request hold ON hold.id=trans2.hold
WHERE trans.source_send_time<trans2.source_send_time
 AND trans.dest_recv_time IS NULL AND trans.cancel_time IS NULL
 AND trans2.dest_recv_time IS NULL AND trans2.cancel_time IS NULL
 AND trans.dest<>trans2.dest
 AND hold.cancel_time IS NULL AND hold.fulfillment_time IS NULL
 AND hold.current_copy=trans.target_copy

The slip will print the name of Destination 2 and address of Destination 1.

See also bug 1775276 regarding the incorrect information displaying in the "Route To" field of Check In. If an item has multiple transits, the "Route To" field will only display the older destination.

Note that if you are testing this, you may want to refresh the screen after you check an item in. If a second item with multiple active transits is checked in, then sometimes "We do not have a holds address for this library." displays.

[Bill Erickson (berick)]

Thanks, John. This is certainly useful info. There should only ever be one active transit on a copy at a time and the user interface (and all of the other code) assumes as much. Any time multiple active transits exist, the behavior is undefined. Any insights into how the multiples are happening is appreciated.

[John Amundson (jamundson)]

Opened a new bug regarding active transits in the web client: https://bugs.launchpad.net/evergreen/+bug/1787274

[Terran McCanna (tmccanna)]

John - You may have already tried this, but when we implemented the patch for the incorrect transit slips, we had to ask staff to clear browser cache if they were still seeing the problem. We haven't had any reports of problems after cache clearing.

[Blake GH (bmagic)]

Browser full refresh is almost always the issue with this. We are no longer seeing this issue in 3.1.10. It might be time to close this bug.

[Terran McCanna (tmccanna)]

This doesn't appear to be an issue any longer.