Summary: | Dismissing a "Wrong transfer detected" modal leads to transfer not cancelable anymore | ||
---|---|---|---|
Product: | Koha | Reporter: | Victor Grousset/tuxayo <victor> |
Component: | Circulation | Assignee: | Bugs List <koha-bugs> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | major | ||
Priority: | P5 - low | CC: | emily.lamancusa, gmcharlt, kyle.m.hall |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38789 | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: |
Description
Victor Grousset/tuxayo
2024-12-30 19:33:26 UTC
Thanks for reporting, Victor! Step 7 - this is the expected behavior if AutomaticConfirmTransfer is off (which it is in the default test data). Step 10-12 - clicking OK wasn't confirming the transfer, so it was getting stuck in a pending transfer state. Are you still seeing this behavior with the patches from bug 38588 applied? When I test with those patches, what I see is: 10. Click ok 11. Check the item in again 12. Wrong Transfer modal appears again (which still doesn't allow canceling at the moment because the Cancel button on the Wrong Transfer modal doesn't work, but we have bug 38793 for that) Step 9 - As far as I can tell, this has been the behavior ever since the concept of a pending transfer was introduced in bug 23092 - it's not a new regression like the others. We could probably add an option to cancel from that modal if there's a need for it though (unless that would cause unwanted side effects with the Stock Rotation module - I don't know the ins and outs of it off the top of my head but I know it's one of the main use cases for the concept of a pending transfer). (In reply to Emily Lamancusa (emlam) from comment #1) > Step 7 - this is the expected behavior if AutomaticConfirmTransfer is off > (which it is in the default test data). Good, nothing to see here :) > Step 10-12 - clicking OK wasn't confirming the transfer, so it was getting > stuck in a pending transfer state. Are you still seeing this behavior with > the patches from bug 38588 applied? No! :D Cool, 38588 fixes the 2nd issue. I might have seen the 1st issue with 38588 and then did my testing on main for reporting here. > When I test with those patches, what I > see is: > 10. Click ok > 11. Check the item in again > 12. Wrong Transfer modal appears again With the cancel button I suppose. Yes, that's what I got. > (which still doesn't allow canceling at the moment because the Cancel button > on the Wrong Transfer modal doesn't work, but we have bug 38793 for that) For me it works with just bug 38588. The issue on step 12 isn't here anymore :D > Step 9 - As far as I can tell, this has been the behavior ever since the > concept of a pending transfer was introduced in bug 23092 - it's not a new > regression like the others. We could probably add an option to cancel from > that modal if there's a need for it though (unless that would cause unwanted > side effects with the Stock Rotation module - I don't know the ins and outs > of it off the top of my head but I know it's one of the main use cases for > the concept of a pending transfer). "if there's a need for it though" Oh, so the only issue remaining here with bug 38588 applied would be mostly a weird behavior? Is the scenario relevant enough to still be considered a bug? Otherwise that would be a UX enhancement. In other words, is it really a problem vs the other tickets in this area. I'm not a librarian so I might find bugs or bad UX that aren't that relevant ^^" (In reply to Victor Grousset/tuxayo from comment #2) > For me it works with just bug 38588. The issue on step 12 isn't here anymore > :D I do still reproduce bug 38793 (cancel button doesn't cancel) with 38588 applied, but only with TransfersBlockCirc set to "don't block" and AutomaticConfirmTransfer set to "do". If I leave the sysprefs at their default values, then it works as expected. > "if there's a need for it though" > Oh, so the only issue remaining here with bug 38588 applied would be mostly > a weird behavior? > Is the scenario relevant enough to still be considered a bug? Otherwise that > would be a UX enhancement. > In other words, is it really a problem vs the other tickets in this area. > I'm not a librarian so I might find bugs or bad UX that aren't that relevant > ^^" I'm not sure either! Our library system doesn't have any situations where we generate unsent transfers intentionally, so I can't really say how important/desirable it is to be able to cancel an unsent transfer at checkin. |