Implementing permissions across multiple user groups

This and other similar questions keep coming up so here's an example of how to prevent newly registered members from starting conversations and only allowing them to once they have been registered for a week.

1. Set the Start conversations permission for the Registered user group to No
2. Create a new user group - let's call it Established members
3. Set the Start conversations permission for the Established members user group to Yes
4. Create a User group promotion to promote members to the Established members user group using the User has been registered for at least X days criterion and set it to 7

The same approach can be used for other permissions and criteria.

Always remove the permission from the Registered user group and add it to a new user group, and combine it with a promotion.

There is another example and more information in the manual here: https://xenforo.com/xf2-docs/manual/groups-permissions/#an-example-promotion

Another question which comes up often is, "How can I create a news or announcement forum, in which only staff members can create threads and post replies?".

Again, it is achieved via node specific permissions.

1. Revoke the 'Post new thread' permission for the Registered user group.
2. Allow the 'Post new thread' permission for the desired user group(s) or user(s).
3. Revoke the 'Post replies' permission for the Registered user group.
4. Allow the 'Post replies' permission for the desired user group(s) or user(s).

If you wish to allow registered members to post replies to staff created threads, then omit steps 3 and 4.

This question comes up quite often so it's worth adding it here for easy reference.

That question being: "How can I allow one user group access to a forum while preventing all others?"

The typical use would be a staff forum to which only staff members have access.

There are two ways of doing it, via node specific permissions.

1. Select the 'Private node' option.
2. Allow the 'View node' permission for the desired user group(s) or user(s).

or

1. Revoke the 'View node' permission for the Registered and Unregistered user groups.
2. Allow the 'View node' permission for the desired user group(s) or user(s).

Some people are still confused as to why it's best practice to have the Registered user group as the primary and other user groups as the secondary.

Let's look at what happens in two different scenarios on two different forums when installing a new add-on.


Dave has 20 user groups defined.
Members have the Registered user group as the primary and they have been added to the other groups as secondary.

John has 20 user groups defined.
Members have different user groups as the primary and have no secondary group.


Dave and John each install the same add-on in their respective forums.
The add-on has a new basic "view" permission.
Dave and John want to allow all members to view the new add-on.

Dave just has to set the new add-on view permission for the Registered group to Allow.

John has to set the new add-on view permission for all 20 groups to Allow.


What about the converse?
What if Dave and John only want members in the Premium user group to view the new add-on?

Dave just has to set the new add-on view permission for the Premium group to Allow.

John also just has to set the new add-on view permission for the Premium group to Allow.


So either way, setting the permissions up so the Registered group is the primary for all members works in every case.


This of course also works in exactly the same way when a new permission is added to the core software.


If you haven't set your user groups up as per the main resource text, you should consider doing so as it makes life a lot easier in the long run.