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)
Never – this will not grant the permission. This can never be overridden, so should be used sparingly.
Allow – this will grant the permission.
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)
Never – this does not grant the permission and cannot be overridden.
Allow – this grants the permission.
Revoke – this does not grant the permission, but can be overridden.
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.
