XF 1.5Problem with getting usergroup promotions to work automatically

Well-known member

The issue I'm having is regarding usergroup promotions. We have one for our forum marketplace where the user has to have 50 posts in order to post their own threads.

The promotions work when I direct it manually but fail to auto-assign the promotion when the user has received 50 posts. I know this because I tested it on another profile I use that has several hundred posts.

The usergroup is supposed to transfer from "registered users" to a usergroup I named "registered verified" to hold the real posters and hold back the inactive users who don't post, also to allow them to post in our marketplace.

With that said, 2 of my users did not receive the promotion upon assigning them to the registered users usergroup.

This was discovered when I had assigned a user to "registered verified" instead of promoting them which I believed would work as well. What happened is the user could not edit his/her posts and ended up coming to me for help. Upon this discovery I noticed it was only in the usergroup that had be on the transferring end of the promotion, when putting a user directly in this usergroup, they cannot edit their own post. I double-checked permissions and used test permissions and the option had been enabled.

So the first question is why the promotions aren't auto-assigning which may have a logical explanation.

Though the second issue could be a bug because not being able to edit a post is a bit off the deep end for a usergroup that had been on the transferring end of usergroup promotions.

Well-known member

Firstly, user group promotions don't "transfer" from one user group to another, they add a user group as a secondary user group to that user. All users should have Registered as their primary user group.

User group promotions happen when the user group promotion cron runs, so you may not necessarily see a user added to a secondary user group immediately they meet the criteria.

If the 50 posts criteria is a new one, users who haven't been active for a while won't get the promotion even if they meet the criteria until they are next active on the forums.

As for editing posts, check that you haven't used the Never permission as it cannot be overridden. You should use Not Set(No) instead). When allowing to edit posts, make sure that the time to edit posts isn't set to 0 in the group you are allowing the editing, as 0 will mean they can't edit (as the editing window will be 0 minutes).

Well-known member

Firstly, user group promotions don't "transfer" from one user group to another, they add a user group as a secondary user group to that user. All users should have Registered as their primary user group.

User group promotions happen when the user group promotion cron runs, so you may not necessarily see a user added to a secondary user group immediately they meet the criteria.

If the 50 posts criteria is a new one, users who haven't been active for a while won't get the promotion even if they meet the criteria until they are next active on the forums.

As for editing posts, check that you haven't used the Never permission as it cannot be overridden. You should use Not Set(No) instead). When allowing to edit posts, make sure that the time to edit posts isn't set to 0 in the group you are allowing the editing, as 0 will mean they can't edit (as the editing window will be 0 minutes).

None of the below apply. Next, you solved one issue. Why they didn't receive the usergroup right away.

Does it matter if the usergroup is only secondary? I'm aware that in this case I need to allow my members access to a specific forum. If a registered user cannot access the specific forum but the new usergroup can, what is the outcome? I was made aware how promotions work... I was also told specifically in a Xenforo manual that after being promoted the secondary (in your case), will take the dominant role of usergroup. Either way it said how they work. More importantly that the users can access the "said" forum without any issue once promoted. If this cannot happen then why would it be a secondary? Only that I wish to understand more if that would indeed be the dominant usergroup afterwords.

Thank you @Martok. Surprised at the lack of responses. Usually techs are up on this stuff.

Last note, the edited post issue was most likely a bug. I checked many times, I don't set anything to never and I'm pretty sure my member was right.

It seems that the edit option would not appear for him. The edited time is set to infinite. Everything was normal as checked. Somehow the destination usergroup would not allow for editing when a user was placed in that usergroup separate from the promotion.

In other words, when a promotion was still active, while placing a user in the destination usergroup manually without being promoted, this behavior occurred.

It doesn't say that anywhere. No user group is dominant. XenForo is based on cumulative permissions across all user groups that a user is a member of. The correct practice is to have the Registered user group as the primary user group with the minimum (base) permissions set that all users should have, then to give the additional permissions in the secondary user groups. So for example on my forum, some users are in 5 user groups and their permissions are a sum of all of these. The other golden rule is to avoid using Never as it cannot be overridden. Not Set (No) is generally what should be used instead.

Well-known member

It doesn't say that anywhere. No user group is dominant. XenForo is based on cumulative permissions across all user groups that a user is a member of. The correct practice is to have the Registered user group as the primary user group with the minimum (base) permissions set that all users should have, then to give the additional permissions in the secondary user groups. So for example on my forum, some users are in 5 user groups and their permissions are a sum of all of these. The other golden rule is to avoid using Never as it cannot be overridden. Not Set (No) is generally what should be used instead.