Piotr Przybylski a écrit :
2010/7/21 Marc Delisle marc@infomarc.info:
Piotr Przybylski a écrit :
2010/7/21 Marc Delisle marc@infomarc.info:
Piotr Przybylski a écrit :
Yes, config file has a key 'UserprefsDisallow', which contains names of values that users cannot override. Also, setup script has checkboxes (next to each option) which allow to modify this. Settings in 'UserprefsDisallow' are marked as DISABLED in user preferences (and are listed in Blacklist section of my debug message).
Great!
In addition to disabling options, some are only partially editable by users. Namely:
- MaxDbList, MaxTableList, QueryHistoryMax - users can set values
which are equal to or lower than the one hardcoded in config.*.php
- AllowUserDropDatabase, UseDbSearch, QueryHistoryDB, ShowPhpInfo,
ShowChgPassword - these can be only disabled (changed from true to false), enabling them is impossible for users
Both cases above are marked by an icon with comment in setup script.
I don't find intuitive that for some options, a checkmark means true and that for others, it means false (I know that you displayed "disable" but it requires more reflexion from the users).
The only alternative I can think of, would require a js-enabled browser to block enabling the option.
I made it that way because I want to keep stored data at a minimum (only differences to defaults) and code straightforward (it's already complex enough), and adding a few options defaulting to false gives me a nice and simple switch to use. When detecting checkbox value I can only tell whether it is on, or off/not available.
I will think about using <select>s there, maybe then the solution will still be simple enough and more obvious. Or maybe I should move all these settings to a new tab, where this behavior would be described? "disable" text would stay, to alert user that something about this form is different.
Added to my todo list, first I will check whether <select>s would be suitable for the task.
I am beginning to wonder if these options (that can only be disabled): *AllowUserDropDatabase *UseDbSearch *QueryHistoryDB *ShowPhpInfo, *ShowChgPassword
Another example is UseDbSearch; this would be disabled in config.inc.php because we want to avoid stressing the server, right? So I don't see the point of permitting a user to disable it for himself. It would mean that when he disables this in Settings, he's aware of the possible overhead but if he makes a db Search he's not aware...