[Phpmyadmin-devel] Piotr's tree and sensible options
marc at infomarc.info
Wed Jul 21 18:32:44 CEST 2010
Piotr Przybylski a écrit :
> 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).
>>>>> 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):
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...
More information about the Developers