In order to determine if an item should be hidden for a specific patron category, we now need to: - Read and parse OpacHiddenItemsExceptions - Verify it is a real category (subject to typos) - Compare to the current patron category This would be avoided by just having an attribute on the categories table (e.g. overrides_hidding_policy). I leave choosing the right attribute name to native speakers.
+1
+1, great idea.
Given the amount of places in which lots of code will need to be refactored (for good), I will file a series of bugs of which this will be the last one, and involve specifically the removal of the syspref and the use of the new attribute.
This is a global override, this is not the branch-based override as envisioned in bug 10589. So, perhaps both overrides, outright and partial based on matching item homebranch and patron branch, should be fields in the patron category table.
Thinking about this in the context of bug bug 10589: this is a clear use case for bug 26129. - This bug tries to implement a flag on Koha::Patron::Categories. - Bug 10589 pretends to make that flag per-category. This could just be a per-branch configuration for each category, or a global value. This is all covered by bug 26129. This bug and 10589 would just be choosing the right 'keyword' for the configuration entry, and adding the UI (on the categories?) and then using the methods to retrieve the configuration based on the parameters.
I am not sure if this is still valid now that we have the nice multi-select on the system preference. A con is that as a pref the OpacHidden* related features can appear in one spot. A contra could be that you need to remember to set this up if a new patron category is added.