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.
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.clk... _______________________________________________ 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.
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 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.
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.
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');
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=Feat...
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=Feat...
Changes done.
-
Marc Delisle -
Mohamed Ashraf -
Piotr Przybylski