Summary: | CheckReserves does not respect holds circulation policies | ||
---|---|---|---|
Product: | Koha | Reporter: | Ian Walls <koha.sekjal> |
Component: | Hold requests | Assignee: | Ian Walls <koha.sekjal> |
Status: | Failed QA --- | QA Contact: | Bugs List <koha-bugs> |
Severity: | major | ||
Priority: | P3 | CC: | alexbuckley, dianajweaver, gmcharlt, hughr, jcamins, jonathan.druart, koha, smoreland, veron |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23172 | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Attachments: | Patch for Bug 4850 |
Description
Ian Walls
2010-06-03 21:25:42 UTC
Created attachment 2218 [details] [review] Patch for Bug 4850 Previous patch insufficient. Requires more testing. Marking Failed QA per Ian's last comment. Is this still an issue? I think this may have been fixed by other work on the holds system, but I'm not entirely clear on what the problem is. Still valid? I confirm that it's still an issue on master. If your item-level_itypes syspref is on item level, you can choose different itemtypes for the same biblio : some of them can be hold and the other not. If you choose to deal holds at a biblio level, you can encounter the problem described by Ian Walls : If there a hold on a biblio with 2 items that are checked out, if the first one to be checked in is not an item type that can be reserve, the circulation rules are not verified and the hold is placed on this item. In fact, it's just a problem of settings. Filling the "Defining circulation and fine rules for all libraries" table by setting 0 in "Holds allowed" column isn't sufficient. You have to fill the "Default holds policy by item type" table (default_branch_item_rules or branch_item_rules) and then, circulation rules are respected at a itemtype level for holds. So for me, this isn't an issue anymore. Regarding comments #6 and #7: Maybe there could be a hint in the description of syspref 'item-level_itypes' and/or in 'Circulation and fine rule' for table 'Default holds policy by item type'? If yes, what would be a good wording? I disagree that this isn't a problem. Comment 7 is true, but only if the only thing you care about is item types. Imagine you have a circ rule for borrower category A plus item type Z, and another rule for borrower category B plus item type Z. You want Category A to be allowed to place holds on Z items, and you don't want category B to be able to place holds on Z items. "Default holds policy by item type" is a blanket rule based on the item type only. So it's impossible to apply different hold rules on a combination of item type and borrower category. Hi all, I have written a related fix to what Ian wrote on this bug report. Mine is slightly different in that it checks the issuingrules database table to check the reservesallowed, holds_per_record, holds_per_day for a specific patron category/itemtype combination. This addresses Hugh's point as in my fix the return of an item now checks and respects the more granular hold rule on different patron category/item type combinations. Ian's patch will be great for checking blanket branch/itemtype combinations as it calls/checks C4::Circulation::GetBranchItemRule but it will not check/respect patron category/item type combination rules defined in the issuingrules table. If you could take a look at and if possible test Bug 23172 ( https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23172 ) that would be wonderful and much appreciated. Many thanks, Alex |