Feature Request: "Canceled Transit" Item Status

Hi Chris,

Would you consider this report a duplicate of https://bugs.launchpad.net/evergreen/+bug/1306666? I was going to mark it, but, since the proposed solutions are a little different, I held off.

Kathy

Okay, after some discussion on bug 1306666, it was agreed that this is a separate issue, though the way this issue is resolved probably depends on the way the solution to bug 1306666 gets implemented. My current branch is here:

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

I think this approach works well to address the original use case reported in bug 1306666:

An item belonging to "Adams Branch" is in transit to fill a hold at "Baker Branch". The Baker Branch patron no longer wants the item, and a staff user at Baker Branch cancels the hold and chooses to abort the transit when prompted, the item appears to now be on the shelf at Adams Branch, and can appear on Adams Branch's pull list if there are additional holds.

Jason's branch on 1306666 is important, but addresses a different problem, where hanging transits can update item statuses inappropriately when aborted, sometimes derailing circulations.

I've updated the description on bug 1306666 to fit better with Jason's code.

I took a look at this branch. I think the new "Canceled transit" status will certainly give staff a better picture of the item's *true* status.

An initial observation, the new status would get default values of "false" for holdable, opac_visible, copy_active and restrict_copy_delete.

I would suggest that "Canceled transit" should have:

holdable: true
opac_visible: true

This differs from "In transit" only in restrict_copy_delete. I think it's appropriate to allow the deletion of items in "Canceled Transit" status.

Another question that comes to mind is, how should/would an item with "Canceled transit" status appear in the alternate view of item status? I would say that the canceled transit should display in the Holds/Transit tab when the item is in that status.

Michele,

I've updated my branch with the suggested changes to holdability and opac-visibility. I was wondering about that myself.

As to the alternate view issue, I would suggest a separate bug report (contingent on this one being accepted, of course). I would imagine adding it to the alternate status screen would not be trivial and might involve some redesign of that screen (in both the XUL and web clients), and I wouldn't want this feature held up by that if possible.

Thanks for testing and for your feedback!

Chris

Just adding a link to the branch with the holdability and opac-visibility changes:

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

Thanks, Michele. I just force-pushed some changes to the above branch, FYI. Please test and let me know how it goes for you.

I tested this code and it looks good. Here's my testing plan:

With
item1 belonging to br1
item2 belonging to br1
item3 belonging to br2
item4 belonging to br2

At br1, create transits

- Checkin item1 with a hold at br2 - item1 goes in transit to fill hold
- Checkin item2 with a hold at br2 - item2 goes in transit to fill hold
- Checkin item3 needing to go home to br2 - item3 goes in transit
- Checkin item4 needing to go home to br2 to fill a hold - item4 goes in transit

Abort transits:

- Cancel hold on item1 and abort transit when prompted - item1 gets Canceled Transit status
- Abort transit on item2 (do not cancel hold) - item2 gets cancelled transit status
- Abort transit on item3 - item3 gets Canceled Transit status
- Abort transit on item4 - item4 gets Canceled Transit status

Checkout Canceled Transit items:

- Checkout item1, item2, item3, item4 - COPY_NOT_AVAILABLE - Force action, checkout proceeds normally.

Repeated steps above to set item1, item2, item3, item4 to Canceled Transit status.

Checkin Canceled Transit items:

- Checkin item1 - item1 goes into Reshelving status
- Checkin item2 - item2 goes in transit to fill hold
- Checkin item3 - item3 goes in transit home
- Checkin item4 - item4 goes in transit home

Magical Status:

- Edit item Attributes for an item in Canceled Transit status - status field is not editable

Checkout an In transit item:

- Checkout item3 at br2 when in transit from br1 to br2
- Click Abort Transit, then Check Out
- COPY_NOT_AVAILABLE - Force action, the copy checks out

I attempted signing off on this, but there's a merge conflict. I'll be happy to sign off if the conflict is resolved, or leave that to anyone else who's willing.

Thanks for working on this, Chris!

We've been discussing, mainly on bug 1306666, what should happen to the copy status in various transit-abort contexts. I don't think we have consensus yet on all situations -- particularly the "remote abort of a return transit" case. I think the effect of this branch should be constrained to the "remote abort of a hold transit" situation, as that one forces the item into Reshelving today. The outcome of an remotely aborted return transit is less clear, though, as it does normal status unwrapping. So, we could be throwing away, among others, a Damaged status change.

Would it make sense to /only/ change the status to Canceled Transit if the final result status would have been Reshelving?

Thanks...

tl;dr: At the user level, it seems it would look like Canceled Transit always overwrites intentionally applied special copy statuses, which seems at least as bad as the current situation.

The series of steps I'm concerned about looks like this:

1) item in status Damaged (or like "important" status)
2) item gos in-transit for home
3) transit is aborted, item gets Canceled Transit status
4) "important" status is lost

Chris mentioned his "cancel don't abort" branch, which which keeps aborted transits around rather than deleting them, but that's not exposed to the user. Even so, it's not clear that it's always safe to use an old canceled transit's status in the future, so I think recovering the old status that got "lost" with the application of Canceled Transit upon abort would be a manual process.

I hope that helps explain my concern.

Okay, I pushed a change that checks for non-special item statuses (those that would just result in "Reshelving" status at checkin) and only marks *those* with the Canceled Transit status. My testing shows a Damaged item (one of the "special" statuses) does *not* get marked Canceled Transit, but is returned to Damaged status as expected.

Please let me know if there's more you think this needs!

Thanks,

Chris

I'm not able to explicitly test this last commit, but am comfortable with the latest changes and Chris's test of same. Here's my signoff branch:

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

Pushed to master. I'm going to brazenly assign this to Chris and request release notes.

Thanks, Chris!

Oh, it's already assigned to him. PERFECT!

Mike,

Release notes added to the top of my working branch. Thanks!

Chris

I've merged Chris' Release Notes to master. Thanks Chris!