Bug 41267 - It should be possible to prevent some itemtypes from filling other biblio level holds
Summary: It should be possible to prevent some itemtypes from filling other biblio lev...
Status: Failed QA
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Nick Clemens (kidclamp)
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-11-18 19:07 UTC by Nick Clemens (kidclamp)
Modified: 2025-12-23 15:50 UTC (History)
11 users (show)

See Also:
GIT URL:
Initiative type: ---
Sponsorship status: ---
Comma delimited list of Sponsors:
Crowdfunding goal: 0
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Bug 41267: Add fill_other_biblio_holds_policy circulation rule (17.17 KB, patch)
2025-11-18 19:18 UTC, Nick Clemens (kidclamp)
Details | Diff | Splinter Review
Bug 41267: Add fill_other_biblio_holds_policy circulation rule (18.91 KB, patch)
2025-12-15 16:16 UTC, Nick Clemens (kidclamp)
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Clemens (kidclamp) 2025-11-18 19:07:12 UTC
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
Comment 1 Nick Clemens (kidclamp) 2025-11-18 19:18:25 UTC
Created attachment 189682 [details] [review]
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
Comment 2 Jason Robb 2025-11-21 21:32:08 UTC
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.
Comment 3 Nick Clemens (kidclamp) 2025-12-15 16:16:40 UTC
Created attachment 190518 [details] [review]
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
Comment 4 Christopher Brannon 2025-12-18 19:07:35 UTC
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.
Comment 5 Nick Clemens (kidclamp) 2025-12-19 02:02:45 UTC
(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
Comment 6 Christopher Brannon 2025-12-19 16:39:28 UTC
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.
Comment 7 Jason Robb 2025-12-23 15:50:50 UTC
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?