https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31642
Pedro Amorim <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #13 from Pedro Amorim <[email protected]> --- Observations: A) If you have an HTML customization on location e.g. 'CookieConsentPopup', and then delete the 'CookieConsentPopup' AV value from ADD_CONT_HTML_OPAC_SYSTEM, at least 2 things will happen: 1) Whenever you edit the existing HTML customization that's still pointing to the - now non-existent - 'CookieConsentPopup' location, the form will render 'ArticleRequestsDisclaimerText' (or whatever is the first alphabetical AV to be shown) as the current location. In short, the form will show false information. 2) The HTML customization is still displayed on whatever location it is still set to, because the code that fetches a HTML customization by a location is still looking for it. In other words, a staff member that deleted that AV from ADD_CONT_HTML_OPAC_SYSTEM potentially thinks that that location is not displayed anymore (because it no longer exists), but that's not the case. B) 'Custom' is shown at the bottom of the dropdown as a parent level entry even if there are no children i.e. ADD_CONT_HTML_CUSTOM is empty. C) Apologies for not understanding the original requirement, I'm certainly missing something obvious, but can you please clarify? 'I want to add locations that match authorised values for category CONSENT_TYPE.' How would you use the work from this patchset? Would you be adding entries to ADD_CONT_HTML_CUSTOM and then how would those locations be rendered Through a plugin? In other words, how would entries from 'ADD_CONT_HTML_CUSTOM' be utilized? Failing QA especially because of observation A). I think this gives the staff member the ability to potentially shoot themselves in the foot by deleting an AV entry that the code directly expects it to exist, and that'll lead to future problems. Personally, I agree with comment 1 regarding having a "is_system" column in the authorised_values table and believe that would be the solution here to prevent deleting/editing AV entries that the system expects to exist. -- 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/
