http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14640 --- Comment #1 from Kyle M Hall <kyle.m.hall@gmail.com> --- First, I want to point out there are two different pieces of code that handle similar situations, first is where a librarian attempts to check out a book on hold and *waiting* for a different patron. When this happens, Koha will offer to cancel or revert the waiting hold. This feature works correctly. This bug is dealing with the situation where an item is checked out to a patron that is not the next in line hold-wise for an item. In this case, Koha will warn the librarian that there are holds on the item and show the first person in line. Again, I want to stress that this is the case where the item *is not waiting* for a patron. The hold for the patron listed will just have a priority of 1. The only situation where the "Cancel hold" checkbox will function is when the priority 1 hold is an item level hold. This is due to the fact that CancelReserve is being passed the trio of biblionumber, borrowernumber, and itemnumber rather than the singular reserve_id. The call stack is as such: AddIssue MoveReserve ( here is where CancelReserve should be called using reserve_id ) CancelReserve -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14640 --- Comment #2 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 41926 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=41926&action=edit Bug 14640 - 'Cancel Hold' check box on check-out confirmation does not cancel the hold when item is checked out. This bug is dealing with the situation where an item is checked out to a patron that is not the next in line hold-wise for an item. In this case, Koha will warn the librarian that there are holds on the item and show the first person in line. Again, I want to stress that this is the case where the item *is not waiting* for a patron. The hold for the patron listed will just have a priority of 1. The only situation where the "Cancel hold" checkbox will function is when the priority 1 hold is an item level hold. This is due to the fact that CancelReserve is being passed the trio of biblionumber, borrowernumber, and itemnumber rather than the singular reserve_id. 1) place biblio level hold on a book to borrower A. 2) check out an item of the book to borrower B. 3) When confirming checkout, check the 'Cancel hold' check-box, and click the "Yes, check out" button. 4) Note the hold was not canceled 5) Apply this patch 6) Repeat steps 1 through 3 7) Note the hold was indeed canceled -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14640 Joonas Kylmälä <j.kylmala@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14640 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14640 --- Comment #5 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Created attachment 42143 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=42143&action=edit Bug 14640 - 'Cancel Hold' check box on check-out confirmation does not cancel the hold when item is checked out. This bug is dealing with the situation where an item is checked out to a patron that is not the next in line hold-wise for an item. In this case, Koha will warn the librarian that there are holds on the item and show the first person in line. Again, I want to stress that this is the case where the item *is not waiting* for a patron. The hold for the patron listed will just have a priority of 1. The only situation where the "Cancel hold" checkbox will function is when the priority 1 hold is an item level hold. This is due to the fact that CancelReserve is being passed the trio of biblionumber, borrowernumber, and itemnumber rather than the singular reserve_id. 1) place biblio level hold on a book to borrower A. 2) check out an item of the book to borrower B. 3) When confirming checkout, check the 'Cancel hold' check-box, and click the "Yes, check out" button. 4) Note the hold was not canceled 5) Apply this patch 6) Repeat steps 1 through 3 7) Note the hold was indeed canceled Signed-off-by: Joonas Kylmälä <j.kylmala@gmail.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14640 --- Comment #7 from Barton Chittenden <barton@bywatersolutions.com> --- Master is at version 3.21.00.026. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14640 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to Master |Pushed to Stable --- Comment #9 from Chris Cormack <chris@bigballofwax.co.nz> --- Pushed to 3.20.x will be in 3.20.4 -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14640 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de Summary|'Cancel Hold' check box on |'Cancel Hold' check box on |check-out confirmation does |check-out confirmation does |not cancel the hold when |not cancel the hold when |item is checked out. |item is checked out -- You are receiving this mail because: You are watching all bug changes.