https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15524
--- Comment #40 from Jonathan Druart <[email protected]> --- Back to this. (In reply to Kyle M Hall from comment #39) > (In reply to Jonathan Druart from comment #38) > > Kyle, > > > > Go to "Default checkout, hold and return policy", you do not see "Total > > holds allowed", fill the other fields, save: default_circ_rules.holdallowed > > is filled. > > We could add it to the interface and make it configurable, do not you think? > > holdallowed doesn't define how many holds may be placed, it defines what > items a patron may place holds on. It's already revealed in the rules editor! > > > > > Also if we add "max_holds", maybe we should rename "holdallowed" then. > > Again, not the same thing. Well, I think you were right here. I do not understand what I wanted to tell. I guess I got holdallowed and max_holds mixed up. Sorry about that. > > After that is done, the code in CanItemBeReserved could be replaced with a > > call to GetBranchBorrowerCircRule. This is, I think, still a valid request/question. In CanItemBeReserved there are 2 Koha::CirculationRules->find I am wondering why we do not call Koha::CirculationRules->get_effective_rule instead. Moreover it seems that there is a mix between '*' and undef. The UI inserts '*' whereas these calls and the tests search for undef. If we use undef we will be able to add FKs (branchcode,categorycode,itemtype) which can be great. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://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/
