I work on a french project where I have to set a usergroup for each state (département). In France we have 97 states but it seems that there's a limit for Joomla UserGoups and subgroups. In fact if I set my 97 usergroups, I can't record changes in configuration panel, set a plugin, etc..
Do you confirm that there's a limit for usergroup in Joomla ?
Thx for answers
What exactly happens? The problem is likely in the user interface, not
in the actual processing. We need to have a better interface to handle
this type of situation. Mark
On Tue, Oct 30, 2012 at 9:09 AM, Eric Lamy <agence.age...@gmail.com> wrote:
> Hi,
> I work on a french project where I have to set a usergroup for each state (département). In France we have 97 states but it seems that there's a limit for Joomla UserGoups and subgroups. In fact if I set my 97 usergroups, I can't record changes in configuration panel, set a plugin, etc..
> Do you confirm that there's a limit for usergroup in Joomla ?
> Thx for answers
> --
> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
> To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/IPx4Lf7jv3kJ.
> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
> To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
What happens ? I can't set Joomla by the backend configuration panel and for some extensions my changes are not recorded, the same settings are displayed after the refresh.
I have a site cloned on another host and I try a lot of things, and one time I try to delete my udergroup. Immediatly Joomla backend works fine.
I saw a post in the forum who was talking about a limit of sub-group (http://forum.joomla.org/viewtopic.php?f=579&t=724084), that's the reason why I ask for that to JM.Simonet who indicate me this workgroup.
Eric
Le mardi 30 octobre 2012 17:56:56 UTC+1, Mark Dexter a écrit :
> What exactly happens? The problem is likely in the user interface, not
> in the actual processing. We need to have a better interface to handle
> this type of situation. Mark
> On Tue, Oct 30, 2012 at 9:09 AM, Eric Lamy <agence.age...@gmail.com> wrote:
> > Hi,
> > I work on a french project where I have to set a usergroup for each state (département). In France we have 97 states but it seems that there's a limit for Joomla UserGoups and subgroups. In fact if I set my 97 usergroups, I can't record changes in configuration panel, set a plugin, etc..
> > Do you confirm that there's a limit for usergroup in Joomla ?
> > Thx for answers
> > --
> > You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
From that error it looks like a JavaScript validator is taking too long and the browser is killing the script with a timeout problem. Strange that it should occur on pages without a group picker sort of control.
--
Sam Moffatt
http://pasamio.id.au Note: I'm not at my desk, responses may be delayed
On 30/10/2012, at 12:56 PM, Eric Lamy <agence.age...@gmail.com> wrote:
> What happens ? I can't set Joomla by the backend configuration panel and for some extensions my changes are not recorded, the same settings are displayed after the refresh.
> I have a site cloned on another host and I try a lot of things, and one time I try to delete my udergroup. Immediatly Joomla backend works fine.
> I saw a post in the forum who was talking about a limit of sub-group (http://forum.joomla.org/viewtopic.php?f=579&t=724084), that's the reason why I ask for that to JM.Simonet who indicate me this workgroup.
> Eric
> Le mardi 30 octobre 2012 17:56:56 UTC+1, Mark Dexter a écrit :
>> What exactly happens? The problem is likely in the user interface, not
>> in the actual processing. We need to have a better interface to handle
>> this type of situation. Mark
>> On Tue, Oct 30, 2012 at 9:09 AM, Eric Lamy <agence.age...@gmail.com> wrote:
>>> Hi,
>>> I work on a french project where I have to set a usergroup for each state (département). In France we have 97 states but it seems that there's a limit for Joomla UserGoups and subgroups. In fact if I set my 97 usergroups, I can't record changes in configuration panel, set a plugin, etc..
>>> Do you confirm that there's a limit for usergroup in Joomla ?
>>> Thx for answers
>>> --
>>> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
> -- > You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
> To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/BbDREA0Y0fcJ.
> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
> To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
I have done some test on this project to find a solution, or at least something to solve this problem.
I have 138 group and sub-group. If I delete groups I can change settings ont the configuration if group number is less than 73. After that it works normaly.
Eric
Le mardi 30 octobre 2012 20:56:31 UTC+1, Samuel Moffatt a écrit :
> From that error it looks like a JavaScript validator is taking too long > and the browser is killing the script with a timeout problem. Strange that > it should occur on pages without a group picker sort of control.
> -- > Sam Moffatt > http://pasamio.id.au > Note: I'm not at my desk, responses may be delayed
> On 30/10/2012, at 12:56 PM, Eric Lamy <agence...@gmail.com <javascript:>> > wrote:
> > What happens ? I can't set Joomla by the backend configuration panel and > for some extensions my changes are not recorded, the same settings are > displayed after the refresh.
> > I have a site cloned on another host and I try a lot of things, and one > time I try to delete my udergroup. Immediatly Joomla backend works fine. > > I saw a post in the forum who was talking about a limit of sub-group (
> http://forum.joomla.org/viewtopic.php?f=579&t=724084), that's the reason > why I ask for that to JM.Simonet who indicate me this workgroup.
> > Eric
> > Le mardi 30 octobre 2012 17:56:56 UTC+1, Mark Dexter a écrit : > >> What exactly happens? The problem is likely in the user interface, not
> >> in the actual processing. We need to have a better interface to handle
> >> this type of situation. Mark
> >> On Tue, Oct 30, 2012 at 9:09 AM, Eric Lamy <agence...@gmail.com<javascript:>> > wrote:
> >>> Hi,
> >>> I work on a french project where I have to set a usergroup for each > state (département). In France we have 97 states but it seems that there's > a limit for Joomla UserGoups and subgroups. In fact if I set my 97 > usergroups, I can't record changes in configuration panel, set a plugin, > etc..
> >>> Do you confirm that there's a limit for usergroup in Joomla ?
> >>> Thx for answers
> >>> --
> >>> You received this message because you are subscribed to the Google > Groups "Joomla! CMS Development" group.
> > -- > > You received this message because you are subscribed to the Google > Groups "Joomla! CMS Development" group. > > To view this discussion on the web, visit > https://groups.google.com/d/msg/joomla-dev-cms/-/BbDREA0Y0fcJ. > > To post to this group, send an email to joomla-...@googlegroups.com<javascript:>.
In #__assets table the rules are stored in a rules-field of varchar(5120). Maybe that is limiting you. You can try by augmenting that number (can be up to 65535).
If I try to reason the 73 groups limit from the 5120 field length limit: when looking at the root asset, there are 9 actions in there by default, which takes up a minimum of about 200 characters. The first 9 groups that are added to those 9 actions take about 6 characters each, so that would be 9 * 9 * 6 characters. Leaving 4434 characters for the rest of the groups. Each group that is added further (with 2 characters for the groupnumbers 10 +) takes about 7 characters. If they are filled in for all 9 actions you could add another 70 groups (4434/63). Then I would end with 79 groups in total before the filed is full. I probably have done some miscounting or something, but it could be that the 5120 field length limit is a cause of the trouble. I didn't test it though and it could have an entire other cause. Just an idea.
It could be a js problem from the validator not responding, or it could be the assets table limiting the number of groups. Or it could be that your server is limiting the amount of POST data it is able to receive.
I recently experienced the third possibility on a client site, where they were submitting a form with so much data, that after they clicked submit, it would just refresh the page - no action was taken. This page refresh took about 3-5 seconds. If your page is locked up and not responding, this is probably not the issue. However, if it is immediately refreshing, but not saving the rules, then it's a possibility.
On Tuesday, October 30, 2012 11:09:21 AM UTC-5, Eric Lamy wrote:
> Hi,
> I work on a french project where I have to set a usergroup for each state > (département). In France we have 97 states but it seems that there's a > limit for Joomla UserGoups and subgroups. In fact if I set my 97 > usergroups, I can't record changes in configuration panel, set a plugin, > etc..
> Do you confirm that there's a limit for usergroup in Joomla ? > Thx for answers
I set the rules to 65535 (mediumtext) and yes I can add another group but no I can't set the configuration by the panel, after the clic on record I have to wait five or six minutes and the refresh give me the last configuration, without any change.
Le mercredi 31 octobre 2012 13:01:23 UTC+1, Herman Peeren a écrit :
> In #__assets table the rules are stored in a rules-field of varchar(5120). > Maybe that is limiting you. You can try by augmenting that number (can be > up to 65535).
> If I try to reason the 73 groups limit from the 5120 field length limit: > when looking at the root asset, there are 9 actions in there by default, > which takes up a minimum of about 200 characters. The first 9 groups that > are added to those 9 actions take about 6 characters each, so that would be > 9 * 9 * 6 characters. Leaving 4434 characters for the rest of the groups. > Each group that is added further (with 2 characters for the groupnumbers 10 > +) takes about 7 characters. If they are filled in for all 9 actions you > could add another 70 groups (4434/63). Then I would end with 79 groups in > total before the filed is full. I probably have done some miscounting or > something, but it could be that the 5120 field length limit is a cause of > the trouble. I didn't test it though and it could have an entire other > cause. Just an idea.
It sounds like a potential issue than like I was describing. Try increasing max_post_size in your php.ini to the max you can (512M) and see if that helps anything.
On Wednesday, October 31, 2012 11:13:53 AM UTC-5, Eric Lamy wrote:
> I set the rules to 65535 (mediumtext) and yes I can add another group but > no I can't set the configuration by the panel, after the clic on record I > have to wait five or six minutes and the refresh give me the last > configuration, without any change.
> Le mercredi 31 octobre 2012 13:01:23 UTC+1, Herman Peeren a écrit :
>> In #__assets table the rules are stored in a rules-field of >> varchar(5120). Maybe that is limiting you. You can try by augmenting that >> number (can be up to 65535).
>> If I try to reason the 73 groups limit from the 5120 field length limit: >> when looking at the root asset, there are 9 actions in there by default, >> which takes up a minimum of about 200 characters. The first 9 groups that >> are added to those 9 actions take about 6 characters each, so that would be >> 9 * 9 * 6 characters. Leaving 4434 characters for the rest of the groups. >> Each group that is added further (with 2 characters for the groupnumbers 10 >> +) takes about 7 characters. If they are filled in for all 9 actions you >> could add another 70 groups (4434/63). Then I would end with 79 groups in >> total before the filed is full. I probably have done some miscounting or >> something, but it could be that the 5120 field length limit is a cause of >> the trouble. I didn't test it though and it could have an entire other >> cause. Just an idea.
Le mercredi 31 octobre 2012 17:42:29 UTC+1, Donald Gilbert a écrit :
> It sounds like a potential issue than like I was describing. Try > increasing max_post_size in your php.ini to the max you can (512M) and see > if that helps anything.
> On Wednesday, October 31, 2012 11:13:53 AM UTC-5, Eric Lamy wrote:
>> I set the rules to 65535 (mediumtext) and yes I can add another group but >> no I can't set the configuration by the panel, after the clic on record I >> have to wait five or six minutes and the refresh give me the last >> configuration, without any change.
*Oups sorry, I mean five or six seconds of course*
>> Le mercredi 31 octobre 2012 13:01:23 UTC+1, Herman Peeren a écrit :
>>> In #__assets table the rules are stored in a rules-field of >>> varchar(5120). Maybe that is limiting you. You can try by augmenting that >>> number (can be up to 65535).
>>> If I try to reason the 73 groups limit from the 5120 field length >>> limit: when looking at the root asset, there are 9 actions in there by >>> default, which takes up a minimum of about 200 characters. The first 9 >>> groups that are added to those 9 actions take about 6 characters each, so >>> that would be 9 * 9 * 6 characters. Leaving 4434 characters for the rest of >>> the groups. Each group that is added further (with 2 characters for the >>> groupnumbers 10 +) takes about 7 characters. If they are filled in for all >>> 9 actions you could add another 70 groups (4434/63). Then I would end with >>> 79 groups in total before the filed is full. I probably have done some >>> miscounting or something, but it could be that the 5120 field length limit >>> is a cause of the trouble. I didn't test it though and it could have an >>> entire other cause. Just an idea.
someone can publish db with this problem (obscure data before publish)?
this will help us to investigate this issue.
On 1 בנוב 2012 03:58, "Eric Lamy" <agence.age...@gmail.com> wrote:
> Le mercredi 31 octobre 2012 17:42:29 UTC+1, Donald Gilbert a écrit :
>> It sounds like a potential issue than like I was describing. Try
>> increasing max_post_size in your php.ini to the max you can (512M) and see
>> if that helps anything.
>> On Wednesday, October 31, 2012 11:13:53 AM UTC-5, Eric Lamy wrote:
>>> I set the rules to 65535 (mediumtext) and yes I can add another group
>>> but no I can't set the configuration by the panel, after the clic on record
>>> I have to wait five or six minutes and the refresh give me the last
>>> configuration, without any change.
> *Oups sorry, I mean five or six seconds of course*
>>> Le mercredi 31 octobre 2012 13:01:23 UTC+1, Herman Peeren a écrit :
>>>> In #__assets table the rules are stored in a rules-field of
>>>> varchar(5120). Maybe that is limiting you. You can try by augmenting that
>>>> number (can be up to 65535).
>>>> If I try to reason the 73 groups limit from the 5120 field length
>>>> limit: when looking at the root asset, there are 9 actions in there by
>>>> default, which takes up a minimum of about 200 characters. The first 9
>>>> groups that are added to those 9 actions take about 6 characters each, so
>>>> that would be 9 * 9 * 6 characters. Leaving 4434 characters for the rest of
>>>> the groups. Each group that is added further (with 2 characters for the
>>>> groupnumbers 10 +) takes about 7 characters. If they are filled in for all
>>>> 9 actions you could add another 70 groups (4434/63). Then I would end with
>>>> 79 groups in total before the filed is full. I probably have done some
>>>> miscounting or something, but it could be that the 5120 field length limit
>>>> is a cause of the trouble. I didn't test it though and it could have an
>>>> entire other cause. Just an idea.
>>>> Herman
>>> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-cms/-/Gb3CnRQQjKgJ.
> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-cms+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
It would be great to get a sample groups table having this issue. I have heard of sites with hundreds of groups but they may not be using this particular UI. Also, do you get the same issue when configuring a component?
Global configuration uses user groups in two places, permissions and filters. It would be good to figure out for certain that it is the permissions on which is causing the problem.
Elin
It could be a js problem from the validator not responding, or it could be
> the assets table limiting the number of groups. Or it could be that your
> server is limiting the amount of POST data it is able to receive.
> I recently experienced the third possibility on a client site, where they > were submitting a form with so much data, that after they clicked submit, > it would just refresh the page - no action was taken. This page refresh > took about 3-5 seconds. If your page is locked up and not responding, this > is probably not the issue. However, if it is immediately refreshing, but > not saving the rules, then it's a possibility.
> On Tuesday, October 30, 2012 11:09:21 AM UTC-5, Eric Lamy wrote:
>> Hi,
>> I work on a french project where I have to set a usergroup for each state >> (département). In France we have 97 states but it seems that there's a >> limit for Joomla UserGoups and subgroups. In fact if I set my 97 >> usergroups, I can't record changes in configuration panel, set a plugin, >> etc..
>> Do you confirm that there's a limit for usergroup in Joomla ? >> Thx for answers
I put in attanched files the usergroup table, hope it helps to understand and to test. And yes I have this issue when I try to configure JDBexport or Ohanah.
Eric
Le jeudi 1 novembre 2012 16:36:42 UTC+1, elin a écrit :
> It would be great to get a sample groups table having this issue. I have > heard of sites with hundreds of groups but they may not be using this > particular UI. Also, do you get the same issue when configuring a > component?
> Global configuration uses user groups in two places, permissions and > filters. It would be good to figure out for certain that it is the > permissions on which is causing the problem.
> Elin
> It could be a js problem from the validator not responding, or it could be >> the assets table limiting the number of groups. Or it could be that your
>> server is limiting the amount of POST data it is able to receive.
>> I recently experienced the third possibility on a client site, where they >> were submitting a form with so much data, that after they clicked submit, >> it would just refresh the page - no action was taken. This page refresh >> took about 3-5 seconds. If your page is locked up and not responding, this >> is probably not the issue. However, if it is immediately refreshing, but >> not saving the rules, then it's a possibility.
>> On Tuesday, October 30, 2012 11:09:21 AM UTC-5, Eric Lamy wrote:
>>> Hi,
>>> I work on a french project where I have to set a usergroup for each >>> state (département). In France we have 97 states but it seems that there's >>> a limit for Joomla UserGoups and subgroups. In fact if I set my 97 >>> usergroups, I can't record changes in configuration panel, set a plugin, >>> etc..
>>> Do you confirm that there's a limit for usergroup in Joomla ? >>> Thx for answers
> someone can publish db with this problem (obscure data before publish)? > this will help us to investigate this issue.
> On 1 בנוב 2012 03:58, "Eric Lamy" <agence...@gmail.com <javascript:>> > wrote:
>> I try with 512 but it changes nothing
>> Le mercredi 31 octobre 2012 17:42:29 UTC+1, Donald Gilbert a écrit :
>>> It sounds like a potential issue than like I was describing. Try >>> increasing max_post_size in your php.ini to the max you can (512M) and see >>> if that helps anything.
>>> On Wednesday, October 31, 2012 11:13:53 AM UTC-5, Eric Lamy wrote:
>>>> I set the rules to 65535 (mediumtext) and yes I can add another group >>>> but no I can't set the configuration by the panel, after the clic on record >>>> I have to wait five or six minutes and the refresh give me the last >>>> configuration, without any change.
>> *Oups sorry, I mean five or six seconds of course*
>>>> Le mercredi 31 octobre 2012 13:01:23 UTC+1, Herman Peeren a écrit :
>>>>> In #__assets table the rules are stored in a rules-field of >>>>> varchar(5120). Maybe that is limiting you. You can try by augmenting that >>>>> number (can be up to 65535).
>>>>> If I try to reason the 73 groups limit from the 5120 field length >>>>> limit: when looking at the root asset, there are 9 actions in there by >>>>> default, which takes up a minimum of about 200 characters. The first 9 >>>>> groups that are added to those 9 actions take about 6 characters each, so >>>>> that would be 9 * 9 * 6 characters. Leaving 4434 characters for the rest of >>>>> the groups. Each group that is added further (with 2 characters for the >>>>> groupnumbers 10 +) takes about 7 characters. If they are filled in for all >>>>> 9 actions you could add another 70 groups (4434/63). Then I would end with >>>>> 79 groups in total before the filed is full. I probably have done some >>>>> miscounting or something, but it could be that the 5120 field length limit >>>>> is a cause of the trouble. I didn't test it though and it could have an >>>>> entire other cause. Just an idea.
>>>>> Herman
>>>> -- >> You received this message because you are subscribed to the Google Groups >> "Joomla! CMS Development" group.
>> To view this discussion on the web, visit >> https://groups.google.com/d/msg/joomla-dev-cms/-/Gb3CnRQQjKgJ.
>> To post to this group, send an email to joomla-...@googlegroups.com<javascript:>
>> .
>> To unsubscribe from this group, send email to >> joomla-dev-cm...@googlegroups.com <javascript:>.
>> For more options, visit this group at >> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
Well i'm back on this subject because I can't find an issue to my problem. Is there a possibility that asset table is wrong and block super admin rules ? I suppose, I don't know if it's possible or not... In fact I can't believe that I'm the first one who try to set more than 73 group and sub-group with Joomla.
Le jeudi 1 novembre 2012 21:27:53 UTC+1, Eric Lamy a écrit :
> Le jeudi 1 novembre 2012 15:17:27 UTC+1, oc666 a écrit :
>> someone can publish db with this problem (obscure data before publish)? >> this will help us to investigate this issue.
>> On 1 בנוב 2012 03:58, "Eric Lamy" <agence...@gmail.com> wrote:
>>> I try with 512 but it changes nothing
>>> Le mercredi 31 octobre 2012 17:42:29 UTC+1, Donald Gilbert a écrit :
>>>> It sounds like a potential issue than like I was describing. Try >>>> increasing max_post_size in your php.ini to the max you can (512M) and see >>>> if that helps anything.
>>>> On Wednesday, October 31, 2012 11:13:53 AM UTC-5, Eric Lamy wrote:
>>>>> I set the rules to 65535 (mediumtext) and yes I can add another group >>>>> but no I can't set the configuration by the panel, after the clic on record >>>>> I have to wait five or six minutes and the refresh give me the last >>>>> configuration, without any change.
>>> *Oups sorry, I mean five or six seconds of course*
>>>>> Le mercredi 31 octobre 2012 13:01:23 UTC+1, Herman Peeren a écrit :
>>>>>> In #__assets table the rules are stored in a rules-field of >>>>>> varchar(5120). Maybe that is limiting you. You can try by augmenting that >>>>>> number (can be up to 65535).
>>>>>> If I try to reason the 73 groups limit from the 5120 field length >>>>>> limit: when looking at the root asset, there are 9 actions in there by >>>>>> default, which takes up a minimum of about 200 characters. The first 9 >>>>>> groups that are added to those 9 actions take about 6 characters each, so >>>>>> that would be 9 * 9 * 6 characters. Leaving 4434 characters for the rest of >>>>>> the groups. Each group that is added further (with 2 characters for the >>>>>> groupnumbers 10 +) takes about 7 characters. If they are filled in for all >>>>>> 9 actions you could add another 70 groups (4434/63). Then I would end with >>>>>> 79 groups in total before the filed is full. I probably have done some >>>>>> miscounting or something, but it could be that the 5120 field length limit >>>>>> is a cause of the trouble. I didn't test it though and it could have an >>>>>> entire other cause. Just an idea.
>>>>>> Herman
>>>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Joomla! CMS Development" group.
>>> To view this discussion on the web, visit >>> https://groups.google.com/d/msg/joomla-dev-cms/-/Gb3CnRQQjKgJ.
>>> To post to this group, send an email to joomla-...@googlegroups.com.
>>> To unsubscribe from this group, send email to >>> joomla-dev-cm...@googlegroups.com.
>>> For more options, visit this group at >>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
On Thursday, November 1, 2012 4:27:10 PM UTC-4, Eric Lamy wrote:
> I put in attanched files the usergroup table, hope it helps to understand > and to test. And yes I have this issue when I try to configure JDBexport or > Ohanah.
> Eric
> Le jeudi 1 novembre 2012 16:36:42 UTC+1, elin a écrit :
>> It would be great to get a sample groups table having this issue. I have >> heard of sites with hundreds of groups but they may not be using this >> particular UI. Also, do you get the same issue when configuring a >> component?
>> Global configuration uses user groups in two places, permissions and >> filters. It would be good to figure out for certain that it is the >> permissions on which is causing the problem.
>> Elin
>> It could be a js problem from the validator not responding, or it could >>> be the assets table limiting the number of groups. Or it could be that your
>>> server is limiting the amount of POST data it is able to receive.
>>> I recently experienced the third possibility on a client site, where >>> they were submitting a form with so much data, that after they clicked >>> submit, it would just refresh the page - no action was taken. This page >>> refresh took about 3-5 seconds. If your page is locked up and not >>> responding, this is probably not the issue. However, if it is immediately >>> refreshing, but not saving the rules, then it's a possibility.
>>> On Tuesday, October 30, 2012 11:09:21 AM UTC-5, Eric Lamy wrote:
>>>> Hi,
>>>> I work on a french project where I have to set a usergroup for each >>>> state (département). In France we have 97 states but it seems that there's >>>> a limit for Joomla UserGoups and subgroups. In fact if I set my 97 >>>> usergroups, I can't record changes in configuration panel, set a plugin, >>>> etc..
>>>> Do you confirm that there's a limit for usergroup in Joomla ? >>>> Thx for answers
I tried to help Eric today. Here are the result of my tests :
- There are two kind of errors,
1 - The first error is linked to the formvalidator of Joomla 2.5. Which is
not able to manage large number of fields (138 groups so lot of
fields....). There is a javascript exception when you try to save the
configuration: The browser runs undefinitely, then it returns a random
error : media/system/js/validate-uncompressed.js:171
It's working great on chrome (very slow) but not working on Firefox at all.
I removed the use of formvalidator in the application.php on com_config,
and the error is out. So it's a workaround not a fix, but this at least can
help.
2- The change are not saved.
In fact, I noticed that the message "configuration saved" was not
displayed, and add a exit() at the beginning of the save function, with no
effect. so I had a brutal var_dump($_POST);exit() in the index.php of
administrator directory, and I can see that the $_POST doesn't contains the
task variable, so the controller cannot be called. Next step was to remove
"permissions tab", in this case, the form is saved ! so the issue is due to
the number of input in the form. So I decided to put at the beginning of
the form <input type="task"....> instead of the bottom, and the form can be
saved, but not all data form are saved.
I checked the PHP documentation, and I saw that for PHP 5.3 there is a
max_input_vars, but the value was set to 1000 , I did a test with 3000 but
still an issue.
Finally on a local server, with the same PHP version, I don't have the
error, the $_POST contains all the data.
> THanks Eric, I am going to play around with this and I hope others will
> too.
> Elin
> On Thursday, November 1, 2012 4:27:10 PM UTC-4, Eric Lamy wrote:
>> I put in attanched files the usergroup table, hope it helps to understand
>> and to test. And yes I have this issue when I try to configure JDBexport or
>> Ohanah.
>> Eric
>> Le jeudi 1 novembre 2012 16:36:42 UTC+1, elin a écrit :
>>> It would be great to get a sample groups table having this issue. I have
>>> heard of sites with hundreds of groups but they may not be using this
>>> particular UI. Also, do you get the same issue when configuring a
>>> component?
>>> Global configuration uses user groups in two places, permissions and
>>> filters. It would be good to figure out for certain that it is the
>>> permissions on which is causing the problem.
>>> Elin
>>> It could be a js problem from the validator not responding, or it could
>>>> be the assets table limiting the number of groups. Or it could be that your
>>>> server is limiting the amount of POST data it is able to receive.
>>>> I recently experienced the third possibility on a client site, where
>>>> they were submitting a form with so much data, that after they clicked
>>>> submit, it would just refresh the page - no action was taken. This page
>>>> refresh took about 3-5 seconds. If your page is locked up and not
>>>> responding, this is probably not the issue. However, if it is immediately
>>>> refreshing, but not saving the rules, then it's a possibility.
>>>> On Tuesday, October 30, 2012 11:09:21 AM UTC-5, Eric Lamy wrote:
>>>>> Hi,
>>>>> I work on a french project where I have to set a usergroup for each
>>>>> state (département). In France we have 97 states but it seems that there's
>>>>> a limit for Joomla UserGoups and subgroups. In fact if I set my 97
>>>>> usergroups, I can't record changes in configuration panel, set a plugin,
>>>>> etc..
>>>>> Do you confirm that there's a limit for usergroup in Joomla ?
>>>>> Thx for answers
> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-cms+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> I tried to help Eric today. Here are the result of my tests :
> - There are two kind of errors,
> 1 - The first error is linked to the formvalidator of Joomla 2.5. Which is
> not able to manage large number of fields (138 groups so lot of
> fields....). There is a javascript exception when you try to save the
> configuration: The browser runs undefinitely, then it returns a random
> error : media/system/js/validate-uncompressed.js:171
> It's working great on chrome (very slow) but not working on Firefox at
> all. I removed the use of formvalidator in the application.php on
> com_config, and the error is out. So it's a workaround not a fix, but this
> at least can help.
> 2- The change are not saved.
> In fact, I noticed that the message "configuration saved" was not
> displayed, and add a exit() at the beginning of the save function, with no
> effect. so I had a brutal var_dump($_POST);exit() in the index.php of
> administrator directory, and I can see that the $_POST doesn't contains the
> task variable, so the controller cannot be called. Next step was to remove
> "permissions tab", in this case, the form is saved ! so the issue is due to
> the number of input in the form. So I decided to put at the beginning of
> the form <input type="task"....> instead of the bottom, and the form can be
> saved, but not all data form are saved.
> I checked the PHP documentation, and I saw that for PHP 5.3 there is a
> max_input_vars, but the value was set to 1000 , I did a test with 3000 but
> still an issue.
> Finally on a local server, with the same PHP version, I don't have the
> error, the $_POST contains all the data.
>> THanks Eric, I am going to play around with this and I hope others will
>> too.
>> Elin
>> On Thursday, November 1, 2012 4:27:10 PM UTC-4, Eric Lamy wrote:
>>> I put in attanched files the usergroup table, hope it helps to
>>> understand and to test. And yes I have this issue when I try to configure
>>> JDBexport or Ohanah.
>>> Eric
>>> Le jeudi 1 novembre 2012 16:36:42 UTC+1, elin a écrit :
>>>> It would be great to get a sample groups table having this issue. I
>>>> have heard of sites with hundreds of groups but they may not be using this
>>>> particular UI. Also, do you get the same issue when configuring a
>>>> component?
>>>> Global configuration uses user groups in two places, permissions and
>>>> filters. It would be good to figure out for certain that it is the
>>>> permissions on which is causing the problem.
>>>> Elin
>>>> It could be a js problem from the validator not responding, or it could
>>>>> be the assets table limiting the number of groups. Or it could be that your
>>>>> server is limiting the amount of POST data it is able to receive.
>>>>> I recently experienced the third possibility on a client site, where
>>>>> they were submitting a form with so much data, that after they clicked
>>>>> submit, it would just refresh the page - no action was taken. This page
>>>>> refresh took about 3-5 seconds. If your page is locked up and not
>>>>> responding, this is probably not the issue. However, if it is immediately
>>>>> refreshing, but not saving the rules, then it's a possibility.
>>>>> On Tuesday, October 30, 2012 11:09:21 AM UTC-5, Eric Lamy wrote:
>>>>>> Hi,
>>>>>> I work on a french project where I have to set a usergroup for each
>>>>>> state (département). In France we have 97 states but it seems that there's
>>>>>> a limit for Joomla UserGoups and subgroups. In fact if I set my 97
>>>>>> usergroups, I can't record changes in configuration panel, set a plugin,
>>>>>> etc..
>>>>>> Do you confirm that there's a limit for usergroup in Joomla ?
>>>>>> Thx for answers
>> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
>> To unsubscribe from this group, send email to
>> joomla-dev-cms+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
