Summary: | Add ability to trigger holds that violate holds policies (overridden holds) | ||
---|---|---|---|
Product: | Koha | Reporter: | Nick Clemens (kidclamp) <nick> |
Component: | Circulation | Assignee: | Nick Clemens (kidclamp) <nick> |
Status: | In Discussion --- | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | emily.lamancusa, gmcharlt, kyle.m.hall, madamyk, margaret, mfuerst |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | 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
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 Created attachment 76102 [details] [review] Bug 20955: Unit tests prove -v t/db_dependent/Holds/HoldFulfillmentPolicy.t prove -v t/db_dependent/Reserves.t 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 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. *** Bug 28788 has been marked as a duplicate of this bug. *** +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. |