[Koha-bugs] [Bug 18958] If patron has multiple record level holds on one record transferring first hold causes next hold to become item level

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

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18958

--- Comment #21 from Nick Clemens <nick at bywatersolutions.com> ---
Created attachment 92160
  -->
https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=92160&action=edit
Bug 18958: Make check reserves find in transit holds

To test:
Imagine you have a record with 3 items, each item is held by LibraryA, LibraryB
and LibraryC respectively.
Now, a patron places two record level holds for pickup at LibraryD.
When any of the items are checked in, that item is trapped to fill the first
hold, but a side affect is
that the next open hold because item level for the item that was just checked
in!

This is clearly incorrect and prevents the patron from placing more record
level holds on the record.

The problem seems to be that we use GetOtherReserves to initiate transfers for
holds
This routine calls CheckReserves to see what holds are on the record. We have
an implicit assumption here
that anything matching the holds queue is the correct hold. This worked when we
couldn't have multiple holds on a record,
but now it can end up with false positive.

The solution seems to be returning the in-transit hold before returning a
second hold on the record to make sure we affect
the correct reserve.

Test Plan:
 1 - Create and use a patron that can place multiple record level holds per
record
 2 - Create a record with X items, each at a different library
 3 - Place X 'Next available' holds on the record for the patron using the
'Holds to place' box
 4 - perl misc/cronjobs/holds/build_holdsqueue.pl
 5 - Check in LibraryA's copy as LibraryA and confirm the hold
 6 - Revisit request.pl for the record, notice the next hold in line is now
item-specific
 7 - Checkout the item to the patron, notice the remaining hold is marked
waiting
 8 - Attempt to place another hold for your patron, notice that it requires an
item-specific hold
 8 - Apply this patch
 9 - Repeat steps 1-5
10 - Revisit request.pl for the record, notice the next hold in line has *not*
become item-specific
11 - Checkout the item to the patron, ensure the first hold is filled and the
second remains record level
12 - Repeat whole test plan without building holds queue to confirm holds are
still treated correctly

-- 
You are receiving this mail because:
You are watching all bug changes.