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

Piotr Przybylski piotr.prz at gmail.com
Wed Jul 21 18:21:23 CEST 2010

2010/7/21 Marc Delisle <marc at infomarc.info>:
> 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):
> *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

Does anybody else have some opinion on this?

Piotr Przybylski

More information about the Developers mailing list