https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18958
--- Comment #49 from Nick Clemens <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
