[Phpmyadmin-devel] Piotr's tree and sensible options

Marc Delisle marc at infomarc.info
Wed Jul 21 17:59:33 CEST 2010

Piotr Przybylski a écrit :
> 2010/7/21 Marc Delisle <marc at 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):

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.

Marc Delisle

More information about the Developers mailing list