• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

XF 1.2 Permission Analysis

Mike

XenForo developer
Staff member
#1
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.png


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.png


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.
 

xf_phantom

Well-known member
#3
Are these values the default xf permission values, or is this really calling the models to check permissions? (because only this would be 100% the real permission)
 

Mike

XenForo developer
Staff member
#5
Are these values the default xf permission values, or is this really calling the models to check permissions?
I'm not sure what you're asking... It's checking the actual permissions in use and generally pulling calculation from the necessary handlers.
 

Slavik

XenForo moderator
Staff member
#6
Would be good to see an artifical user so to speak, so eg, can just select 3 usergroups and the node, and see what the result would be without having to create an actual user with those permissions, as a quick alternative to checking how promotions or usergroups interact with each other.
 

Steve F

Well-known member
#13
Awesome stuff! Can't wait :)

As a side note, Mike please let us know when the final HYS is out so I can resume my daily life, this is just to cool seeing all these.. ;)
 

xf_phantom

Well-known member
#14
I'm not sure what you're asking... It's checking the actual permissions in use and generally pulling calculation from the necessary handlers.
I'm talking about the methods in the thread/post/etc models, which are the only real source for the real permissions.
e.g. addon is overwriting the canViewForum method from the forum model based on the gender/location/date/ etc....


the page would show "yes" but the user would still complain that he's not able(because an addon is changing it)

That's why i hoped that this would be a "real" method <=>permission map which would show the REAL results. This is one of the biggest "issues" in the support forums, if people forget that they've installed addon XYZ which is changing the permissions.

It would be fantastic, if the real value would be used and when you click on "detail", it shows additional to the xf informations e.g. "addon XYZ" is changing this based on FOOBAZ (could be an additinal array variable in the perm check methods, where addons could attach a phrase

I hope you know what i mean :/
 

Mike

XenForo developer
Staff member
#20
I'm talking about the methods in the thread/post/etc models, which are the only real source for the real permissions.
No, that's different and we don't have anything that even enumerates those permissions as they don't map 1:1 with actual permission setups. (For example, we'd never check can view thread-like stuff without a thread, and this applies to many other permissions.)

But regardless, that's not really the general target of this.