http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10314 Galen Charlton <gmcharlt@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |In Discussion --- Comment #11 from Galen Charlton <gmcharlt@gmail.com> --- (In reply to Kyle M Hall from comment #1)
5) Create a hold policy rule that would stop this patron from placing a hold on this item 6) Attempt to place an item-level hold on this item/patron, it should fail, but instead it will succeed
How exactly are you managing to place the item-level hold? Both request.pl and opac-request.pl do call GetBranchItemRule(), and any items that cannot be requested because of the policy are prevented from being selected: http://screencast.com/t/pOF9zM4IChk Of course, maybe I'm just missing another avenue for a patron or staff user to manage to place such requests. To be clear, I'm not opposed to the general idea of the change -- for one thing, the ILS-DI and SIP hold placement code currently doesn't do enough checking, so moving checks into CanItemBeReserved() can certainly simplify things. Also, it looks like it might be useful as a way of preventing patrons from placing forbidden hold requests by manipulating the parameters passed to opac-request.pl. That said, unless there's more of a visible way for users to bypass the library/item-type hold policies, I think this patch can be held back a bit longer for: - unit tests - removing calls to GetBranchItemRule() that would be made redundant by this change - (maybe) tweaking the return of CanItemBeReserved() so that higher-level code can distinguish between an item not being requestable due to a patron exceeding the limit and to it not being requestable because of library/item-type policy. Per a discussion I had with Katrin, I'm setting this to in discussion so that she can review her testing notes. -- You are receiving this mail because: You are watching all bug changes.