https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18958 --- Comment #49 from Nick Clemens <nick@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.