Route to Column In Checkin Screen Confusing when there are back to back transits
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 |
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.