[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

Marcel de Rooy <m.de.rooy at rijksmuseum.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #108936|0                           |1
        is obsolete|                            |

--- Comment #70 from Marcel de Rooy <m.de.rooy at rijksmuseum.nl> ---
Created attachment 109641
  -->
https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=109641&action=edit
Bug 18958: Make hold_fill_targets specific to reserves

After looking at Marcel's comments, the problem is in our matching
to hold_fill_targets - rather than adjusting to find filled/waiting holds we
could ensure that hold_fill_targets only refers to the specific hold it
is intended to

This patch is clearer, if slightly less performant than last (we now return all
the reserves and have to find the 'highest')

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

Signed-off-by: Andrew Fuerste-Henry <andrew at bywatersolutions.com>

Signed-off-by: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>

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