When Aborting a Transit, items should not automatically get a status change.

[Michele Morgan]

When a staff user aborts a transit on an item, the item's status is updated as follows:

set to Reshelving, if it's a hold transit
set to the last status prior to the transit if it's a home transit.

There can, for various reasons, be "hanging transits" on an item that did not get closed out properly. These can hang around for some time. Aborting these hanging transits will apply an inappropriate status change to items that are not currently in transit.

This can potentially break active circulations and cause confusion due to inexplicable item status changes.

[Rogan Hamby (rogan-hamby)]

This has been a long standing (though minor) annoyance for me as well. Making sure new transit slips are appropriately generated will be critical for front line staff as well.

I would think we would want it to behave appropriate per floating collections rules as well. If it's transited between two locations that share a floating collection I don't want it sent back unnecessarily.

[Jason Stephenson (jstephenson)]

Another fun thing is if you end up with "hanging" transits, i.e. an old, incomplete transit hanging around on a copy. I don't know how this happens, but it seems to occur on our system with some frequency. Staff will sometimes abort those old transits without first checking the status of the copy. We've had a few checked out copies end up in reshelving status without closing the circulation that way.

[Jason Stephenson (jstephenson)]

I consider this a bug. It is a logical error in the code, though it may have been the intended behavior, that behavior is potentially dangerously incorrect.

[Jason Stephenson (jstephenson)]

We just got hit with this again when a checked out copy had an old transit aborted.

I plan to work on a fix for this, so I'm seeking some consensus on a solution.

My preference is to simply see this behavior go way, i.e. when a transit is aborted, the status of the copy is left untouched.

At most, I could live with only changing the copy status if its status is currently "In Transit."

I'd also rather not have an org. unit setting for this.

Discuss or I decide. :)

[Michele Morgan (mmorgan)]

My current thoughts on this:

"Abort transit" should NOT do anything to the status of a copy that does not have status In transit.

For a copy with status In transit, aborting a transit should remove the transit in question, and essentially perform a Checkin, creating a new transit if an item isn't at home, or capturing a hold and setting in transit to the pickup point.

No copy should ever be allowed to have two associated open transits.
No copy should have an open transit without also having the status In transit.

My real preference would be to make the option to "Abort Transit" go away altogether and have the Checkin process evaluate whether a current transit is still valid, or if a different one, or none at all, is required. The Checkout process should also close an open transit.

[Jason Stephenson (jstephenson)]

Michele,

For my purposes, I am focusing solely on the copy status being changed when a transit is aborted. I have a small branch that stops the copy status from changing if it is not already in transit.

I want to add some Perl tests and then I'll turn it loose on the world.

Jason

[Jason Stephenson (jstephenson)]

Oops! Wrong bug number.

[Jason Stephenson (jstephenson)]

I have a branch that stops the copy status from changing, unless the copy status is "In Transit."

user/dyrcona/lp1306666-abort-transit-item-status in the working repo

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1306666-abort-transit-item-status

I would have posted sooner, but the tests took a while to write.

[Kathy Lussier (klussier)]

It took me a long time to find a series of steps that would cause a hanging transit to occur while the copy was in another status, particularly a checked out status. I finally was able to do so by 1) putting the copy in transit to fill a hold, 2) marking the copy damaged, 3) forcing the damaged copy into circulation again to another patron and 4) aborting the transit from the item status screen.

I can confirm that Jason's patch stops the copy from moving to a Reshelving Status, and I agree this is a bug that should be fixed.

However, I don't think this patch addresses the original problem reported on the bug. The problem reported here was for actively in-transit copies where the transits are aborted from another location, throwing the copy into a reshelving status when the copy isn't even at its home library.

Would it make sense to file a new bug on the hanging transit status issue to which this patch can be added? I just don't want to lose track of the original problem if this bug eventually gets to a Fix Committed/Fix Released status.

[Jason Stephenson (jstephenson)]

Currently, only the sending or receiving library can abort a transit, unless the ABORT_REMOTE_TRANSIT permission is granted. Not granting that permission at least keeps the ability to about down to either the library that supposedly sent or supposedly received the item.

We, at MVLC, do not assign that permission to staff, so we don't run into the original issue as often. We sometimes get asked by the library that owns a copy to abort transits for their copies that went between two other libraries, usually when they have the copy in hand.

Unfortunately, Evergreen has no way of knowing where the copy actually is. It sometimes has to trust that the staff know what they are doing. (Just to anthropomorphize things a bit.)

I think that the original code assumed that the copy was indeed in transit, and that whoever had the copy in hand would be the one aborting the transit. There also appears to be an expectation that the copy will be checked in again to see if it needs to go elsewhere after the transit is aborted.

A better option might be to put the copy in some status that allows it to capture holds or be checked in normally. Reshelving currently fulfills that role.

So not arguing against changes to my code, but trying to clarify what might need to be done.

[Jason Stephenson (jstephenson)]

A little "esprit de l'escalier" before I head out to a meeting.

Perhaps, a copy's status should not be changed at all when aborting a transit. I say that because the software really cannot know what is going on or who has the copy when the transit is aborted. It may be best to just leave the copy status alone and let a human sort it out later if it becomes a problem. Just another thought on the matter.

[Jason Stephenson (jstephenson)]

Given this some more thought and considering Michele's comment about doing a circulation, I have a slightly different idea.

My thought is to alter my branch a bit more so that a copy's status is only changed to reshelving when the copy has an in transit status and the transit is aborted at the organization that "owns" the copy, i.e. the copy's circ lib.

My thinking behind this is that we cannot count on much of anything if the transit is aborted somewhere other than at its home. Usually, transits are aborted by someone who has the copy in hand, but that is not always the case. Typically, if the copy is in some "limbo" state after having the transit aborted, a check in will clear it up. Some more testing may be required to verify this.

I'm not inclined to have the abort transit code try a check in because that could possibly lead to more problems depending on the other variables.

Also, it may be tricky to have check in clear hanging transits. Part of the check in process is to look for transits and hold transits to see if the book should be routed elsewhere. When checking in a book at a library other than the source or the destination of a transit, it could be difficult for the software to figure out what to do. It could happen that a copy was delivered to the wrong library, maybe it fell into the wrong bin or something, and needs to be routed somewhere else.

So, I'll update the branch a bit later with the change mentioned above. Does that better meet the need identified in the initial report?

[Jason Stephenson (jstephenson)]

OK. I force-pushed a rebased version of the branch with an additional change to only set the copy status if the status was both in transit and the action is done from the copy's home library (circ_lib).

I also renumbered the test file name.

I should add another test for the status not changing if the abort happens from somewhere other than the copy's circ lib. The existing tests still pass.

[Jason Stephenson (jstephenson)]

I pushed additional tests in another commit, so it is the top 4 commits in the branch. I left the new code based on the comments as separate commits so that they are easy to revert.

I'm also leaving the release notes until the functionality settles down and everyone is happy with it.

I'm re-adding the pullrequest tag to request testing because I think it is ready for inclusion in mainline.

[Kathy Lussier (klussier)]

Hi Jason,

I took a look at this code today.

I tested the workflow first identified in Michele's bug report, where a hold is canceled while the copy is in transit and staff select the option to abort the transit. The copy remained in transit, which is good.

I didn't get a chance to test the hanging transit issue again.

However, I also tested a scenario where the copy is in transit back to its home library, but the transit source attempts a checkout on the item. With the new code, staff are unable to abort the transit at this point, and the checkout fails. I think this is one case where you do want the status to change.

I think it might be good to identify a set of use cases where transits can be aborted and whether the system should be changing the status. I think Michele's list is a good start, but there may be others.

[Terran McCanna (tmccanna)]

What do the rest of you think of Chris's idea (https://bugs.launchpad.net/evergreen/+bug/1613374) to have a new Canceled Transit status rather than trying to determine which other imperfect status for it to go into?

I like the simplicity of it, and it would make it more easily reportable.

[Jason Stephenson (jstephenson)]

A new status is fine with me, but it will add to the work of fixing this bug. Many places in Evergreen check for copies with a list of statuses and those places will need to be examined to determine if this new status should be included in those lists.

Also, I'd prefer the copy status to not change unless it is In Transit at the time the transit is aborted. I would trust the copy status before I trust the presence of a transit being indicative of what's really going on with a copy.

[Chris Sharp (chrissharp123)]

Here is my working branch, which should be considered in-progress:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/csharp/lp1306666_canceled_transit_item_status

I have added logic to only change the status if the transited copy is actually "In transit" as Jason suggests. I have also added the status to the "magical statuses" list (thereby disabling it in the copy editor). I am actually unaware of other places that need checking, so I'd appreciate pointers if someone knows what else I need to change.

Thanks!

[Jason Stephenson (jstephenson)]

Mike made a modification to my branch today and shared it here:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp1306666-abort-transit-item-status

I have not had time to test it, but the code looks OK.

At this point, we should maybe have a discussion on the approach to this. If Chris wants to add a canceled transit status, then we should probably consider that now rather than later.

[Chris Sharp (chrissharp123)]

My concern about leaving the status "In transit" is that it's kind of lying about what's actually happening for items whose transits have been aborted/canceled. The "Canceled Transit" status would be a clear indicator of what happened. If others disagree, I can probably be convinced that it's not necessary, but staff confusion about what the heck happened to their items is what originated our interest in this bug, and I'm not sure leaving the copy in "In transit" status fully accomplishes that. Maybe my bug 1613374 should be considered a separate issue after all?

[Mike Rylander (mrylander)]

Chris, I agree the use of a new "marker" status makes sense, if this is the route we want to go. The name "Canceled Transit" is fine by me.

[Mike Rylander (mrylander)]

And, yes, I think your branch is a separate issue, and worthwhile.

[Michele Morgan (mmorgan)]

I updated the description of this bug to better fit the hanging transit problem Jason's code is addressing. The new status proposed in bug 1613374 should address the issue in the original description of this bug.

Also including a link to a relevant IRC discussion:

http://irc.evergreen-ils.org/evergreen/2016-08-16#i_261624

[Mike Rylander (mrylander)]

To be clear, all branches currently proposed go far beyond avoiding the "hanging transit" issue. To address that, we need only check that the copy is in the "In Transit" status before doing any (existing or new) status mangling.

Because there is no consensus on what the outcome should actually be to the further discussion we've had on the adjacent issues, I propose we fix the OP's stated bug of "hanging transits" damaging circs, and open a separate bug to address how or if we'll change the current "transit unwrapping" behavior in the case of a remote abort.

Input appreciated, and I'll address the core issue as stated here if I get general agreement.

[Jason Stephenson (jstephenson)]

Mike, that works for me.

[Mike Rylander (mrylander)]

I've picked the first two original commits from Jason's branch, which make the minimal change needed, and supply tests to be sure remote abort of a hanging transit doesn't harm circs.

Thanks, everyone, for working on this. I'll start a new bug with the remainder of this.

[Mike Rylander (mrylander)]

I've also backported this to 2.10, but not 2.9.

[Jason Stephenson (jstephenson)]

I'll backport to 2.9 from master to preserve signoffs.