In 'CanBookBeRenewed' we call 'CanItemBeReserved' to see if an item is available to fill a hold - this doesn't work because: 1 - We call it wrong (bug 28013) 2 - We count the current hold against the limit This bug adds an optional param 'ignore_hold_counts' to the routine, while still forbidding holds when 0 are allowed
Created attachment 119124 [details] [review] Bug 28078 - Add 'ignore_hold_counts' param to CanItemBeReserved This patch adds an optional param 'ignore_hold_counts' to the routine, while still forbidding holds when 0 are allowed To test: 1 - prove -v t/db_dependent/Holds.t
Created attachment 119143 [details] [review] Bug 28078 - Add 'ignore_hold_counts' param to CanItemBeReserved This patch adds an optional param 'ignore_hold_counts' to the routine, while still forbidding holds when 0 are allowed To test: 1 - prove -v t/db_dependent/Holds.t Signed-off-by: David Nind <david@davidnind.com>
Let me come back to this later but I'm pretty sure we cannot do this because (at least how the parameter is used in the bug 28013) it wouldn't follow circulation rules. We have libraries intentionally defining the amounts of holds a patron in a specific patron category and in a specific library can do to a specific item type. See also Bug 26659.
(In reply to Joonas Kylmälä from comment #3) > Let me come back to this later but I'm pretty sure we cannot do this because > (at least how the parameter is used in the bug 28013) it wouldn't follow > circulation rules. We have libraries intentionally defining the amounts of > holds a patron in a specific patron category and in a specific library can > do to a specific item type. See also Bug 26659. I see what you are saying, the way I understand it is this: In CanBookBeRenewed we call CanItemBeReserved to see if the item could fill the reserve Those are two different questions: CanItemBeReserved answers the question: "Can the patron place a hold on this item?" What we are asking in CanBookBeRenewed is: "Can this item fill any hold for this patron?" In the first question the number of holds the patron currently has should be taken into account as the end result would be adding one more In the second question the number of holds don't matter, because we will not add any holds, we just want to know if we can fill the hold The other solution is two subroutines: CanItemBeReserved CanItemFillHold Note: We do have Koha::Holds->get_items_that_can_fill, however, that leaves out checks on transfer limits and counts of holds
(In reply to Nick Clemens from comment #4) > (In reply to Joonas Kylmälä from comment #3) > > Let me come back to this later but I'm pretty sure we cannot do this because > > (at least how the parameter is used in the bug 28013) it wouldn't follow > > circulation rules. We have libraries intentionally defining the amounts of > > holds a patron in a specific patron category and in a specific library can > > do to a specific item type. See also Bug 26659. > > I see what you are saying, the way I understand it is this: > In CanBookBeRenewed we call CanItemBeReserved to see if the item could fill > the reserve > > Those are two different questions: > > CanItemBeReserved answers the question: "Can the patron place a hold on this > item?" > > What we are asking in CanBookBeRenewed is: "Can this item fill any hold for > this patron?" > > In the first question the number of holds the patron currently has should be > taken into account as the end result would be adding one more > > In the second question the number of holds don't matter, because we will not > add any holds, we just want to know if we can fill the hold > > > The other solution is two subroutines: > CanItemBeReserved > CanItemFillHold > > Note: We do have Koha::Holds->get_items_that_can_fill, however, that leaves > out checks on transfer limits and counts of holds Interesting. I see now you added the condition > && (!$params->{ignore_hold_counts} || $allowedreserves == 0 ) so it still keeps follows the circulation rules also when allowedreserves rules is 0. Maybe doing the check on also how many hold requests the patron has to the biblio or item is not relevant here as you said. However, I think this patch should also skip the itemAlreadyOnHold return value for this to work on item-level holds as well, could you please re-do the patch?
Created attachment 119220 [details] [review] Bug 28078: (follow-up) Add param check to 'itemAlreadyOnHold' test
Created attachment 119263 [details] [review] Bug 28078: Add 'ignore_hold_counts' param to CanItemBeReserved This patch adds an optional param 'ignore_hold_counts' to the routine, while still forbidding holds when 0 are allowed To test: 1 - prove -v t/db_dependent/Holds.t Signed-off-by: David Nind <david@davidnind.com> JK: Commit message amended: Fixed title formatting Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Created attachment 119264 [details] [review] Bug 28078: (follow-up) Add param check to 'itemAlreadyOnHold' test Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Passing QA.
Pushed to master for 21.05, thanks to everybody involved!
+ should not check if there are too many holds as we only csre about reservability Is it a typo for "care" ? This is more enhancement than bug no ?
(In reply to Fridolin Somers from comment #11) > + should not check if there are too many holds as we only csre about > reservability > > Is it a typo for "care" ? yup. > This is more enhancement than bug no ? This is a dependency to fix a bug. The bug fix is in bug 28013. The issues caused by this bug were reported also in other bugs, like bug 26659.
Pushed to 20.11.x for 20.11.06
Pushed to 20.05.x for 20.05.12
Not backported to oldoldstable (19.11.x). Feel free to ask if it's needed.