[Bug 28529] New: Max holds per item type ineffective when using AllowHoldItemTypeSelection on bib-level holds
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 Bug ID: 28529 Summary: Max holds per item type ineffective when using AllowHoldItemTypeSelection on bib-level holds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: tomascohen@gmail.com QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com Bug 15533 introduced a way to constraint biblio-level holds to a specific item type. This is controlled by the AllowHoldItemTypeSelection syspref. On the circulation rules, you are able to set max_holds for an item type. This max_holds setting, seems to be honoured for item-level holds only, and it is not quite correct. To reproduce: 1. Have a patron of category 'Staff' (S) 2. Have 3 records with items with the 'BK' item type, and maybe others 3. Enable AllowHoldItemTypeSelection 4. Set a limit of 2 max holds for that category+item type 5. In the OPAC. Place bibio-level holds, with item type contraint to 'BK' on those 3 records => FAIL: You can place the 3 holds -- 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=28529 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=24683 -- 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=28529 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|koha-bugs@lists.koha-commun |tomascohen@gmail.com |ity.org | -- 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=28529 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Max holds per item type |Item type-constrained |ineffective when using |biblio-level holds should |AllowHoldItemTypeSelection |honour max_holds as |on bib-level holds |item-level do CC| |jonathan.druart+koha@gmail. | |com, | |katrin.fischer@bsz-bw.de, | |kyle@bywatersolutions.com --- Comment #1 from Tomás Cohen Arazi <tomascohen@gmail.com> --- I consider this a bug, but this should be an opt-in change, because the feature never considered circ rules in its conception, and libraries are using them as-is and might see their workflows affected. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #2 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Hi Tomas, I seem to remember that the biblio-level itemtype played into the max holds setting as well (which poses a problem to us, as we usually don't set it). In your test, was there a biblio-level itemtype (942$c) set? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #3 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Katrin Fischer from comment #2)
Hi Tomas, I seem to remember that the biblio-level itemtype played into the max holds setting as well (which poses a problem to us, as we usually don't set it).
In your test, was there a biblio-level itemtype (942$c) set?
There wasn't a 942$c set. If you look at bug 15533 you will notice the purpose of the feature is to define which items on the biblio can fill the hold. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #4 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 124505 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=124505&action=edit Bug 28529: Add BiblioHoldItemTypeUseForRules system preference -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #5 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 124506 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=124506&action=edit Bug 28529: Unit tests -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #6 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 124507 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=124507&action=edit Bug 28529: Make biblio-level hold itemtype count against max rules The current situation is that biblio-level holds can be assigned an item type, so they can only be fulfilled by items matching that specified item type (be it item-level itype or the fallback to biblio-level). But there's the situation in which max holds limits for a specific item type can be overridden by using biblio-level holds with item type selection (AllowHoldItemTypeSelection) enabled. To test: 1. Have a patron of category 'Staff' (S) 2. Have 3 records with items with the 'BK' item type, and maybe others 3. Enable AllowHoldItemTypeSelection 4. Set a limit of 2 max holds for that category+item type 5. In the OPAC. Place bibio-level holds, with item type contraint to 'BK' on those 3 records => FAIL: You can place the 3 holds 6. Cancel the holds 7. Apply this patch and restart all 8. Repeat 5 => SUCCESS: You can only place 2 holds 9. Run: $ kshell t/db_dependent/Reserves.t => SUCCESS: Tests pass! 10. Sign off :-D -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #7 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Katrin Fischer from comment #2)
Hi Tomas, I seem to remember that the biblio-level itemtype played into the max holds setting as well (which poses a problem to us, as we usually don't set it).
In your test, was there a biblio-level itemtype (942$c) set?
I did some digging about this. The biblio-level itype is used for item-level holds, when item-level_itypes is disabled. So it doesn't seem to be the same thing. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david@davidnind.com --- Comment #8 from David Nind <david@davidnind.com> --- I couldn't reproduce the issue before the patch is applied (koha-testing-docker): - For step 4 I setup a circulation and fines rule for patron category=Staff and item type = Books, with holds allowed (total) = 2 - Using the OPAC, I placed holds with "Request specific item type" set to Books - I can't place a third hold (message was "There are no items that can be placed on hold.") - AllowHoldItemTypeSelection is enabled - The records I placed holds on all have 942$c set to Books and each item is also set to Books and have multiple items Is there something else or other system preference setting needed? I'm guessing it is something with the circulation and fines rules that I'm not getting right. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #9 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to David Nind from comment #8)
I couldn't reproduce the issue before the patch is applied (koha-testing-docker):
I'm guessing it is something with the circulation and fines rules that I'm not getting right.
Edit items and added 'multiple' items of type 'Books'. On each record
David, thanks for taking the time. I have just set a fresh KTD and reproduced the issue fairly easily. This were my steps: 1. Fresh KTD (master branch of Koha) 2. Pick 'Henry Acevedo' patron, and set a known user/pass (henry/Henry123!) 3. Enable AllowHoldItemTypeSelection 4. Circ rules: there's only one global rule, for all categories and types. I generated a new one, for 'Staff' and 'Books' with everything similar to the existing rule, except holds. I put 2 in the holds rules (max, daily, per record) 5. Search for 'a' 6. Make sure the first three titles contain items of type 'Books', I used Edit 7. Logged in as henry/Henry123! in the OPAC 8. Searched for 'a' 9. Placed record-level holds on them, choosing the 'Books' in the More options section. => FAIL: I was able to set 4 holds -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomascohen@gmail.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #124505|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=28529 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #124506|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=28529 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #124507|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=28529 --- Comment #10 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 134557 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=134557&action=edit Bug 28529: Add BiblioHoldItemTypeUseForRules system preference -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #11 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 134558 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=134558&action=edit Bug 28529: Unit tests -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #12 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 134559 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=134559&action=edit Bug 28529: Make biblio-level hold itemtype count against max rules The current situation is that biblio-level holds can be assigned an item type, so they can only be fulfilled by items matching that specified item type (be it item-level itype or the fallback to biblio-level). But there's the situation in which max holds limits for a specific item type can be overridden by using biblio-level holds with item type selection (AllowHoldItemTypeSelection) enabled. To test: 1. Have a patron of category 'Staff' (S) 2. Have 3 records with items with the 'BK' item type, and maybe others 3. Enable AllowHoldItemTypeSelection 4. Set a limit of 2 max holds for that category+item type 5. In the OPAC. Place bibio-level holds, with item type contraint to 'BK' on those 3 records => FAIL: You can place the 3 holds 6. Cancel the holds 7. Apply this patch and restart all 8. Repeat 5 => SUCCESS: You can only place 2 holds 9. Run: $ kshell t/db_dependent/Reserves.t => SUCCESS: Tests pass! 10. Sign off :-D -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #13 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Rebased. I still think this could've gone without the syspref and enabled by default. Yet, as-is it is good for inclusion. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #14 from David Nind <david@davidnind.com> --- Created attachment 134562 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=134562&action=edit Screenshots - behaviour after patches applied Hi Tomás. I finally managed to get this to work (I think)! Things I didn't do: - Make sure the 3 records had multiple books and some other type of items. - I didn't update the database after the patches were applied. - I didn't test with BiblioHoldItemTypeUseForRules set to 'Don't consider' (retains current behaviour - the total number of holds is not taken into account when multiple item types) and 'Consider' (limits number of holds to holds allowed (total)) when AllowHoldItemTypeSelection set to allow. However: 1. When I went to place a hold for record 3 (searching for 'a' after applying the patches) I didn't get any message - it just took me to the patron holds summary page and didn't place a hold. 2. Placing a hold for another record where there were only items with one item type showed the message "There are no items that can be placed on hold.", which seems like the correct behaviour to me. However, if I add another item to that record with a different item type, I get the same behaviour as in 1 - that is, I don't get any message and am taken to the patron holds summary screen. I've attached a PDF with some screenshots to illustrate what I mean. Also, for the new/updated system preference, should it be 'BiblioHold...' and 'biblio-level hold...' or 'RecordHold...' and 'record-level hold...'? I'm not sure of the correct terminology to use, considering we have several system preference names that include biblio, but all the descriptions now use bibliographic record. David -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #15 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Yes, there's no feedback on problems with selected options. I felt like it was out of the scope of the bug because any error on placing the hold is actually silently skipped, but 99.9% of the time the checks have been done first and the UI doesn't let you choose the problematic options. One way to trigger that is to choose to place some allowed hold, but before confirming, use another browser tab to add new holds that would invalidate the one we are about to place. In that case you will reproduce the silently skipped hold when you try to confirm it. I'll think of a proper solution tomorrow at my desk. Thanks! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 Tomás Cohen Arazi <tomascohen@gmail.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=28529 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #134557|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=28529 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #134558|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=28529 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #134559|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=28529 --- Comment #16 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 134790 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=134790&action=edit Bug 28529: Add BiblioHoldItemTypeUseForRules system preference -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #17 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 134791 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=134791&action=edit Bug 28529: Unit tests -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #18 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 134792 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=134792&action=edit Bug 28529: Make biblio-level hold itemtype count against max rules The current situation is that biblio-level holds can be assigned an item type, so they can only be fulfilled by items matching that specified item type (be it item-level itype or the fallback to biblio-level). But there's the situation in which max holds limits for a specific item type can be overridden by using biblio-level holds with item type selection (AllowHoldItemTypeSelection) enabled. To test: 1. Have a patron of category 'Staff' (S) 2. Have 3 records with items with the 'BK' item type, and maybe others 3. Enable AllowHoldItemTypeSelection 4. Set a limit of 2 max holds for that category+item type 5. In the OPAC. Place bibio-level holds, with item type contraint to 'BK' on those 3 records => FAIL: You can place the 3 holds 6. Cancel the holds 7. Apply this patch and restart all 8. Repeat 5 => SUCCESS: You can only place 2 holds 9. Run: $ kshell t/db_dependent/Reserves.t => SUCCESS: Tests pass! 10. Sign off :-D -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #19 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to David Nind from comment #14)
However:
1. When I went to place a hold for record 3 (searching for 'a' after applying the patches) I didn't get any message - it just took me to the patron holds summary page and didn't place a hold.
I took the current approach of checking holdability of each option so it doesn't offer the end user the forbidden item types. It should work as expected now. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Patch doesn't apply --- Comment #20 from David Nind <david@davidnind.com> --- Patch no longer applies 8-(.. git bz apply 28529 Bug 28529 - Item type-constrained biblio-level holds should honour max_holds as item-level do 134790 - Bug 28529: Add BiblioHoldItemTypeUseForRules system preference 134791 - Bug 28529: Unit tests 134792 - Bug 28529: Make biblio-level hold itemtype count against max rules Apply? [(y)es, (n)o, (i)nteractive] y Applying: Bug 28529: Add BiblioHoldItemTypeUseForRules system preference Applying: Bug 28529: Unit tests Using index info to reconstruct a base tree... M t/db_dependent/Reserves.t Falling back to patching base and 3-way merge... Auto-merging t/db_dependent/Reserves.t CONFLICT (content): Merge conflict in t/db_dependent/Reserves.t error: Failed to merge in the changes. Patch failed at 0001 Bug 28529: Unit tests -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 Tomás Cohen Arazi <tomascohen@gmail.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=28529 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #134792|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=28529 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #134790|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=28529 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #134791|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=28529 --- Comment #21 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 134809 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=134809&action=edit Bug 28529: Add BiblioHoldItemTypeUseForRules system preference -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #22 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 134810 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=134810&action=edit Bug 28529: Unit tests -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #23 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 134811 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=134811&action=edit Bug 28529: Make biblio-level hold itemtype count against max rules The current situation is that biblio-level holds can be assigned an item type, so they can only be fulfilled by items matching that specified item type (be it item-level itype or the fallback to biblio-level). But there's the situation in which max holds limits for a specific item type can be overridden by using biblio-level holds with item type selection (AllowHoldItemTypeSelection) enabled. To test: 1. Have a patron of category 'Staff' (S) 2. Have 3 records with items with the 'BK' item type, and maybe others 3. Enable AllowHoldItemTypeSelection 4. Set a limit of 2 max holds for that category+item type 5. In the OPAC. Place bibio-level holds, with item type contraint to 'BK' on those 3 records => FAIL: You can place the 3 holds 6. Cancel the holds 7. Apply this patch and restart all 8. Repeat 5 => SUCCESS: You can only place 2 holds 9. Run: $ kshell t/db_dependent/Reserves.t => SUCCESS: Tests pass! 10. Sign off :-D -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #134809|0 |1 is obsolete| | --- Comment #24 from David Nind <david@davidnind.com> --- Created attachment 134837 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=134837&action=edit Bug 28529: Add BiblioHoldItemTypeUseForRules system preference Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #134810|0 |1 is obsolete| | --- Comment #25 from David Nind <david@davidnind.com> --- Created attachment 134838 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=134838&action=edit Bug 28529: Unit tests Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #134811|0 |1 is obsolete| | --- Comment #26 from David Nind <david@davidnind.com> --- Created attachment 134839 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=134839&action=edit Bug 28529: Make biblio-level hold itemtype count against max rules The current situation is that biblio-level holds can be assigned an item type, so they can only be fulfilled by items matching that specified item type (be it item-level itype or the fallback to biblio-level). But there's the situation in which max holds limits for a specific item type can be overridden by using biblio-level holds with item type selection (AllowHoldItemTypeSelection) enabled. To test: 1. Have a patron of category 'Staff' (S) 2. Have 3 records with items with the 'BK' item type, and maybe others 3. Enable AllowHoldItemTypeSelection 4. Set a limit of 2 max holds for that category+item type 5. In the OPAC. Place bibio-level holds, with item type contraint to 'BK' on those 3 records => FAIL: You can place the 3 holds 6. Cancel the holds 7. Apply this patch and restart all 8. Repeat 5 => SUCCESS: You can only place 2 holds 9. Run: $ kshell t/db_dependent/Reserves.t => SUCCESS: Tests pass! 10. Sign off :-D Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #27 from David Nind <david@davidnind.com> --- I think I have tested this correctly. Another sign-off would be very welcome! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Medium patch -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #134837|0 |1 is obsolete| | --- Comment #28 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 134991 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=134991&action=edit Bug 28529: Add BiblioHoldItemTypeUseForRules system preference Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #134838|0 |1 is obsolete| | --- Comment #29 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 134992 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=134992&action=edit Bug 28529: Unit tests Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #134839|0 |1 is obsolete| | --- Comment #30 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 134993 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=134993&action=edit Bug 28529: Make biblio-level hold itemtype count against max rules The current situation is that biblio-level holds can be assigned an item type, so they can only be fulfilled by items matching that specified item type (be it item-level itype or the fallback to biblio-level). But there's the situation in which max holds limits for a specific item type can be overridden by using biblio-level holds with item type selection (AllowHoldItemTypeSelection) enabled. To test: 1. Have a patron of category 'Staff' (S) 2. Have 3 records with items with the 'BK' item type, and maybe others 3. Enable AllowHoldItemTypeSelection 4. Set a limit of 2 max holds for that category+item type 5. In the OPAC. Place bibio-level holds, with item type contraint to 'BK' on those 3 records => FAIL: You can place the 3 holds 6. Cancel the holds 7. Apply this patch and restart all 8. Repeat 5 => SUCCESS: You can only place 2 holds 9. Run: $ kshell t/db_dependent/Reserves.t => SUCCESS: Tests pass! 10. Sign off :-D Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |martin.renvoize@ptfs-europe |y.org |.com CC| |martin.renvoize@ptfs-europe | |.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA --- Comment #31 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- All works as described and resolves the bug.. Unit tests passing and QA script happy. I would argue we don't really need the system preference for this.. in my opinion, it's fixing an inconsistency/bug and thus would be a welcome change and consistency improvement so doesn't really need the option to enable/disable.. But I'll leave the final decision to the RM on that one. Passing QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #32 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Martin Renvoize from comment #31)
All works as described and resolves the bug.. Unit tests passing and QA script happy.
I would argue we don't really need the system preference for this.. in my opinion, it's fixing an inconsistency/bug and thus would be a welcome change and consistency improvement so doesn't really need the option to enable/disable.. But I'll leave the final decision to the RM on that one.
Passing QA
I think you're absolutely right. This is really a behavior inconsistency introduced by bug 15533 a lot of time ago! I agree 100% we shouldn't make it depend on that syspref. But I hoped to hear others 'complain about the fix' and overstepped. I will provide a follow-up removing it, just in case the RM prefers to pick it. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #134992|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=28529 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #134993|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=28529 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #134991|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=28529 --- Comment #33 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 135044 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=135044&action=edit Bug 28529: Regression tests Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #34 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 135045 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=135045&action=edit Bug 28529: Make biblio-level hold itemtype count against max rules The current situation is that biblio-level holds can be assigned an item type, so they can only be fulfilled by items matching that specified item type (be it item-level itype or the fallback to biblio-level). But there's the situation in which max holds limits for a specific item type can be overridden by using biblio-level holds with item type selection (AllowHoldItemTypeSelection) enabled. To test: 1. Have a patron of category 'Staff' (S) 2. Have 3 records with items with the 'BK' item type, and maybe others 3. Enable AllowHoldItemTypeSelection 4. Set a limit of 2 max holds for that category+item type 5. In the OPAC. Place bibio-level holds, with item type contraint to 'BK' on those 3 records => FAIL: You can place the 3 holds 6. Cancel the holds 7. Apply this patch and restart all 8. Repeat 5 => SUCCESS: You can only place 2 holds 9. Run: $ kshell t/db_dependent/Reserves.t => SUCCESS: Tests pass! 10. Sign off :-D Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 Fridolin Somers <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fridolin.somers@biblibre.co | |m --- Comment #35 from Fridolin Somers <fridolin.somers@biblibre.com> --- I propose to push this in next release, too risky at this end-of-cycle. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #36 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Fridolin Somers from comment #35)
I propose to push this in next release, too risky at this end-of-cycle.
+1 we've got enough to do. This bugfix can be easily backported anyway. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)| |22.11.00 released in| | Status|Passed QA |Pushed to master -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #37 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Pushed to master for 22.11. Nice work everyone, thanks! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 Lucas Gass <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to master |Pushed to stable Version(s)|22.11.00 |22.11.00, 22.05.01 released in| | CC| |lucas@bywatersolutions.com --- Comment #38 from Lucas Gass <lucas@bywatersolutions.com> --- Pushed to 22.05.x for 22.05.01 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #39 from Tomás Cohen Arazi <tomascohen@gmail.com> --- @RMaints: can we get this down to 21.05? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arthur.suzuki@biblibre.com --- Comment #40 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- Hi, tried to apply to 21.11.x but have conflicts. Didn't manage to fix them on the main patch. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #41 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 137964 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=137964&action=edit [21.11.x] Bug 28529: Regression tests Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 --- Comment #42 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 137965 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=137965&action=edit [21.11.x] Bug 28529: Make biblio-level hold itemtype count against max rules The current situation is that biblio-level holds can be assigned an item type, so they can only be fulfilled by items matching that specified item type (be it item-level itype or the fallback to biblio-level). But there's the situation in which max holds limits for a specific item type can be overridden by using biblio-level holds with item type selection (AllowHoldItemTypeSelection) enabled. To test: 1. Have a patron of category 'Staff' (S) 2. Have 3 records with items with the 'BK' item type, and maybe others 3. Enable AllowHoldItemTypeSelection 4. Set a limit of 2 max holds for that category+item type 5. In the OPAC. Place bibio-level holds, with item type contraint to 'BK' on those 3 records => FAIL: You can place the 3 holds 6. Cancel the holds 7. Apply this patch and restart all 8. Repeat 5 => SUCCESS: You can only place 2 holds 9. Run: $ kshell t/db_dependent/Reserves.t => SUCCESS: Tests pass! 10. Sign off :-D Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)|22.11.00, 22.05.01 |22.11.00, 22.05.01, released in| |21.11.11 Status|Pushed to stable |Pushed to oldstable --- Comment #43 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- backported to 21.11.x for 21.11.11. Thx! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28529 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|Pushed to oldstable |RESOLVED CC| |victor@tuxayo.net --- Comment #44 from Victor Grousset/tuxayo <victor@tuxayo.net> --- Not backported to oldoldstable (21.05.x). Feel free to ask if it's needed. Nothing to document, marking resolved. -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org