https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38806 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emily.lamancusa@montgomeryc | |ountymd.gov --- Comment #1 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- 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). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38806 --- Comment #3 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- (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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38806 --- Comment #4 from Victor Grousset/tuxayo <victor@tuxayo.net> --- Let's see if over time other people have that issue or something related, and find this ticket. Otherwise it could be closed if forgotten for long enough. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38806 Benjamin Daeuber <bdaeuber@cityoffargo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bdaeuber@cityoffargo.com --- Comment #5 from Benjamin Daeuber <bdaeuber@cityoffargo.com> --- (In reply to Victor Grousset/tuxayo from comment #2)

"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 ^^"

The most common scenario for us is that we discover an item is damaged or missing pieces after the transfer has been initiated. If that's the case, the easiest thing for the staff person to do is check in the item again and cancel the transfer. We've also had scenarios where a branch has been temporarily closed (for a few days or a week) and rather than go through the whole setup of changing or suspending holds, it's easiest just to cancel the transfer and deal with it later. I'm mostly replying to this because of Bug 38789, so I'm not sure how important the button is in this specific scenario (the third or fourth checkin), but I'm also somewhat baffled by the criss cross of intersecting modal issues at this point. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38806 Rebecca Coert <rcoert@arlingtonva.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rcoert@arlingtonva.us -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38806 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |lisette@bywatersolutions.co |ity.org |m CC| |lisette@bywatersolutions.co | |m -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38806 --- Comment #7 from Lisette Scheer <lisette@bywatersolutions.com> --- This works for me in main. I'm not sure if there's a step I'm missing somewhere in here. Is anyone still having this problem on main? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38806 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@openfifth.c | |o.uk --- Comment #9 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- The original test plan here was written before bug 38789, bug 38793, and bug 38588 were pushed to fix several related issues with transfer modals, which is definitely adding to the confusion! The original test plan no longer occurs as written now that those bugs have been pushed. If I'm understanding the issue Sally is describing correctly, it should have been fixed by bug 38793, which is in 24.11.03. It also depends on the browser - the bug happens in Firefox, but not Chrome or Chromium (I don't know if it's been tested in any other browsers). The question on this bug was specifically for the situation where you have an item with a transfer that was requested but not confirmed/sent (shown as "Transit pending" on the item holdings table), and then you check it in - is a Cancel button needed in that specific situation? The only situation that I know of where an item is supposed to have "Transit pending" status is if a transfer was queued up by the Stock Rotation module. I'm not very familiar with the Stock Rotation module, so I don't know if the Cancel button was intentionally left out in that situation because requested Stock Rotation transfers are not supposed to be cancellable, or if it just wasn't a focus and can be safely added. (CCing Martin to weigh in on this) Is anyone seeing an issue that is not related to items in the "Transit pending" status (or an issue where items are being set to "Transit pending" when they shouldn't be), and is on 24.11.03 or later? If so, can you tell us your exact Koha version and describe step-by-step how to reproduce the issue? I think that's the only way we'll be able to tell if there is still a bug in need of fixing, or if it's one of the related bugs that are fixed in a newer version. -- You are receiving this mail because: You are watching all bug changes.