webstaff Most Recent Transit display in item status may mislead with canceled transit
Bug #1738688 reported by
Jason Etheridge
on 2017-12-18
This bug affects 3 people
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | Evergreen |
Undecided
|
Unassigned | ||
Bug Description
The Most Recent Transit display in the webstaff Item Status -> Holds / Transit pane does not indicate whether the transit being displayed is canceled or not, which can make a canceled transit look the same as an unreceived transit. One mitigating factor is that the item status may show Canceled Transit, though that's not guaranteed, and it's not prominently displayed at that point.
To post a comment you must log in.
I also agree that not knowing whether the transit on the screen has been cancelled or is current is not ideal.
Certain workflows, (such as manual copy status updates), can lead to an item that has an active transit but not a status of in-transit. For troubleshooting, it is important to know if the transit on the screen is active or cancelled. Simply adding the Cancel time box to the screen could solve this problem, (see attached mock-up).
In the same vein as this, we have also had certain items with multiple active transits, (see lp 1505772). These active transits are not always the most recent, and the new interface of the web client makes it impossible to tell if there are any old "stuck" transits that need to be cancelled.
The XUL client would only show transits that were active. Perhaps the web client could show...
- Most recent active transit, (NULL receive time, NULL cancel time), if one exists.
- If no active transits exist, it could show the most recent transit.
If this secondary request should exist as a separate bug, let me know.
The addition of seeing the cancelled/received transits in the web client is a great addition for troubleshooting, but the current structure prevents other troubleshooting that used to be possible.