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.
(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?
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.
Still valid?