Bug 6619 - pressing enter when hold found at checkin causes issues
Summary: pressing enter when hold found at checkin causes issues
Status: CLOSED INVALID
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: master
Hardware: All All
: P5 - low minor (vote)
Target Milestone: ---
Assignee: Owen Leonard
QA Contact: Bugs List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-20 21:54 UTC by Liz Rea
Modified: 2017-06-14 22:11 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Bot Control: ---
When did the bot last check this:
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Liz Rea 2011-07-20 21:54:39 UTC
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.
Comment 1 Owen Leonard 2013-04-04 22:24:37 UTC
(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?
Comment 2 Liz Rea 2013-04-05 03:19:19 UTC
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.
Comment 3 Marc Véron 2016-10-03 15:29:57 UTC
Still valid?