https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31642
--- Comment #20 from Pedro Amorim <pedro.amo...@openfifth.co.uk> --- (In reply to Marcel de Rooy from comment #19) > The idea of using is_system on the value level would be nice but no complete > solution for both issues. Deleting a custom value would still be a problem. From my understanding, custom HTML customization locations are meant to only be used by plugins (e.g. core is not querying or using'em). If this is the case, isolating this possible issue only to installations that use said plugins would be better than not handling it at all. 'is_system' AV entries should, at the very least, not be deletable through the UI, imo. Additionally, plugin code making use of 'custom' locations should know that, because they're 'custom', they may or may not exist, so can error handle accordingly. Whereas core Koha using 'is_system' should ideally never need to handle the case of them not existing. > If you delete values from a category, the Koha combo boxes here and there > will > currently display a wrong entry too. True, but we should at least consider displaying "!" with some text like "current value doesn't match any of the options" or similar. I know this patchset doesn't introduce this pattern in Koha, but it's adding yet another possibility where it may happen. > Writing a module for additional actions after an AV modify or delete crossed > my mind, but looks like a larger exercise with pitfalls as to performance > etc. We should have action hooks like 'before/after_object_update', 'before/after_object_create' and 'before/after_object_delete' at Koha::Object level and then any plugin could do whatever they wanted. As to performance, every other OS framework out there does this, surely we could work around these eventual challenges. But this is way outside the scope of this bug. > So in conclusion, how should we proceed here? Or just abandon it? I don't know. I don't feel comfortable PQAing it as is because it adds the possibility for staff members to create problems for themselves in a place that they couldn't before, but I also understand it's a deeper/wider problem not exclusive to this patchset. A possible alternative here would be to add a filter hook to get_html_customizations_options added in bug 39900. Needs some changes but would allow for plugins to hook into the list of available customization locations and add whatever they want. Though personally I think the 'is_system' approach for AV values would benefit Koha more as a whole. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list Koha-bugs@lists.koha-community.org 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/
