Bug 20955

Summary: Add ability to trigger item-level holds that violate holds policies (overridden holds)
Product: Koha Reporter: Nick Clemens (kidclamp) <nick>
Component: CirculationAssignee: Nick Clemens (kidclamp) <nick>
Status: In Discussion --- QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: andrew, bywater, carthur, Chip.Halvorsen, chris.rowlands6, christophe.croullebois, dcook, emily.lamancusa, gmcharlt, katrin.fischer, kebliss, kyle, madamyk, margaret, mfuerst, mspinney, phillip.berg, rpalermo
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27464
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:
Bug Depends on: 31169    
Bug Blocks:    
Attachments: Bug 20955: Add systempreference to allow triggering forbidden holds
Bug 20955: Unit tests

Description Nick Clemens (kidclamp) 2018-06-15 14:22:07 UTC
Some libraries would like holds placed by staff that override holds policies to trigger during checkin.
Comment 1 Nick Clemens (kidclamp) 2018-06-15 14:26:04 UTC
Created attachment 76101 [details] [review]
Bug 20955: Add systempreference to allow triggering forbidden holds

To test:
1 - Set a holds policy to allow only holds from homebranch
2 - Place a hold on an item for a patron from another branch
3 - Checkin item
4 - Hold does not trigger
5 - Apply patches and updatedatabase
6 - Check in item
7 - Hold triggers
Comment 2 Nick Clemens (kidclamp) 2018-06-15 14:26:07 UTC
Created attachment 76102 [details] [review]
Bug 20955: Unit tests

prove -v t/db_dependent/Holds/HoldFulfillmentPolicy.t
prove -v t/db_dependent/Reserves.t
Comment 3 Martha Fuerst 2019-05-15 20:27:03 UTC
This is me being a squeaky wheel. We would love to help test this, as it would greatly benefit how we deal with holds that occasionally come out of our Outreach collection.

-Marti Fuerst
Comment 4 Katrin Fischer 2023-09-16 08:23:04 UTC
I feel like this goes a little too far, because it would trigger holds for all items, independent on how the hold was placed - it doesn't check if it was an overridden hold. It feels like we should have a flag or similar on the reserves table when that happens.
Comment 5 Emily Lamancusa (emlam) 2023-10-03 14:36:07 UTC
*** Bug 28788 has been marked as a duplicate of this bug. ***
Comment 6 Emily Lamancusa (emlam) 2023-10-03 15:38:54 UTC
+1 for adding a flag - holds violating the holds policy should trap if and only if the hold policy was explicitly overridden. Retaining that information in a flag seems like a good way to enforce that.

Even with an override flag, there are some possible side effects with bib level holds, though... For sure I can see problems for consortia that have set-in-stone rules about which branches can and cannot share resources, but allow overrides for other reasons. With a simple true/false override flag, a hold that was placed with an override for other reasons (e.g. patron category, hold limits, etc) could unintentionally override the branch restriction and trigger a transfer that may not be possible or reasonable to actually fulfill.

I'm not sure what the solution is here.
- Flagging which specific policies were overridden when the hold was placed? (seems messy and with a high potential for side effects)
- More granularity in the sysprefs governing which policies are allowed to be overridden at all? (I think this would be great, but not sure if this is the right place)
- Apply this enhancement only to item-level holds, or give TriggerForbiddenHolds three settings - All / Item-level only / Off?

We at MCPL would definitely like to see something like this go through (our staff often place holds to get their hands on items for workflow reasons, and currently that doesn't work for items that aren't normally holdable). But I think it needs a bit more examination to make sure it isn't unusable for systems that need to keep some things set in stone.
Comment 7 Andrew Fuerste-Henry 2025-10-29 12:45:29 UTC
*** Bug 17884 has been marked as a duplicate of this bug. ***
Comment 8 rpalermo 2025-10-29 19:48:14 UTC
This is how we always thought it was supposed to work. If the hold is placed with an override in Koha staff side, it should be filled at checkin. What other reason would there be to override and place the hold if not to have it get trapped?
Comment 9 David Cook 2025-12-17 04:16:28 UTC
It was driving me crazy trying to figure out why the hold wasn't being trapped, and it was because the "Hold policy" was set to "No holds allowed" for the branch library.

--

That said, I might agree about the patch not being enough. As Katrin said, there's no way to know that this was an overridden hold. That said, that makes this extremely difficult to fix with the current code.


(In reply to rpalermo from comment #8)
> This is how we always thought it was supposed to work. If the hold is placed
> with an override in Koha staff side, it should be filled at checkin. What
> other reason would there be to override and place the hold if not to have it
> get trapped?

But I also agree with this. I mean if a hold exists, it must mean that it followed the rules at the time of its placement (whether via an override or not), so surely we should trap the hold. 

But... I guess we're looping through reserves at this point... and the branch with "No holds allowed" shouldn't fill the hold but a different branch could, so it wouldn't make sense to trap the hold in this case.

--

Holds are a very challenging area...
Comment 10 Phillip Berg 2025-12-17 20:51:49 UTC
We're definitely interested in this as well. Having it as an option would be hugely helpful when trying to do more complex throttling when it comes to holds fulfillment as well.
Comment 11 David Cook 2026-01-05 02:46:17 UTC
I'm not sure if anyone is going to have the resources to do this one, and yet it needs to be done.
Comment 12 David Cook 2026-01-05 04:50:41 UTC
Something is bugging me with this...

If it's an item-level hold which we placed with an override, and we have the item in hand, surely we would want to honour the hold. 

If it were a "next available" hold, then... I could see not honouring it, because we have no way of knowing that the hold placer is authorized to have this item fulfil that hold?
Comment 13 Andrew Fuerste-Henry 2026-01-05 13:31:11 UTC
I see a general consensus that it makes sense to capture items for item-level holds that violate hold policy. I've retitled this bug to reflect that smaller scope.

This leaves us with the broader issue of how to handle bib-level hold policy overrides to be tackled in other bugs.
Comment 14 Katrin Fischer 2026-01-07 12:55:14 UTC
*** Bug 13559 has been marked as a duplicate of this bug. ***
Comment 15 Katrin Fischer 2026-01-07 12:56:47 UTC
Maybe it could be an alert that requires confirmation, so that had the option to decide what to do. But that would leave the question on how to handle these at the self check.