https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38806
Benjamin Daeuber <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #5 from Benjamin Daeuber <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
