| Summary: | pressing enter when hold found at checkin causes issues | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Liz Rea <wizzyrea> |
| Component: | Circulation | Assignee: | Owen Leonard <oleonard> |
| Status: | CLOSED INVALID | QA Contact: | Bugs List <koha-bugs> |
| Severity: | minor | ||
| Priority: | P5 - low | CC: | gmcharlt, liz, veron |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| GIT URL: | Initiative type: | --- | |
| Sponsorship status: | --- | Comma delimited list of Sponsors: | |
| Crowdfunding goal: | 0 | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
|
Description
Liz Rea
2011-07-20 21:54:39 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? 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? |