Piotr Przybylski a écrit :
> 2013/11/19 Marc Delisle <marc@infomarc.info>
>
>> Piotr Przybylski a écrit :
>>> 2013/11/19 Marc Delisle <marc@infomarc.info>
>>>
>>>> Le 2013-11-18 19:37, Mohamed Ashraf a écrit :
>>>>> On Monday, November 18, 2013 at 7:06 PM, Marc Delisle wrote:
>>>>>> Hi Mohamed,
>>>>>>
>>>>>> Why do we need two configuration directives? I guess that instead of
>>>>>> verifying whether ErrorReporting is true, we could just verify whether
>>>>>> SendErrorReports is different than 'never' to load the js files.
>>>>>>
>>>>>> If you confirm my suggestion, I'll make the changes.
>>>>>>
>>>>> One was actually meant for the hoster of the phpmyadmin installation
>> and
>>>>> one for the user. If you donot want the phpmyadmin deployer to have
>>>>> control over it you can remove it.
>>>>>
>>>>> I just thought this is a new system and if a fatal bug is not caught
>>>>> before a release we need to have an easy way for a deployer using that
>>>>> release to disable it.
>>>>>
>>>>> Or if for whatever reason the data is secretive enough that he diesnt
>>>>> want it on our publc servers if he doesnt trust it is anonymous enough.
>>>> Thanks, I accept your explanation and I'll just add some documentation.
>>>>
>>>>
>>> Hosters can disable ErrorReporting and add it to UserprefsDisallow:
>>> $cfg['UserprefsDisallow'] = array('UserprefsDisallow');
>>>
>>> That way users won't be able to override their settings.
>> Piotr,
>> ErrorReporting is not part of user preferences, but SendErrorReports is.
>>
>>
> Yes, you are right. I just gave it as an example that it can be done with
> just one switch.

I see what you mean. So we don't need the ErrorReporting directive. To
block the feature completely, the deployer would do

$cfg['SendErrorReports'] = 'never';
$cfg['UserprefsDisallow'] = array('SendErrorReports');