[Bug 6619] New: pressing enter when hold found at checkin causes issues
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6619 Bug #: 6619 Summary: pressing enter when hold found at checkin causes issues Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Circulation AssignedTo: oleonard@myacpl.org ReportedBy: wizzyrea@gmail.com QAContact: koha-bugs@lists.koha-community.org CC: gmcharlt@gmail.com if you hit enter when presented with a "confirm hold" dialog, it doesn't confirm or ignore the hold, but it does close the transfer. There is also the issue presented in this discussion on IRC: http://stats.workbuffer.org/irclog/koha/2011-04-26#i_654179 which is: scanning a 2nd item (with a barcode scanner CR) while a "confirm hold" dialog is present doesn't check in the 2nd item *or* confirm or ignore the hold. The net result of this is as follows: An item that has an incoming transfer and a hold will have the transfer closed but the hold will go into oblivion (unless it is rescanned and confirmed through clicking). An item that doesn't have an incoming transfer and only a hold will go into oblivion, unless properly processed by clicking. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6619 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|3.6 |master --- Comment #1 from Owen Leonard <oleonard@myacpl.org> --- (In reply to comment #0)
if you hit enter when presented with a "confirm hold" dialog, it doesn't confirm or ignore the hold, but it does close the transfer.
This aspect of the bug is still true. I don't know if my librarians would consider what they do as "working around a bug" or just working with Koha's workflow as it is designed.
which is: scanning a 2nd item (with a barcode scanner CR) while a "confirm hold" dialog is present doesn't check in the 2nd item *or* confirm or ignore the hold.
So: Check in something on hold, don't confirm, proceed directly to checking in a second item which is checked out? I do not find that there is a problem with the check-in aspect of this transaction when I test it. The book is properly returned. Or do I misunderstand? -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6619 Liz Rea <liz@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |In Discussion CC| |liz@catalyst.net.nz --- Comment #2 from Liz Rea <liz@catalyst.net.nz> --- I will have to retest this - certainly I think it was the case in 3.6 or a pre-release version of 3.8. There has been some work done in that area, so i'll try to check it again. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon@bugs.koha-community.org