Bug 27464 - Extend functionality of AllowHoldsPolicyOverride to prevent some overrides
Summary: Extend functionality of AllowHoldsPolicyOverride to prevent some overrides
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 31169
Blocks:
  Show dependency treegraph
 
Reported: 2021-01-18 14:48 UTC by Michael Adamyk
Modified: 2025-11-18 19:40 UTC (History)
4 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

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Adamyk 2021-01-18 14:48:27 UTC
If one tries to create a "local use only" item type, there isn't a good way to make it impossible to place holds for anywhere other than its home branch. 

Setting restrictions on it in Circ rules allows any staff member with permissions to override the hold restrictions. 

Another option is setting an item to a lost status, but this is certainly not ideal: it clears the status every time the item is scanned, and it affects how it appears in the OPAC. 

What if there were a way to have finer control over the AllowHoldsPolicyOverride system preference? For instance, allow hold overrides as a separate permission for overriding circulation rules vs. overriding patron restrictions. It seems logical that overriding a restriction to check out to a patron is quite a bit different from ignoring specific circulation rules (if that makes sense).

Perhaps another way to work around this would be a checkbox in the circulation rules with an option to "Ignore staff overrides" or something similar? It could be turned on or off for each individual circulation rule.
Comment 1 Katrin Fischer 2021-01-18 23:08:08 UTC
Thx for filing Michael!
Comment 2 Christopher Brannon 2022-02-02 19:11:11 UTC
Since the topic is on AllowHoldsPolicyOverride, I would also like to suggest that there be a permission in patron permissions for this.  We don't want everyone being able to override holds.

While we don't want everyone being able to place holds on lost items, there are situations where we want to have a staff member place a hold on a lost item, as they may have to decide if this item will continue circulating.  Currently we can't do that unless we turn this setting on, but we don't want to just turn it on for everyone to override.
Comment 3 mteal 2025-01-24 18:34:36 UTC
I agree with the idea of having a patron permission to allow overrides to holds. It'd be nice to have a middle ground between allowing everybody to override all hold policies and nobody being able to.
Comment 4 Andrew Fuerste-Henry 2025-10-29 13:03:37 UTC
I've filed bug 41130 for tying hold overrides to a permission, akin to the force_checkout permission for the various checkout overrides.

I've added a See Also to Bug 20955, which seeks to address the fact that AllowHoldPolicyOverride currently allows one to place holds that will never capture an item at checkin.

On this bug, I favor the approach of splitting AllowHoldPolicyOverride into at least two systempreferences. 

One of the checkout override preferences is "AllowTooManyOverride," to allow checkouts when the patron has reached the maximum number of allowed checkouts. I suggest the addition of AllowTooManyHoldsOverride to allow holds beyond the maximum number of allowed checkouts.

That would leave the existing AllowHoldPolicyOverride tied to overrides related to Hold Policy and Hold Pickup Library Match (and branch transfer limits?).