| 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: | --- | 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? |