https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955
Emily Lamancusa <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emily.lamancusa@montgomeryc | |ountymd.gov Status|ASSIGNED |In Discussion --- Comment #6 from Emily Lamancusa <[email protected]> --- +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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
