https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26386 Bug ID: 26386 Summary: Fixing of waiting holds at wrong location crashes in certain situations Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: stefan.berndtsson@ub.gu.se QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com The fix when returning holds at the wrong location while the hold was waiting in Bug 21944 can cause crashes when the hold originated from a record level hold. The error mentioned in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21944#c33 can be reproduced via the following sequence: 1. Find a record with items 2. Create a record level hold with pickuplocation at library A 3. Check in one of the items at Library A 4. In the modal, click "Confirm", causing the hold to be in Waiting state 5. Change to library B 6. Check in the same item at Library B 7. In the modal, click "Confirm hold and transfer" This now causes the error mentioned in Comment 33 of Bug 21944.
From what I can see the cause of this is the sequence used when checking in an item. "returns.pl" is called twice.
Point 1-5 is normal. No issues there. When doing 6, it is: 1. checked in by calling "returns.pl", with the barcode. 2. RevertWaitingStatus will eventually be called, since this is at a different library than the one it is waiting at. Since this is a record level hold, the itemnumber will be removed from the hold. 3. The modal is shown with a transfer (to Library A, since that is the pickup location chosen for the hold) At step 7 we get: 1. checked in by calling "returns.pl" again, this time with a reserve_id connected. 2. There is code in "returns.pl" that assumes that checking in with a reserve_id must have a connected item, but this was removed at step 6.2, causing the crash. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.