http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10325
M. de Rooy <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |In Discussion --- Comment #5 from M. de Rooy <[email protected]> --- (In reply to comment #2) > I can imagine an edge case, though -- there's nothing stopping one from > using this in the *intranet* virtual host definitions (and I could imagine a > Koha administrator wanting to do this to allow local admins access to system > preferences while locking down ones such as 'marcflavour' that should never > be changed). But that could really confuse somebody who is wondering why > their system preference change isn't having the desired effect. > > Perhaps the system preference editor should be taught how to recognize > overriden sysprefs? I think that this feature is indeed very interesting, but dangerous at the other side. Galen's idea to make it visible in the pref editor is a good one too. Why not e.g. disable editing the pref when it is overridden? Other color? But it will be very difficult to say which prefs should be excluded from overriding. You could start with Version, marcflavour, etc. but will become very arbitrary at the end. And yet another idea: If you have a pref, yes.., AllowOverridingPrefValues or something, you could say that the admin at least knows which adventure he started? > > + if ( defined $ENV{"OVERRIDE_SYSPREF_$var"} ) { > > The test should be 'exists', no? If it does not exist, it is undefined? It could even exist and be undefined (pure theoretically).. Setting status to In Discussion. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://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/
