"Find Another Target" creates network failure on in-transit holds
Bug #1012690 reported by
Thomas Berezansky
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Evergreen |
Fix Released
|
Medium
|
Unassigned | ||
| 2.1 |
Fix Released
|
Medium
|
Unassigned | ||
Bug Description
Looks to be an issue with the transit abort function committing the transaction when we don't want it to. The branch below contains a fix.
| Changed in evergreen: | |
| assignee: | nobody → Lebbeous Fogle-Weekley (lebbeous) |
| status: | New → In Progress |
| milestone: | none → 2.2.0 |
| importance: | Undecided → Medium |
Revision history for this message
| Lebbeous Fogle-Weekley (lebbeous) wrote | #1 |
| Changed in evergreen: | |
| status: | In Progress → Fix Committed |
| assignee: | Lebbeous Fogle-Weekley (lebbeous) → nobody |
| Changed in evergreen: | |
| status: | Fix Committed → Fix Released |
To post a comment you must log in.
Tested well. The feature probably needs a rethink in the future, but at least it works where it couldn't have worked before.
Signed-off and backported through 2.1 series.
> 10:37 < senator> tsbere: your branch works as advertised. just ooc i guess, if
> staff at pickup lib retarget a hold that's already in transit
> from some other lib, what does staff at pickup lib do when
> they get a copy that the system no longer thinks was in
> transit to them?
> 10:38 < senator> well, i guess they check it in and it still goes home
> 10:39 < tsbere> senator: I disagree with these copies going to "reshelving",
> but that isn't an error generating thing. I am thinking a new
> status is needed for "transit was aborted". Like, say,
> "transit_aborted". At checkin it gets treated like reshelving,
> but until then I don't think those copies should be considered
> holdable.
> 10:40 < tsbere> senator: Plus then you can run reports on aborted transits that
> nobody ever checked in again