[Bug 41267] New: It should be possible to prevent some itemtypes from filling other biblio level holds
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Bug ID: 41267 Summary: It should be possible to prevent some itemtypes from filling other biblio level holds Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: nick@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, lisette@bywatersolutions.com, tomascohen@gmail.com See bug 40792 and related/dependent bugs. Currently Koha will fill any title level holds on a record when another item on the record is checked out. Some libraries want this behaviour, others don't want it for all item types. E.g. - A library has 'lucky day' item which cannot have holds placed. If a patron finds them in the library they can check them out. In some libraries they have similar circ rules and so the item should fill the hold In other libraries the lucky day items have a shorter circulation period, so the patron may still want the regular book with a longer circ We should add a circulation rule to determine if an item type should or should not fill other biblio level holds Filing as a bug since many libraries consider this a regression -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 --- Comment #1 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- Created attachment 189682 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=189682&action=edit Bug 41267: Add fill_other_biblio_holds_policy circulation rule This patch adds a new rule for itemtypes to allow/prevent filling other holds on a bibliographic record The rule will obey ReservesControlBranch for determining the rules To test: 1 - Apply patches 2 - Setup/choose 2 item types in Administration->Item types 3 - In Administration -> Circulation and fine rules scroll to the bottom 4 - Set one item type to "Fill other holds on record" = 'Yes' and the other to 'No' 5 - Place a hold on the 'No' item type for a patron 6 - Checkout the 'Yes' item type to the patron 7 - Their hold should fill 8 - Check in the items - place a hold for the 'Yes' item type 9 - Checkout the 'No' itemtype to the patron 10 - Their hold should not be filled 11 - Set a rule for the patrons branch to No and set system preference ReservesControlBranch to 'Patrons library' 12 - repeat 5&6 13 - The hold should not fill 14 - Change reserves control branch to items home library 15 - checkin /checkout the yes item type 16 - The hold should fill -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |nick@bywatersolutions.com |ity.org | See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=40792 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Jason Robb <jrobb@sekls.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jrobb@sekls.org Status|Needs Signoff |Failed QA --- Comment #2 from Jason Robb <jrobb@sekls.org> --- I'm not getting the expected results on step 10 onward. When I check out the "Dont fill" type item to the patron with an active hold, the hold is completed which doesn't seem to be the desired result. I set up: - 2 new item types (Fill other holds, Don't fill other holds) - A global/all libraries hold policy for each of the item types - One bib with two items, one with a "Fill" itype and one with a "Don't fill" itype - Holds were placed at the bib-level I also tried setting the hold policies at the branch-level of the patron with ReservesControlBranch set to Patron's Home Library and the "Don't fill" type item still clears the hold on check out. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Steve, OSLRI, USA <sspohn@oslri.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bywater@oslri.net, | |sspohn@oslri.net -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Hans Pålsson <hans.palsson@hkr.se> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hans.palsson@hkr.se -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #189682|0 |1 is obsolete| | --- Comment #3 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- Created attachment 190518 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=190518&action=edit Bug 41267: Add fill_other_biblio_holds_policy circulation rule This patch adds a new rule for itemtypes to allow/prevent filling other holds on a bibliographic record The rule will obey ReservesControlBranch for determining the rules To test: 1 - Apply patches 2 - Setup/choose 2 item types in Administration->Item types 3 - In Administration -> Circulation and fine rules scroll to the bottom 4 - Set one item type to "Fill other holds on record" = 'Yes' and the other to 'No' 5 - Place a next available hold on the record 6 - Checkout the 'Yes' item type to the patron 7 - Their hold should fill 8 - Check in the items 9 - Place a next available hold on the record 10 - Checkout the 'No' itemtype to the patron 11 - Their hold should not be filled 12 - Check in the item and confirm the hold 13 - Checkout the itme to the patron, the hold fills NOTE: While seemingly counter intuitive, the rule controls whether a hold NOT tied to this item will fill Confirming the hold adds an itemnumber to the hold. In most cases, these items will not be holdable, so won't trigger at checkin 14 - Set a rule for the patrons branch to No and set system preference ReservesControlBranch to 'Patrons library' 15 - repeat 5&6 16 - The hold should not fill 17 - Change reserves control branch to items home library 18 - checkin /checkout the yes item type 19 - The hold should fill -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Katie Bliss <kebliss@dmpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kebliss@dmpl.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Michelle Spinney <mspinney@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mspinney@clamsnet.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Christopher Brannon <cbrannon@cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cbrannon@cdalibrary.org --- Comment #4 from Christopher Brannon <cbrannon@cdalibrary.org> --- Steps get really muddy starting at step 11: 14 - Set a rule for the patrons branch to No and set system preference ReservesControlBranch to 'Patrons library' Set a rule for the patrons branch to No - Can you give a little more detail? Am I setting the rule on the holds for an item type? This is not as clear as the previous steps. 15 - repeat 5&6 16 - The hold should not fill I set a no under the patrons home library for the itemtype that is no on the default rules. Your instructions are vague. This did not produce the result you mention. I stopped here because I am not following this to produce the desired result. Frankly, the logic with this functionality seems a bit confusing. And the outcome of step 13 is where the confusion beings. I don't know why checking this item in would have triggered the hold based on the rule we set in step 4. If we are checking in the No item, why would it EVER trigger the hold? I think a LOT of folks are going to have a problem with this workflow. That contradicts the rule we set, and I can't see the logic at all. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 --- Comment #5 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- (In reply to Christopher Brannon from comment #4)
Steps get really muddy starting at step 11:
14 - Set a rule for the patrons branch to No and set system preference ReservesControlBranch to 'Patrons library'
Set a rule for the patrons branch to No - Can you give a little more detail? Am I setting the rule on the holds for an item type? This is not as clear as the previous steps.
Set a rule for the itemtype marked 'Fill other holds=Yes' in step 4 as 'Fill other holds=No' for the patron's branch in the circ rules - i.e. not for all branches, just their branch to confirm they use the setting of their branch when the reserves cnotrol is flipped
15 - repeat 5&6 16 - The hold should not fill
I set a no under the patrons home library for the itemtype that is no on the default rules. Your instructions are vague. This did not produce the result you mention.
I stopped here because I am not following this to produce the desired result.
Frankly, the logic with this functionality seems a bit confusing. And the outcome of step 13 is where the confusion beings. I don't know why checking this item in would have triggered the hold based on the rule we set in step 4. If we are checking in the No item, why would it EVER trigger the hold?
This is not a likely scenario, but to demonstrate that the rule is not "No holds allowed" - but don't fill a hold that is not targeted to this item with this item. Most likely, an item that you don't want to fill holds will be marked as 'No holds allowed' - this rule determines whether the itemtype should fill any other hold. If you have 2Wk loan and 1wk loan items, and both can be held and you place a next available hold, the 1wk item is expected to fill the hold. If the patron placed an item hold on the 2wk, and 1wk items cannot fill OTHER holds, then the hold on the 2wk would remain -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Christopher Brannon <cbrannon@cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #6 from Christopher Brannon <cbrannon@cdalibrary.org> --- Step 16 fails according to your instructions. I suspect there are conditions that are not getting set correctly because they are overlooked in the steps. What branch should I be checking out under? What branch should the patron be part of? In any case, with the conditions you outline, on step 16, the hold filled. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emily.lamancusa@montgomeryc | |ountymd.gov -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 --- Comment #7 from Jason Robb <jrobb@sekls.org> --- Thanks for working on this Nick! Part of the confusion for me is the "other hold" for the patron on the record is ignored by the "no fill" item on checkout, but not check *in*. If the intention is to only apply this rule at checkout, adding that to the column header for the setting could add clarity (i.e. Fill other holds on record at checkout). It's still a little weird that a "Don't fill my hold" item can be checked out, not fill my hold, then when I return it that exact same item will try to immediately fill my hold, but maybe there are use cases for that. The described behavior for a Lucky Day collection *can* be achieved by setting "Fill other holds on record" to "No" alongside a Hold policy of "No holds allowed" for a specific item type, which seems like an ideal setup for a browsing shelf of lucky day books. These are the steps I took for testing: 1. Create 2 items types: Fill, No fill 2. In the circ rules > holds and bookings policies for Midway: - Fill - Fill other holds on record = Yes - (Hold policy remains 'From any library' by default) - No fill - Fill other holds on record = No - (Hold policy remains 'From any library' by default) 3. Set logged in library to Midway --Hold policies follow patron home library: ReservesControlBranch - PatronLibrary (default)-- 4. Prep items - on X Power Tools (bib 6) - Set one item to the Fill/Yes itype - Set the other item to the No Fill/No itype 5. Place a record-level hold for Henry (home library is Midway by default) 6. Check out the Yes item to Henry, hold fills 7. Check in the Yes item 8. Place a record-level hold for Henry 9. Check out the No item to Henry, hold doesn't fill 10. Check in the No item, hold is triggered, confirm the hold 11. Check out the No item, hold fills --Hold policies follow item home library-- 12. Change syspref ReservesControlBranch to ItemHomeLibrary 13. Change Henry's home library to Centerville 14. Set both item home libraries to Midway 15. Place a record-level hold for Henry 16. Check out the Yes item to Henry, hold fills 17. Check in the Yes item 18. Place a record-level hold for Henry 19. Check out the No item to Henry, hold doesn't fill 20. Check in the No item, hold is triggered, confirm the hold 21. Check out the No item, hold fills --Testing for a Lucky Day use scenario-- Setup: - ReservesControlBranch = PatronLibrary - Logged in branch = Midway (mostly doesn't matter) - Henry's home library = Midway - Items' home library = Midway - Midway Fill (regular book) rule - Hold policy: From any library - Fill other holds on record: Yes - Midway No fill (lucky day book) rule - Hold policy: No holds allowed - Fill other holds on record: No 1. Place a record-level hold for Henry 2. Check out the Yes (regular book) item to Henry, hold fills 3. Check in the Yes (regular book) item 4. Place a record-level hold for Henry 5. Check out the No (lucky day book) item to Henry, hold doesn't fill 6. Check in the No (lucky day book) item, hold doesn't trigger 7. Lucky day item goes back to the lucky day shelf, Henry's hold remains until an unlucky regular item is available to fill it This seems to all be working as described, if I'm understanding the intended functionality correctly. It would definitely still help to add some clarity about the setting, though. Maybe another bullet point in the Important list that says the feature only applies at checkout and only to record-level holds? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=38650 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 --- Comment #8 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- Created attachment 191695 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=191695&action=edit Bug 41267: (follow-up) Add more clarifying text -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 --- Comment #9 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- (In reply to Christopher Brannon from comment #6)
Step 16 fails according to your instructions. I suspect there are conditions that are not getting set correctly because they are overlooked in the steps. What branch should I be checking out under? What branch should the patron be part of? In any case, with the conditions you outline, on step 16, the hold filled.
I think I meant: 14 - Set a rule for the 'Yes' itemtype in the patrons homebranch, setting the Fill other holds on record" = 'No' What I wanted to demonstrate here was that the rule was correctly selected when set for a specific library - for the original rules I meant for them to be set for 'All libraries' -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Rebecca Coert <rcoert@arlingtonva.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rcoert@arlingtonva.us -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #10 from David Cook <dcook@prosentient.com.au> --- This sounds interesting. And the place to check isn't CheckReserves? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 --- Comment #11 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- (In reply to David Cook from comment #10)
This sounds interesting. And the place to check isn't CheckReserves?
CheckReserves finds the holds that can be filled for a particular item, in the cases we are really interested in here Koha wouldn't trap the item we are checking out to fill the hold, but it currently fills the hold when the item is checked out, but we don't want to prevent other items from trapping. What we want to do is generally fill holds when the patron gets any item on a record, unless that item type is a limited type. The use case presented is where the item has a shortened check out period, and the patron should still be eligible for a hold with a longer period. It's a fine distinction, true, but one that libraries want. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Patch doesn't apply --- Comment #12 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- Does not apply :( -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #190518|0 |1 is obsolete| | Attachment #191695|0 |1 is obsolete| | --- Comment #13 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- Created attachment 195371 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=195371&action=edit Bug 41267: Add fill_other_biblio_holds_policy circulation rule This patch adds a new rule for itemtypes to allow/prevent filling other holds on a bibliographic record The rule will obey ReservesControlBranch for determining the rules To test: 1 - Apply patches 2 - Setup/choose 2 item types in Administration->Item types 3 - In Administration -> Circulation and fine rules scroll to the bottom 4 - Set one item type to "Fill other holds on record" = 'Yes' and the other to 'No' 5 - Place a next available hold on the record 6 - Checkout the 'Yes' item type to the patron 7 - Their hold should fill 8 - Check in the items 9 - Place a next available hold on the record 10 - Checkout the 'No' itemtype to the patron 11 - Their hold should not be filled 12 - Check in the item and confirm the hold 13 - Checkout the itme to the patron, the hold fills NOTE: While seemingly counter intuitive, the rule controls whether a hold NOT tied to this item will fill Confirming the hold adds an itemnumber to the hold. In most cases, these items will not be holdable, so won't trigger at checkin 14 - Set a rule for the patrons branch to No and set system preference ReservesControlBranch to 'Patrons library' 15 - repeat 5&6 16 - The hold should not fill 17 - Change reserves control branch to items home library 18 - checkin /checkout the yes item type 19 - The hold should fill -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 --- Comment #14 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- Created attachment 195372 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=195372&action=edit Bug 41267: (follow-up) Add more clarifying text -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Andrew Auld <andrew.auld@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #195371|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Andrew Auld <andrew.auld@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #195372|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 --- Comment #15 from Andrew Auld <andrew.auld@openfifth.co.uk> --- Created attachment 196208 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=196208&action=edit Bug 41267: Add fill_other_biblio_holds_policy circulation rule This patch adds a new rule for itemtypes to allow/prevent filling other holds on a bibliographic record The rule will obey ReservesControlBranch for determining the rules To test: 1 - Apply patches 2 - Setup/choose 2 item types in Administration->Item types 3 - In Administration -> Circulation and fine rules scroll to the bottom 4 - Set one item type to "Fill other holds on record" = 'Yes' and the other to 'No' 5 - Place a next available hold on the record 6 - Checkout the 'Yes' item type to the patron 7 - Their hold should fill 8 - Check in the items 9 - Place a next available hold on the record 10 - Checkout the 'No' itemtype to the patron 11 - Their hold should not be filled 12 - Check in the item and confirm the hold 13 - Checkout the itme to the patron, the hold fills NOTE: While seemingly counter intuitive, the rule controls whether a hold NOT tied to this item will fill Confirming the hold adds an itemnumber to the hold. In most cases, these items will not be holdable, so won't trigger at checkin 14 - Set a rule for the patrons branch to No and set system preference ReservesControlBranch to 'Patrons library' 15 - repeat 5&6 16 - The hold should not fill 17 - Change reserves control branch to items home library 18 - checkin /checkout the yes item type 19 - The hold should fill Signed-off-by: Andrew Auld <andrew.auld@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 --- Comment #16 from Andrew Auld <andrew.auld@openfifth.co.uk> --- Created attachment 196209 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=196209&action=edit Bug 41267: (follow-up) Add more clarifying text Signed-off-by: Andrew Auld <andrew.auld@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Andrew Auld <andrew.auld@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew.auld@openfifth.co.uk --- Comment #17 from Andrew Auld <andrew.auld@openfifth.co.uk> --- Nicely done! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Andrew Auld <andrew.auld@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off --- Comment #18 from Andrew Auld <andrew.auld@openfifth.co.uk> --- Nicely done, this time with SO! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |emily.lamancusa@montgomeryc |y.org |ountymd.gov -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #196208|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #196209|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 --- Comment #19 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- Created attachment 196380 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=196380&action=edit Bug 41267: Add fill_other_biblio_holds_policy circulation rule This patch adds a new rule for itemtypes to allow/prevent filling other holds on a bibliographic record The rule will obey ReservesControlBranch for determining the rules To test: 1 - Apply patches 2 - Setup/choose 2 item types in Administration->Item types 3 - In Administration -> Circulation and fine rules scroll to the bottom 4 - Set one item type to "Fill other holds on record" = 'Yes' and the other to 'No' 5 - Place a next available hold on the record 6 - Checkout the 'Yes' item type to the patron 7 - Their hold should fill 8 - Check in the items 9 - Place a next available hold on the record 10 - Checkout the 'No' itemtype to the patron 11 - Their hold should not be filled 12 - Check in the item and confirm the hold 13 - Checkout the itme to the patron, the hold fills NOTE: While seemingly counter intuitive, the rule controls whether a hold NOT tied to this item will fill Confirming the hold adds an itemnumber to the hold. In most cases, these items will not be holdable, so won't trigger at checkin 14 - Set a rule for the patrons branch to No and set system preference ReservesControlBranch to 'Patrons library' 15 - repeat 5&6 16 - The hold should not fill 17 - Change reserves control branch to items home library 18 - checkin /checkout the yes item type 19 - The hold should fill Signed-off-by: Andrew Auld <andrew.auld@openfifth.co.uk> Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 --- Comment #20 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- Created attachment 196381 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=196381&action=edit Bug 41267: (follow-up) Add more clarifying text Signed-off-by: Andrew Auld <andrew.auld@openfifth.co.uk> Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA --- Comment #21 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- Thanks everyone! This looks works as intended, passes tests, and all the previous feedback has been addressed. Passing QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Hanna Dehlin <hanna.dehlin@hkr.se> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hanna.dehlin@hkr.se -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to main Version(s)| |26.05.00 released in| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 --- Comment #22 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- Nice work everyone! Pushed to main for 26.05 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |additional_work_needed CC| |lucas@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 --- Comment #23 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- t/db_dependent/Holds.t fails now with this patch: # Subtest: EmailPatronWhenHoldIsPlaced tests 1..2 ok 1 - EmailPatronWhenHoldIsPlaced is disabled so no email is queued # Looks like you planned 2 tests but ran 1. not ok 72 - EmailPatronWhenHoldIsPlaced tests # Failed test 'EmailPatronWhenHoldIsPlaced tests' # at /kohadevbox/koha/t/db_dependent/Holds.t line 2110. Can't call method "cancel" on an undefined value at /kohadevbox/koha/C4/Reserves.pm line 2201. ok 73 - no warnings # Looks like your test exited with 11 just after 73. Dubious, test returned 11 (wstat 2816, 0xb00) Failed 2/74 subtests Test Summary Report ------------------- /kohadevbox/koha/t/db_dependent/Holds.t (Wstat: 2816 (exited 11) Tests: 73 Failed: 1) Failed test: 72 Non-zero exit status: 11 Parse errors: Bad plan. You planned 74 tests but ran 73. Files=1, Tests=73, 10 wallclock secs ( 0.04 usr 0.01 sys + 6.50 cusr 1.95 csys = 8.50 CPU) Result: FAIL -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 --- Comment #24 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- Created attachment 197039 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197039&action=edit Bug 41267: (follow-up) Check if exists Patch from commit 83a936f -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 --- Comment #25 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- Please check my follow-up before I push. It makes the test pass but I'm not sure if it is right. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 --- Comment #26 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- (In reply to Lucas Gass (lukeg) from comment #25)
Please check my follow-up before I push. It makes the test pass but I'm not sure if it is right.
The followup seems good - the test is doing a weird thing. It is calling MoveReserve with cancelreserve - but the hold fills, and then there is nothing to cancel - it does seem like we should address this case, so the patch makes sense -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 --- Comment #27 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- (In reply to Nick Clemens (kidclamp) from comment #26)
(In reply to Lucas Gass (lukeg) from comment #25)
Please check my follow-up before I push. It makes the test pass but I'm not sure if it is right.
The followup seems good - the test is doing a weird thing.
It is calling MoveReserve with cancelreserve - but the hold fills, and then there is nothing to cancel - it does seem like we should address this case, so the patch makes sense
Thanks Nick! Follow-up here pushed to main. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|additional_work_needed | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Jacob O'Mara <jacob.omara@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to main |Pushed to stable Version(s)|26.05.00 |26.05.00,25.11.05 released in| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 --- Comment #28 from Jacob O'Mara <jacob.omara@openfifth.co.uk> --- Thanks all, pushed to 25.11.x -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |43072 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43072 [Bug 43072] Hold policies display incorrectly in circ rules page -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org