XF 1.2 Permission Analysis

Permissions in XenForo are very powerful. However, this can also create confusion, especially if you are just getting to grips with the concepts in XenForo's permission system.

The biggest challenge is often determining why a user has (or doesn't have) a permission. XenForo 1.2 adds a permission analysis system to help you determine this.

Using it is very simple:

ss-2013-05-31_13-25-17.webp


First, you can choose whether you just want to look at global (user group and user) or node permissions. Global permissions still factor into node permissions, so I'm just looking at the latter here.

Then you enter the user you want to check the permissions for and--if you're checking node permissions--the node to check. After submitting the form, you'll be given a list of all of the permissions with the final, calculated yes/no/integer values displayed:

ss-2013-05-31_13-33-23.webp


Each of these can then be displayed with the "details" link showing you exactly what is contributing to that.

Looking at the "view node" permission, the final value is yes, but you can see that I revoked viewing for registered users but then re-allowed it for admins. Note that we're actually looking at the permissions for "main forum" here. These changes were on the category, but because the permissions bubble down, they're relevant here.

Conversely, for "post new thread", it's revoked for registered users at the "main forum" level itself, but nothing overrides that so it's still no.

Now I can quickly see what the permissions are for a particular user and, if they're wrong, diagnose it and change them as necessary.
 
Permissions in XenForo are very powerful. However, this can also create confusion, especially if you are just getting to grips with the concepts in XenForo's permission system.

The biggest challenge is often determining why a user has (or doesn't have) a permission. XenForo 1.2 adds a permission analysis system to help you determine this.

Using it is very simple:

View attachment 47208

First, you can choose whether you just want to look at global (user group and user) or node permissions. Global permissions still factor into node permissions, so I'm just looking at the latter here.

Then you enter the user you want to check the permissions for and--if you're checking node permissions--the node to check. After submitting the form, you'll be given a list of all of the permissions with the final, calculated yes/no/integer values displayed:

View attachment 47211

Each of these can then be displayed with the "details" link showing you exactly what is contributing to that.

Looking at the "view node" permission, the final value is yes, but you can see that I revoked viewing for registered users but then re-allowed it for admins. Note that we're actually looking at the permissions for "main forum" here. These changes were on the category, but because the permissions bubble down, they're relevant here.

Conversely, for "post new thread", it's revoked for registered users at the "main forum" level itself, but nothing overrides that so it's still no.

Now I can quickly see what the permissions are for a particular user and, if they're wrong, diagnose it and change them as necessary.
Excellent work. This is awesome.

I don't know if this is the time for suggestions. Permission wise, one use case that I commonly have is: "Make sure nobody can ... "
Sometimes I really want to make sure people cannot physically delete things. My current flow is going through each smod and checking.
 
That should be a single permission check in a single group, if you have them set up correctly.
My main issue is that I have more than 1 admin in the forum.
So, they sometimes setup a supermoderador and give them permission to hard-delete ...

So every few months I manually check that is not the case. Surprisingly it keeps happening again and again.

Um ... I guess I could just Revoke the privilege on the SuperMod group and that's that. Even if granted on the user level Revoke should take precedence.

Thanks, Brogan.
 
Well the group setting would be Not Set (No) and Allow would override that.

Unless you set it to Never, but that would affect everyone in that group.
 
Also it will remove a large workload on here and maybe tickets because ordinary (non-dev) admins can't grasp it and get in muddles needing help.
So this is good for us, good for the mods and supporter sommunity here, and them good in first impressions for prospective buyers. Win Win Win Win.!
 
Permissions in XenForo are very powerful. However, this can also create confusion, especially if you are just getting to grips with the concepts in XenForo's permission system.

So can we now set permissions for the upgrade system?
 
Top Bottom