Allowed memory size exhausted when deleting usergroup

[whyweprotest]

I am trying to do some usergroups cleanup.. our old vb3 board had gotten a bit crazy with different groups and we need to simplify things now. As part of an older spam-issue, we had an 'elevated' group that we moved users into once things were verified. So this means that this group has a lot of folks in it that I would like to get back to the 'Registered' group within XF.

However, when doing so, I encounter the following error:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32 bytes) in /var/www/forums/library/Zend/Db/Statement/Mysqli.php on line 304

my db-fu is a bit weak admittedly, so I'm not certain if that is a hard coded variable within the Zend framework, or an issue with my my.cnf having some too-low settings. Any advice on how to proceed would be helpful.

Oh, and yeah, the group has 25k people in it.

 

[Jake Bunce]

You can try increasing your memory limit.

Or you can try manually moving the users with a database query:

UPDATE xf_user
SET user_group_id = 2
WHERE user_group_id = 3

Change the group ids appropriately.

 

[whyweprotest]

argh search fail on my part. Thanks Jake!

 

[Mike]

Oh, and yeah, the group has 25k people in it.

That's the main problem currently, as there's a lot to do. There was a bug report about this and it's something I'll try to look into in a future version. Mass user editing tools would also help.

Or you can try manually moving the users with a database query:

UPDATE xf_user
SET user_group_id = 2
WHERE user_group_id = 3

Change the group ids appropriately.

That query will sort of work - the permission_combination_id needs to be updated accordingly, which really isn't feasible to do via a query, at least not for everyone. If you know the old combination ID that corresponds to a particular setup and you have the combination ID that matches that setup with a different primary user group ID, then you could change both the group and the combination ID... though there's also a cache in another table too. So all in all, that's a dangerous approach.