webstaff Most Recent Transit display in item status may mislead with canceled transit

[Jason Etheridge]

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.

[John Amundson (jamundson)]

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.

[Kathy Lussier (klussier)]

A working branch that adds the Cancel Time to the display is available at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp1738688-add-canceled-transit-time-to-most-recent-transit

John, I didn't address the secondary request. I would recommend adding it in a new bug.

[John Amundson (jamundson)]

I plan on testing this fix on Wednesday.

In the meantime, I've spun off my other concerns into this bug: https://bugs.launchpad.net/evergreen/+bug/1791828

[Joan Kranich (jkranich)]

Hi John,

For the transit list idea are you thinking of a limit to the number of
transits that would display?

What do you use to create the mockup?

Thanks.
Joan

On Mon, Sep 10, 2018 at 5:02 PM, John Amundson <email address hidden>
wrote:

> I plan on testing this fix on Wednesday.
>
> In the meantime, I've spun off my other concerns into this bug:
> https://bugs.launchpad.net/evergreen/+bug/1791828
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1738688
>
> Title:
> webstaff Most Recent Transit display in item status may mislead with
> canceled transit
>
> Status in Evergreen:
> Confirmed
> Status in Evergreen 3.0 series:
> Confirmed
>
> 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 manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1738688/+subscriptions
>

--

​​

Joan Kranich | Member Services Supervisor

CW MARS

<email address hidden>

508-755-3323 x321 or x1 <(508)%20755-3323>

http://www.cwmars.org

[John Amundson (jamundson)]

This is great, Kathy.

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

[Galen Charlton (gmc)]

Pushed to master, rel_3_1, and rel_3_0. Thanks, Kathy and John!