© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
demo site
(Get the code!)
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.