Re: [jcms] User group limit with Joomla 2.5 ?

[Mark Dexter]

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> 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-...@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.
>

[Eric Lamy]

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

[Sam Moffatt]

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

> To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/BbDREA0Y0fcJ.

[Eric Lamy]

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

[Lapoux Sébastien]

Bonjour Eric,

I thank you a lot :). We have meet the same limit when we tested SEBLOD multisite, in this case for each site some user groups are created.
And we find the limitation to 73 too ;): http://www.seblod.com/support/forum/105-General-Discussions/34926-Multisite-feature---limit-on-subdomains---is-there.html#36561

We have search a lot and clearly more on SEBLOD side, but impossible to find anything false.

Hope that Joomla core team will find the solution.

Best Regards.

[Herman Peeren]

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

[Donald Gilbert]

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. 

[Eric Lamy]

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.

[Donald Gilbert]

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.

[Eric Lamy]

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

[Ofer Cohen]

someone can publish db with this problem (obscure data before publish)?
this will help us to investigate this issue.

--

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.

[elin]

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

[Eric Lamy]

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

[Eric Lamy]

you mean all database or only some tables ?

[Eric Lamy]

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.

[elin]

THanks Eric, I am going to play around with this and I hope others will too.

Elin

[Thomas PAPIN]

Hello,

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.

Hope someone has some other ideas

2012/11/5 elin <elin....@gmail.com>

--

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/-/wW5i5Hof7MQJ.

[Thomas PAPIN]

I found it, The server was installed with susohin patch
So need to add :
suhosin.post.max_vars = 3000
suhosin.request.max_vars = 3000

Now it's working.

Only the javascript point remaining for the joomla configuration page.

2012/11/5 Thomas PAPIN <thomas...@gmail.com>