http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8465 Priority: P5 - low Change sponsored?: --- Bug ID: 8465 CC: gmcharlt@gmail.com, kyle.m.hall@gmail.com Assignee: koha-bugs@lists.koha-community.org Summary: CancelReserve sub is doing wrong Severity: critical Classification: Unclassified OS: All Reporter: christophe.croullebois@biblibre.com Hardware: All Status: NEW Version: master Component: Circulation Product: Koha In request.pl when you cancel a waiting hold, with the red cross,the next becomes "waiting", but: in the same page, the details column shows "No Barcode " in detail.pl, the status column shows "available" that is bad too, but: behind the scene, it's worse, because the CancelReserve function is poorly formated. The matter is that this sub puts a "W" on the next hold, that is impossible due to many constraints An other point, the sub increases priority for all other holds, that is good, except in one case: if we delete an hold with priority=0 and found=W the next waiting with priority=1 will be 0, and that is not good. So I have just corrected that and cleaned the code. After discussions, I have decided to avoid a manual checkin of the item. So, in the case of deleting a waiting hold, no need to checkin the item, if we have an hold following, a requester will propose to transfer or to confirm the hold. cleaning CancelReserve API : the biblionumber is retrieved in the SELECT * FROM reserves WHERE reservenumber = ?' at the beginning of the sub, so removing it from API. **************************************************************************** To test : * put 2 different holds on a biblio with 1 item * checkin and confirm the first hold * all is correct you can see it in the piority column "Waiting" * now use the red cross on the right to cancel this hold * check request.pl and detail.pl you'll see the results of the bug. Thx for testing -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.