Share This Article
XenForo has a lot of features for both users, and the administrators of the forums. With that comes the necessity to be able to manage what features users have access to, which necessitates a robust permissions system. XenForo has a lot of core permissions features that provide a great deal of control and flexibility for how your users make use of the forums, but with a complex permissions system comes complex problems. Let’s start by talking about the granularity issue in XenForo’s permissions.
XenForo’s inconsistency in permissions: Granularity
Granularity in permissions is usually a good thing; By being able to drill down access to content and features narrowly you can craft a unique experience for your userbase depending on needs, strategy, and more. Additionally, this granularity comes with a (mostly) simple permission control: Yes, No, and Never. Just to summarize that quickly:
- Yes means the user will have access.
- No means they won’t, unless they have a “Yes” granted via another permission.
- Never means just that: No matter where and how many ways you assign a “Yes” to a user, if the permission has a “Never” assigned for that same user then they will not have access to that feature/content.
You’ll notice that we said “No matter where and how many ways you assign”; XenForo’s permissions system provides many ways to grant permissions. You can grant them via user groups, via individual user permission settings, node permissions, and potentially more depending on the add-ons in use. What complicates this further is that – in some cases – you’ll just want to assign a set of common permissions for a specific class of actions (such as viewing, posting, and replying to forum posts); These are somewhat grouped together in logical ways, and the permissions system lets you do a batch “Yes/No/Never” to all within those groups fairly easily, except for one caveat: Some of those permissions are ones you may not want to assign to the user.
A common one seen is “General Permissions”; a lot of these are very common permissions all users may want in a standard forum.. Except for a handful of them, of course. Ones like “Require two-step verification” can confuse users who aren’t used to using 2FA (although it generally is a good security practice to enable). Moving along, a subsequent issue that comes along with this granularity is the question of inheritance.
XenForo’s permission inheritance problem
The Yes/No/Never permission makes a lot of sense, and does simplify understanding when a user should have access to something. Where things get complicated – and occasionally buggy – is inheritance, and tracking it down. XenForo provides a tool for analyzing permissions, cleverly called.. “Analyze permissions.”
That’s about where the simplicity ends.
When you use this tool to analyze the permissions of a specific user, you’re probably trying to figure out one of two things: Why they have access to something they shouldn’t or why they can’t access something they should be able to. At face value, this is a very useful tool. You look up a user and other criteria depending on what permissions you’re attempting to analyze, and then get a nice set of results for all possible permissions. These results start out with the “top level” view, showing specifically what their “end result” permissions are. If you click “Details” next to the permission, you’ll see a breakdown of the various ways permissions may be set for that user leading to the ultimate “end result” permission.
The problem here is that it can also be incorrect; Sometimes XenForo’s permissions can be buggy, necessitating using another tool: The Permissions rebuild. XenForo provides a number of rebuild functions that can be used to literally “rebuild” data based on the various criteria stored in the database.
And then you come to the complications related to being able to set contradictory permissions. As an example, someone can have the ability to technically reply to a thread via a “Yes” permission, but if they don’t have permission to view that thread, that permission becomes moot, and can lead to confusion for first-time forum admins and users alike. Users may not always be able to communicate their goals and steps clearly, leading to general confusion as to where the hiccup is along the path of permissions. There are no “Permission X relies on Permission Y” sort of descriptors here, which then leads us into understanding permission assignment context.
XenForo’s groups vs. roles and permissions
We’ve talked briefly about groups and how they relate to permissions, but now we get to complicate things further by discussing roles. If you assumed adding a user to the “Moderator” or “Admin” group would give them the full access a moderator or admin respectively would have, you’d be wrong. While there are permissions that are typically only assigned to those in the moderator or admin groups, to have access to the full features tied to those, you have to look at the staff section of XenForo’s groups & permissions.
The groups for moderators and admins apply more to the general permissions used in accessing the front-end portion of the forum. Things like being able to edit posts by other members, bypassing limits on replies, and more are all controlled via the regular permissions system we’ve been talking about.
However, accessing things like the moderators or the admin control panel require utilizing an entirely different permissions system for staff. A user can be added to either Administrator or Moderator staff (or both, in fact), but that’s not all. You also have what’s called “Super administrators” and “Super moderators”.
Regular administrators only have access to the admin features you explicitly grant them access to. Regular moderators typically only have moderator capabilities on the forum they are assigned to. In order to have full access to everything with either the moderator or administrator roles, you need to make them “Super” moderators/administrators.
This can cause a lot of confusion overall, especially in the context of administrators and permissions; You can’t make someone an administrator, for example, and grant them access to everything and expect them to have the same access as a super administrator; these are distinct roles separated from each other.
Someone can be made a super administrator, but also have permissions revoked to access specific forums or features on the platform. Of course, they can always edit their own permissions to give themselves access, but it’s a bit absurd that it would even be necessary to do so (this happens more often than you might realize, especially when you look at 3rd party addons and permissions, which we’ll discuss later).
XenForo’s lack of guardrails on permissions, groups, and more
You can do many strange things with XenForo’s permissions system, and some of those oddities really make very little sense in that you’re allowed to do it without any sort of warning that it could be a bad idea. A common mistake that some folks make is to set the users’ primary group to something other than registered. For example, they may want to make their moderators have their primary user group be moderators, thinking that a moderator would have all the permissions for a registered user by default, but this would be incorrect.
By setting the primary user group for a user to anything other than “Registered”, they will no longer inherit the default registered user permissions (unless they are assigned as “Registered” as a secondary user group). This means they could technically be able to do things like bypass edit limits on posts, but they would be unable to actually create new posts or do things a regular user could do over an unregistered user.
The fact that you’re allowed to do this without any sort of warning can be a little headache-inducing. Many community leaders assume they then need to explicitly grant permissions to all the user groups, which then makes things even more complicated, and can cause problems down the road with user permission management, inheritance, and understanding where the breaks in permissions are happening. And that’s all before we get to the final issue with XF’s permissions systems: 3rd party add-ons.
XenForo’s permissions and 3rd party addons
Add-ons can utilize both existing permissions structures, as well as their own. Most add-on developers will make use of existing permissions themselves where applicable, and will extend the permissions system itself to include new permissions as-needed. The fact that the permissions system can be extended like this is great; It makes it easier to manage new functionality for users without too much added complication. Of course, not all add-on developers will do this: Some may bypass the core permissions system and instead utilize something like an Options menu to manage access. This can be for legitimate reasons – such as a lack of necessary controls in the permissions system – or just because they believe it would make more sense to implement the access via settings rather than permissions.
It gets even more complicated when you discover that some add-ons will install with a default of “No” on all permissions. This makes sense in some cases; if you’ve got an add-on that adds an entirely new section to the forums, restricting access before it’s fully configured is a reasonable precaution.
This does, however, create confusion with admins wondering why the new addon they just installed says they don’t have permissions to view the new content it just added.. And then you come full-circle back to the granularity issue, where an addon may add a large number of permissions settings without grouping them in a context that would make using the “Set All” a safe option.
Is XenForo’s permissions system too complex?
In some ways, you may feel like the granularity presented in XenForo’s permissions system ends up creating a complex mess that is hard to manage. It certainly does get challenging the deeper you dive into it, but if you’re lucky enough to have a fairly basic XenForo configuration without a lot of extra bells & whistles, a light touch on permissions management is recommended. The less you mess with, the fewer problems you will have.
Once you begin to consider things like adding staff, managing access for premium features, attempting to reduce spam by limiting new user accounts’ ability to interact without moderator approval, and adding 3rd party addons?
All bets are off, and you need to be prepared for some frustration. Thankfully, issues tend to be minimal once resolved (assuming you resolved them the right way, of course).
