Comment 3 for bug 1869971

So, being responsible for initially committing this and not thinking it through enough at the time I don't believe it can realistically be made robust in the 3.5 timeframe and am for reverting these master / 3.5 commits:
485624d4a7bc8d44843857060b72a813e47573ab
11868e97844a47d57489062197ac6809d9473366

and these master only commits:
3b9b5e7b22d2b39f11dc518d1023abac9d067901
f11b2356b39e5e7a1a3b728c072cd531dc93125d
da42d5649ea4bc12a2d2ab28d4bddca15ad0278d

(master only because I forgot yesterday that rel_3_5 had already been cut and rather than now also push them to rel_3_5 the feature can just be reverted everywhere applicable.) I do think upgrade script numbers 1196 (obviously) and 1201 should still be considered burned to prevent any possible future confusion. (Or altered to just insert the number and do nothing? Another point for discussion.)

I haven't done this yet because I wanted to see more people chime in on this first. (Though if someone is sufficiently motivated or impatient before that I won't complain.)

That said, I don't believe that bug 1849152 and bug 1849113 should be written off as things never to be considered; they can be a powerful way to allow less technical users (granted the appropriate permissions and warnings, etc.) to customize their installation in minor ways without having to involve a system admin just because you want to change the color of some widget from green to blue or similar. This is the primary way that customizations are performed in Koha, though I have yet to look at what they may be doing to prevent rogue admins from doing undesirable. (I don't really believe you can do a whole lot to "verify" the JavaScript stuff other than only granting the currently missing permission to people that you would also trust with psql access, or give the feature a 2-step change, then verify/apply mechanism.)