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
make sense to offer in the user prefs interface. For example, if I want to block myself (remember, this is just about the current user) to change a password, do I need a setting to do so? I'll just avoid changing a password from the interface.
I was thinking about giving users a choice to hide some UI settings, but it we drop it the issue of problematic inputs for them will also disappear.
Does anybody else have some opinion on this?