[Koha-bugs] [Bug 26386] New: Fixing of waiting holds at wrong location crashes in certain situations

[bugzilla-daemon at bugs.koha-community.org]

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 at lists.koha-community.org
          Reporter: stefan.berndtsson at ub.gu.se
        QA Contact: testopia at bugs.koha-community.org
                CC: gmcharlt at 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.