19 Nov
2013
19 Nov
'13
10:22 p.m.
Piotr Przybylski a écrit :
2013/11/19 Marc Delisle <marc(a)infomarc.info>
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');
--
Marc Delisle
http://infomarc.info
Piotr Przybylski a écrit :
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. 2013/11/19 Marc Delisle
<marc(a)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.