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

[Piotr Przybylski]

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
disappear.

Does anybody else have some opinion on this?

-- 
Piotr Przybylski