Bug 26910 - When calling the effective rule (allowed reserves), the undef is now set at 0 versus undef
Summary: When calling the effective rule (allowed reserves), the undef is now set at 0...
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-11-03 14:42 UTC by Kelly McElligott
Modified: 2022-07-16 18:43 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kelly McElligott 2020-11-03 14:42:03 UTC
When calling allowed reserves - git effective rule, if this rule is undef, the default is now set to zero.  Prior to the change made in 18936, the default was set to undef.


It appears this change was made "Bug 18936: Fix some more tests (19.56 KB, patch)" during this stage in the bug.  

In conclusion, this is very critical, as libraries will come across the inability to allow holds if they have circulation rules effective by this.
Comment 1 Jonathan Druart 2020-11-03 15:36:47 UTC
Can you provide a step by step plan to recreate the issue please?

I edited the main circulation rule, filled "Holds allowed (total)" with an empty string, saved => "" is set in DB and I am able to place hold on items.

Do you mean you have NULL in DB?

What is the return of
> select rule_value from circulation_rules where rule_name="reservesallowed";
Comment 2 Nick Clemens 2020-11-03 15:47:30 UTC
Found from bug 26911 

Set some other values for a rule in the circ matrix then
DELETE FROM circulation_rules WHERE rule_name = 'reservesallowed';

The rules now appear as unlimited, but act as if 0

This line:
 427         $allowedreserves  = $rights->{reservesallowed} // $allowedreserves;

Previously it did not assign to allowed reserves which is defaulted to 0 at the beginning of CanItemBeReserved
Comment 3 Jonathan Druart 2020-11-03 15:59:54 UTC
So it does not happen if the upgrade does not fail?
Comment 4 Nick Clemens 2020-11-03 18:22:14 UTC
To recreate:
1 - Remove any All/All rules from circulation rules
2 - Set a circ rule for a specific itemtype with Holds allowed (total) set to 5
3 - Attempt to place a hold on an itemtype without the rules
4 - Too many holds: Edna Acosta can only place a maximum of 0 total holds.

Turns out, this behaviour is consistent in my testing, so the problem was the upgrade only

There is a question whether no rules set should allow unlimited holds, or 0 holds but that's not necessarily a bug.
Currently we set "" for unlimited, and the rule not existing means that holds are not allowed.