https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 --- Comment #1 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 76101 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=76101&action=edit 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 -- 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=20955 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |ASSIGNED -- 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=20955 Martha Fuerst <mfuerst@hmcpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mfuerst@hmcpl.org --- Comment #3 from Martha Fuerst <mfuerst@hmcpl.org> --- 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 -- 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=20955 --- Comment #4 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emily.lamancusa@montgomeryc | |ountymd.gov Status|ASSIGNED |In Discussion --- Comment #6 from Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> --- +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. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 Chris Rowlands <chris.rowlands6@nhs.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chris.rowlands6@nhs.net -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |christophe.croullebois@bibl | |ibre.com --- Comment #7 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- *** Bug 17884 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 --- Comment #8 from rpalermo@oslri.net --- 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? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 Chip Halvorsen <Chip.Halvorsen@WestlakeLibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Chip.Halvorsen@WestlakeLibr | |ary.org -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 Katie Bliss <kebliss@dmpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kebliss@dmpl.org -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 Michelle Spinney <mspinney@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mspinney@clamsnet.org -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 --- Comment #11 from David Cook <dcook@prosentient.com.au> --- I'm not sure if anyone is going to have the resources to do this one, and yet it needs to be done. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Add ability to trigger |Add ability to trigger |holds that violate holds |item-level holds that |policies (overridden holds) |violate holds policies | |(overridden holds) --- Comment #13 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- 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. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 --- Comment #15 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #76102|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=20955 --- Comment #17 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #16)

Well, I just went to test the original scenario in main and now I can't place holds that violate hold policy even with AllowHoldPolicyOverride set to "Allow".

I mean it gives me the option but when you click "Place hold" when trying to hold a specific item, it just seems to redirect you back to request.pl. Fun times...

Ah nevermind. That's because I didn't set a pickup library. Different bug there it seems... -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 --- Comment #19 from David Cook <dcook@prosentient.com.au> --- This code is a bit nauseating to look at 😅. There's so many different permutations of holds rules... and any change will break one of these tests: t/db_dependent/Koha/Holds.t t/db_dependent/Holds.t t/db_dependent/Circulation.t t/db_dependent/Holds/LocalHoldsPriority.t t/db_dependent/Holds/HoldItemtypeLimit.t t/db_dependent/Holds/HoldFulfillmentPolicy.t t/db_dependent/Reserves.t I don't think that I know holds/reserves well enough to try to fiddle with the business logic. -- Maybe when placing the hold, we have to capture that it has an override attached to it, and then in CheckReserves if there's an override we ignore all the policy stuff. That could be a way where we honour the existing business logic while also trying to honour the override... Both item-specific and bib-level holds could contain the override in their reserve... so that could work for both. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 --- Comment #21 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #20)

Yeah, I think I'm proposing adding an "override_policy" column to reserves and old_reserves.

Then in CheckReserves we could wrap the policy checks with a check for "override_policy".

At the moment, that's the only thing I can think of that will work.

What do folk think of that idea? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 --- Comment #23 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Agreed, David's plan to add a field to reserves in which to record that a given hold required an override makes sense and Katrin's correct that it would be helpful for that field to record the type of override. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 --- Comment #25 from rpalermo@oslri.net --- This override note would be ideal if it was automatically recorded with no additional staff action. It's not necessary for OSL's purposes since we would know that it was placed with an override just by having the hold active. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 --- Comment #27 from David Cook <dcook@prosentient.com.au> --- (In reply to Katrin Fischer from comment #26)

(In reply to David Cook from comment #24)

...

(In reply to Katrin Fischer from comment #22)

...

I think that makes sense. Maybe instead of just a boolean flag we will want to note why kind of hold policy was overriden. If it was an override of the max holds it has a different effect (now too) as if it was an override of an item that is usually not holdable at all.

Hmm that's interesting. I don't know if we can capture that information. What's the different effect?

The "max holds" create no issues afaik as the hold will trigger and behave normally. But if you place a hold on an unholdable item, the hold won't trigger currently, so these are probably the ones we want to target here.

Ah, I understand now. Looking at CheckReserves, I was thinking we'd just group the policy ones together. Adding a note for the override could get burdensome. placerequest.pl would need some updates because it turns out that $can_override actually gets checked before CanBookBeReserved. So we'd need to change the precedence there. I think there also needs to be a parameter sent to indicate that an override has been requested. At the moment, the value of AllowHoldPolicyOverride is all that is used in order to trigger an override, and I guess the ability for someone to place an override in the first place. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lisette@bywatersolutions.co | |m -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 Brendan Lawlor <blawlor@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |blawlor@clamsnet.org -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 --- Comment #30 from David Cook <dcook@prosentient.com.au> --- To reproduce: 0. Use a fresh KTD 1. Go to http://localhost:8081/cgi-bin/koha/admin/smart-rules.pl 2. Set "Hold policy" to "From home library" for "Standard rules for all libraries" 3. Set "AllowHoldPolicyOverride" syspref to "Allow" 4. Go to http://localhost:8081/cgi-bin/koha/reserve/request.pl?biblionumber=134&borrowernumber=51 5. Note that you can still place bib-level and item-level holds -- So the problem here is... maybe you have a library network that requires you to borrow and return from the same branch as they don't have a transportation service that can take books from one location to another. But maybe they have "AllowHoldPolicyOverride" set to "Allow" because sometime they need to allow people to go over their hold limits. But then you might have a library network with library groups where you've overridden a hold policy for one of them, and you'd be ok with a bib-level hold being filled within the library group, but not for other parts of the network. We could include some algorithms to try to take this all into account, but... it's going to add complexity to an already poorly understood part of code... -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 --- Comment #32 from David Cook <dcook@prosentient.com.au> --- Workarounds... in C4::Circulation::AddReturn we do the following: my ( $resfound, $resrec ); my $lookahead = C4::Context->preference('ConfirmFutureHolds'); #number of days to look for future holds ( $resfound, $resrec, undef ) = C4::Reserves::CheckReserves( $item, $lookahead ) unless ( $item->withdrawn ); # FIXME: CheckReserves should return the Koha::Hold my $hold = Koha::Holds->find( $resrec->{reserve_id} ); # if a hold is found and is waiting at another branch, change the priority back to 1 and trigger the hold (this will trigger a transfer and update the hold status properly) if ( $resfound and $resfound eq "Waiting" and $branch ne $resrec->{branchcode} ) { $hold->revert_found(); $resfound = 'Reserved'; $resrec = $hold->unblessed; } if ($resfound) { $resrec->{'ResFound'} = $resfound; $messages->{'ResFound'} = $resrec; } -- Technically, C4::Reserves::CheckReserves does return 3 values in most cases: return ( "Waiting", $res, \@reserves ); return ( "Processing", $res, \@reserves ); return ( "Transferred", $res, \@reserves ); return ( "Reserved", $highest, \@reserves ); It's only if there is no $highest set that we return nothing. So maybe... what we can do is if "AllowHoldPolicyOverride" is set to allowed... we return the possible reserves and present the top 5 or something to the staff member and they can decide which hold the item should fill? -- But... the problem with that is that it assumes that there's no other holds that this item could fill. It might be that the next hold to fill is a forbidden hold but the other holds in the queue after it are allowed holds. This would never work for that scenario. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42863 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 --- Comment #34 from David Cook <dcook@prosentient.com.au> --- It's hard enough just recording that a hold was subject to a hold policy override... heh (see bug 42863) But once we do have that in... then we'll at least know which holds require special treatment. -- You are receiving this mail because: You are watching all bug changes.