https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39860 --- Comment #53 from David Cook <dcook@prosentient.com.au> --- (In reply to Lisette Scheer from comment #52)
(In reply to David Cook from comment #51)
So the WYSIWYG thing is an issue for sure.
We might want to make a change to the HTML customizations feature (or rather DB schema) that allows us to specify that some can only be edited using the text editor and not the WYSIWYG I reckon...
In my in progress work on css and js snippets I'm doing this to make them always load the text:
[% IF ( wysiwyg ) && category != 'js_snippets' && category != 'css_snippets' %] [% SET editmode = "wysiwyg" %]
Hard-coding might work for a POC but I think we'll probably want to put that into the database.
I worry about being too restrictive when the library is already going to be vetting employees.
I don't think most libraries worldwide are vetting their employees very carefully or at all.
Could we compromise by doing a more restrictive scrub unless you have specific permissions and not allow editing of ones that would be scrubbed if you didn't have the right permission?
Honestly, I'd say both-and rather than either-or. The person editing the UI should have higher permissions than someone adding a news item. But it should still be scrubbed either way. Content management systems do this, and if we're going to offer content management, we need to do it too. -- Does Bywater already have this feature locally? If so, then it should be easy to come up with a list of elements and attributes to allow list. If not, then I think we use the Wordpress list as a first pass. If there is concern that it won't be comprehensive enough, then we need to make a way to re-configure it on the backend. -- You are receiving this mail because: You are watching all bug changes.