Bug 26386

Summary: Fixing of waiting holds at wrong location crashes in certain situations
Product: Koha Reporter: Stefan Berndtsson <stefan.berndtsson>
Component: Hold requestsAssignee: Bugs List <koha-bugs>
Status: RESOLVED DUPLICATE QA Contact: Testopia <testopia>
Severity: major    
Priority: P5 - low CC: gmcharlt, jonathan.druart, nick
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Bug Depends on: 21944    
Bug Blocks:    

Description Stefan Berndtsson 2020-09-04 12:22:37 UTC
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.
Comment 1 Nick Clemens (kidclamp) 2020-09-04 16:22:15 UTC

*** This bug has been marked as a duplicate of bug 25969 ***