Web Client: Check In - "Route To" Field Sometimes Incorrect

[John Amundson]

Web Client - Evergreen 3.0.8

When an item is checked in from delivery and needs to go to a different library, the "Route to" column on the Check In screen shows the current library instead of its destination. If the item is checked in again, the correct information is displayed, as seen in the attached screenshot.

This only seems to happen if the item is in transit upon check in and is then sent in transit somewhere else.

This behavior is very similar to bug #1740537 but was not fixed by its patch.

I am able to replicate this issue every time with the following steps:
1. Sign in as Library A.
2. Check in an item owned by Library B that does not have any holds associated with it. This will send the item in transit to its home, Library B.
3. Place a hold on the item to be picked up at Library C.
4. Sign in as Library B.
5. Check in the item. [Upon check in, the item should show a "Route To" of Library C, but instead...] the column shows that the item needs to be transited to Library B instead of Library C.

[John Amundson (jamundson)]

We are also finding this is true for items "coming home". If an item is owned by Library A and is in transit to and checked in by Library A, the Route To field will display Library A on the first scan and then the item's shelving location on the second scan. See attached image.

[John Amundson (jamundson)]

We continue to have libraries report this bug to us. A good portion of our libraries seem to use this field to make sure they are handling items correctly after the check-in.

[Anna Goben (agoben)]

Just a quick note to confirm that we're still seeing this in 3.2.

[Terran McCanna (tmccanna)]

Yes, PINES is no longer getting the incorrect routing slips but we are still getting incorrect routing libraries on the check-in screen in 3.2.3.

[Michele Morgan (mmorgan)]

We are also seeing incorrect 'route to' information displayed on the checkin screen in our 3.2.4 system.

[Dan Briem (dbriem)]

If open-ils.circ.checkin closes a transit and creates a new one (for example, opportunistic hold capture for another location), the return payload only contains the closed transit. The route dialogs perform a pcrud search to get the most recent transit, but the grid's Route To field still depends on the transit returned by the API. So, the dialog and receipt display the new destination, but the grid's Route To field displays the old destination.

Branch for testing: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbriem/lp1775276_route_to_sometimes_incorrect

It returns the newest route data collected from the route dialog and, if the transit destination doesn't match the payload, assigns the new transit destination shortcode to the route_to prop on the final_resp. Also, it checks that the payload transit is open before assigning the final route_to prop so the shelving location displays for received transits.

[John Amundson (jamundson)]

Thank you for your work on this, Dan. Our libraries will be happy!

I have tested your code on a 3.4 system and could not break it. The "Route To" field displayed accurately every time, and I did not notice any slowdowns.

I have tested this code and consent to signing off on it with my name, John Amundson, and my email address, <email address hidden>.

[Jason Stephenson (jstephenson)]

Thanks for testing, John!

I have pushed a rebased branch with John's signoff and mine to the working repository:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/dyrcona/lp1775276_route_to_sometimes_incorrect-signoff

In addition to adding our signoffs, I edited the commit message slightly. I reformatted it to fit our guidelines and general recommendations of the git community. I didn't change the wording other than removing the words "web client" from the subject line.

I intend to push this to the master repository in a few days unless someone else wants to have a look.

[Jason Stephenson (jstephenson)]

Pushed to master, rel_3_3, and rel_3_4.

Thanks, Dan and John!