[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 #49 from Nick Clemens <nick at bywatersolutions.com> ---
(In reply to Marcel de Rooy from comment #48)
> Just puzzled by this change. Since CheckReserves is such a vital routine.
> How is it possible that we just now need to add waiting and transit holds?
> Related to use of holds queue?

Related to the fact that once upon a time a patron could only have a single
hold per biblio. We didn't run the risk of returning the wrong hold for a
borrower. The problem we are facing specifically is triggered by the holds
queue as well

> 
> Please note that _Findgroupreserve contains three queries. The first one is
> item level targeted. Why didnt you add the clause here? Since waiting and
> transit are item level.
> 

If a patron has multiple item level holds, no problem. Each has a specific
itemnumber and holdsqueue can only select one item

If a patron has multiple title level holds but at least one entry in
hold_fill_targets is where we hit the problem. The second title level hold
joins to the hold_fill_target that was really meant for the first hold. So we
end up returning only the second title level hold in the second query - this is
where we need to make sure to return the hold that we just marked
waiting/transit

Look at the unit test, that helps clarify the problem - run it without patches,
always get the wrong reserve_id

> If no results, the second is run. Which should be "title level". But
> inconsistently it does not contain an itemnumber IS NULL clause. And that
> fact helps you now to add the W/T clause. Does not look very consistent to
> me.

It is title level, but title level joins to an item level holds fill target

> 
> The first two runs are based on hold_fill_targets. If there are no results,
> the third query gets record and item level holds from the reserves table.
> My question here is: If we do not change the second query, the third one
> should find them too, since it does not contain a clause on found?

The problem is not the third query not returning the hold - it is the second
query returning the wrong hold

Alternate patch coming

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