Comment 3 for bug 1779467

Hi Jason,

Regarding the points in comment #1:

1) I think this is probably correct /except/ for marking an item Lost. In that case, we're "blaming" the patron and it should stay on their items out list.

2) +1, that seems it will provide the flexibility to deal with future UIs where we might want to /not/ force a checkin -- and even provide a hook for a YAOUS to specify that behavior for existing UIs (as in, a set of "don't check in on marking BLAH" YAOUSen).

3) I disagree with canceling transits generally, not just for the feature you're working on. Since we have the barcode value available, then especially for marking discard/weed, but also for other statuses, I don't understand why we aren't simply changing the copy_status field on the transit. Then the transit will either naturally finish, and the copy will get the new status and trigger the routing event at checkin, or the barcode can be checked in if the copy is in hand. It's an extra step in the case of a copy that has disappeared while in transit, but it also avoids throwing out state information about the copy's location (on a truck). All that said, the deciding evidence would be whether it is more common for a copy to be lost in transit than to simply still be in transit. If lost-in-transit is more common, then I see the argument for canceling the transit. Otherwise, it just seems wrong -- the right thing will happen at the right time when the copy shows up.

4) Is this meant to allow editing of action.transit_copy.copy_status rather than canceling, or just to prevent the action via an event in the face of an outstanding transit? If the former, +1. ;)

5) Thanks

6) +1

Thanks!