[Phpmyadmin-devel] about ErrorReporting and SendErrorReports

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. -- Marc Delisle http://infomarc.info

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.
-- Marc Delisle http://infomarc.info
------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel

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. -- Marc Delisle http://infomarc.info

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. -- Regards, Piotr Przybylski

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. -- Marc Delisle http://infomarc.info

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. -- Regards, Piotr Przybylski

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'); -- Marc Delisle http://infomarc.info

2013/11/19 Marc Delisle <marc@infomarc.info>
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');
Exactly, that's what this function is designed to do. We just need to add SendErrorReports to setup script in place of ErrorReporting. Then setup script will display a checkbox that allows for adding it to UserprefsDisallow in generated config (right aligned checkbox at [1]). [1] http://demo.phpmyadmin.net/master/setup/index.php?page=form&formset=Features... -- Regards, Piotr Przybylski

Le 2013-11-19 15:17, Piotr Przybylski a écrit :
2013/11/19 Marc Delisle <marc@infomarc.info <mailto:marc@infomarc.info>>
Piotr Przybylski a écrit : > 2013/11/19 Marc Delisle <marc@infomarc.info <mailto:marc@infomarc.info>> > >> Piotr Przybylski a écrit : >>> 2013/11/19 Marc Delisle <marc@infomarc.info <mailto: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');
Exactly, that's what this function is designed to do. We just need to add SendErrorReports to setup script in place of ErrorReporting. Then setup script will display a checkbox that allows for adding it to UserprefsDisallow in generated config (right aligned checkbox at [1]).
[1] http://demo.phpmyadmin.net/master/setup/index.php?page=form&formset=Features...
Changes done. -- Marc Delisle http://infomarc.info
participants (3)
-
Marc Delisle
-
Mohamed Ashraf
-
Piotr Przybylski