XenForo has a very powerful system for controlling what your users are allowed to do. This is called the permissions system. Permissions can be set at a number of levels, such as for user groups, users, and nodes. Administrator permissions are controlled separately.

Core Concepts

Multiple Group Membership and Permission Set Merging

A user may belong to more than one user group and may have specific permissions applied as well. When we calculate their final permission values, we look at all of these permission sets. The final value is taken from the highest priority value (see below).

Permission Value Priority

Each permission may be set to a different value. If a user is in multiple groups or has specific permissions set, this may cause multiple conflicting values for a permission. For example, a user may have both not set (no) and allow for the view node permission, so what takes priority?

Permission value priority is set in this order: (highest priority first)

  1. Never – this will not grant the permission. This can never be overridden, so should be used sparingly.
  2. Allow – this will grant the permission.
  3. Not Set (No) – this will not grant the permission. This is the lowest priority value; any explicit allow will override this.

Thus, if a user has not set (no) and allow for a permission, the final value will be allow. The Test Permissions system can help confirm that permissions are set correctly.

Note that the permission terminology is slightly different for node permissions.

Additive Permissions with Multiple User Groups

Forums generally have multiple classes of users, such as regular users, moderators, and administrators. Larger forums may have more classes, including premium users and other distinctions. Keeping track of permissions can be very challenging, so it is important to have a standard approach to laying out your permissions.

A key approach in managing complex permissions is to use multiple user groups to build up permissions for users with higher privileges.

Let’s consider the concept of a premium user. This user has all of the abilities of a regular user, but also has access to a few special permissions. This directs us to having these two user groups:

  • Registered – this is a default group; it’s where newly registered users group.
  • Premium – this is a custom group that we’ll create to give the extra permissions.

For this setup to work, we need to ensure that the registered group does not use permission values of never, as it cannot be overridden.

When the premium user group is created, it starts with no permissions (all not set (no)). However, because the user will be in the premium group and the registered group, he or she will inherit all of registered user permissions. Thus, in the premium group, we only need to set the permissions (to allow) that we want to add.

The same concept can be used to give a specific group access to a special forum.

Node Permissions

In addition to specifying permissions for user groups and users, you may specify permissions on specific nodes. Like before, these can be applied to user groups and users.

Node Permission Terminology and Priority

Node permissions follow a similar concept to user group and user permissions, but the terminology is a bit different. The permission value priority is: (highest priority first)

  1. Never – this does not grant the permission and cannot be overridden.
  2. Allow – this grants the permission.
  3. Revoke – this does not grant the permission, but can be overridden.
  4. Inherit – this takes the value from the parent. See below.

A value of never cannot be overridden, even in a child node. Use it sparingly.

The inherit value causes the value for that permission to be inherited from the parent node. If there is no parent node, then the value will come from the user group and user permissions.

Private Nodes

When setting the permissions for a node, you have the option to mark it as private. This means that no one will have access to the forum, unless they are explicitly given the view node permission by setting the value to allow.

For example, to make a forum for admins and moderators, you would mark the forum as private and then allow the view node permission for the administrative and moderating user groups.

Analyzing Permissions

This feature is new in XenForo 1.2.

It can be a challenge to confirm that you have correctly set up a user’s permissions. The Analyze Permission option allows you to see all of a user's permissions globally or in a particular node.

If you are unsure why a particular value has been set, you can click the Details link to expand a list of the permission values that led to that final value. You can use this to identify the offending permission setting. From there, you would go into the correct location (user group, user, or node permissions) and change the permission as needed.

Testing Permissions

An alternative method to confirm that you have correctly set up a user’s permissions is the Test Permissions system. You enter a user’s name and you will be shown the forum as if you applied the user’s permission to yourself.

Please keep in mind the following caveats:

  1. You are still logged in as yourself, not the user you’re testing as. You will not be able to see their conversations, watched threads, etc.
  2. User-specific changes such as banning or discouragement will not affect you.
  3. As the permissions are applied to you, if a permission grants you access to do something only to your own posts (such as editing), you can only edit posts that you made, not posts made by the test user.

To exit permission testing, click the Permissions from Name text at the top of the page and confirm that you want to go back to your permissions.

Admin Permissions

Admin permissions are completely separate from the user group, user, and node permissions. Please see the administrators section for more details.