Route to Column In Checkin Screen Confusing when there are back to back transits

Bug #1825358 reported by Rogan Hamby
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
New
Low
Unassigned

Bug Description

I'm torn as to whether to classify this as wishlist or bug. The existing code works but there is a circumstance it's very confusing in. As items are checked in that are part of a transit into a location that transit is consistently shown under the "Route To" column of the checkin screen. If that same item is immediately transiting out in the same transaction then the original is still shown into instead of where it is routing.

Normal circumstance:

"The Hound of The Baskervilles" has been loaned out from West Library to East Library. It checks in, transits home to West Library and shows Route To West Library on the checkin screen because that is the Route To in the transaction in the action.transit_copy table.

Problematic circumstance:

As before but while transiting home to West a hold is placed on the item and it is the only copy to fill the hold at East Library again. Now there are two entries in action.transit_copy table tied to that transaction, one being written with a receive time (incoming to West from East) and one with a start time (outgoing from West to East). When the hold is checked in it will show Route To West library even though a hold slip now prints for East Library and it in fact does route to there, correctly. So, everything works correctly but the screen display is confusing to staff because the Route To column shows the incoming transit not the outgoing one.

Changed in evergreen:
importance: Undecided → Low
Revision history for this message
John Amundson (jamundson) wrote :

I'm marking this a duplicate of bug #1775276.

I would 100% personally consider this a bug. The web client behavior differs from the XUL client, and the "Route To" field is even incorrect when the item is being checked in an the destination-home library. In the XUL client, the shelving location would appear in this field. Now the library displays.

A second check-in fixes the display.

More details in bug #1775276

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.

Revision history for this message
John Amundson (jamundson) wrote :

I'll also not that bug #1775276 hasn't been marked as "confirmed" yet...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.