Bug 26386 - Fixing of waiting holds at wrong location crashes in certain situations
Summary: Fixing of waiting holds at wrong location crashes in certain situations
Status: RESOLVED DUPLICATE of bug 25969
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: All All
: P5 - low major (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 21944
Blocks:
  Show dependency treegraph
 
Reported: 2020-09-04 12:22 UTC by Stefan Berndtsson
Modified: 2020-09-04 16:22 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 2020-09-04 16:22:15 UTC

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