• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
  • This forum has been archived. New threads and replies may not be made. All add-ons/resources that are active should be migrated to the Resource Manager. See this thread for more information.

Understanding Permissions

Jake Bunce

XenForo moderator
Staff member
#1
Types of Permissions

Not Set (No)
Not explicitly set. Effectively a No if there is no Allow in other applicable permission sets. In the Node Permissions this is Inherit which means that permission is inherited from the higher level User Group Permissions and User Permissions.

Allow
This is like a Yes. The permission is granted.

Revoke
This is only used in the Node Permissions. A Revoke can be overridden by an explicit Allow but not an inherited Allow. Revoke is designed to reduce a user's Node Permissions in the absence of an explicit Allow. More on this later.

Never
This is an overriding No. The user won't have this permission even if there is an Allow elsewhere.

Permission Sets

There are different permission sets which come together to determine a user's overall permissions. These are the levels of permissions:

Admin CP -> Users

> User Group Permissions
> User Permissions
> Node Permissions


The User Group Permissions define the base permissions. Then the User Permissions are an optional set of permissions that can be defined for individual users. These two sets merge together to form the base permissions for a user.

Then you have the Node Permissions. These permissions are inherited from the previous two sets. In addition, node permissions of a parent node are inherited by child nodes. You can set node permissions per group and per user, and these two sets of permissions merge together to determine a user's final permissions per node.

Permission Math

Here is some permission math for the combinations that might not be obvious:

Not Set (No) + Not Set (No) = Overall No

Not Set (No) + Allow = Overall Yes

Not Set (No) + Never = Overall No

Inherited Allow + Revoke = Overall No

Allow + Revoke = Overall Yes

Allow + Never = Overall No

Pay special attention to the Revoke ones:

Inherited Allow + Revoke = Overall No

Allow + Revoke = Overall Yes

Only an explicit Allow (as opposed to an inherited Allow) can override a Revoke. A Revoke is designed to trump inherited access and reduce a user's permissions unless you explicitly Allow (no inheritance) that permission elsewhere in the Node Permissions (e.g. for one of the user's other groups).

Use Cases

Here are some notable use cases. I may add more later.

Creating a private forum

Because of the way Revoke works in xenForo you shouldn't use it to restrict a private forum. Instead you should use a special feature in xenForo called Private node. You will see the Private node checkbox when editing the permissions for a specific node. This basically inverts the permissions so that you can specify Allowed groups instead of Revoked groups. This is actually better for group management if you add more groups later.

Admin CP -> Users -> Node Permissions -> [select a forum] -> Private node
 

Simon

Active member
#3
Thanks for this, I found it very helpful.

Making a private forum for a usergroup:
The only thing I found confusing at first was after selecting the Private Node for a certain forum, you have to click on the actual usergroup name to change permissions for that node. Not the group Info link. (to the right under each usergroup)

Hope this Helps.
 

projectego

Active member
#6
A very useful guide. I will review this further when I find enough time to sit down and actually mess around with some of the options in the admin CP.
 

Dean

Well-known member
#12
Jake, and others, my testing was a bit.... 'confusing' until someone pointed out an issue with firefox.

With 2 windows open, making changes in window 1, and doing a refresh in window 2 to watch for the expected results in another area of the adminCP. That showed some bizarre and unexpected results. I recommend a hard re-fresh in windows to see reliable results (Control F5). That made everything work correctly.

In summary: If things don't make sense, try a control F5 to see if that helps.
 

Dean

Well-known member
#14
I think that is a missing feature then, otherwise its not going to be possible to maintain private forums where thread content is also private, ie. between a user and a mod / admin.
If you mean having a forum where an admin (or other specific group) can see all threads, and normal people can see only the threads they had started - but not threads other people have started - that is not possible.
 

Anthony Parsons

Well-known member
#15
If you mean having a forum where an admin (or other specific group) can see all threads, and normal people can see only the threads they had started - but not threads other people have started - that is not possible.
Yer... I found that the permissions for it don't exist with xenforo. I do hope they may in the near future to assist at the admin level for overall control of content.
 

Mr_Bob

Well-known member
#16
Yer... I found that the permissions for it don't exist with xenforo. I do hope they may in the near future to assist at the admin level for overall control of content.
The only way they know it is wanted is if it appears in the suggestion forum (or the bug forum, if it's a bug-worthy oversight :D ). That's an important feature for me as well, so if you do happen to suggest I'll like it for you ;).
 

Brogan

XenForo moderator
Staff member
#17
The only way they know it is wanted is if it appears in the suggestion forum (or the bug forum, if it's a bug-worthy oversight :D ). That's an important feature for me as well, so if you do happen to suggest I'll like it for you ;).
I'm fairly sure that has been suggested, I'll see if I can find the thread.
 

Dean

Well-known member
#18
Yer... I found that the permissions for it don't exist with xenforo. I do hope they may in the near future to assist at the admin level for overall control of content.
Actually, a forum setup that way has other issues such as convincing people others cannot see their threads. I refer to it as the 'creepy' factor, and it requires a lot a trust to trade private information that way.

I believe a much better approach are the personal conversations, if the management of them can be improved (being able to see participants, be searchable & have attachments).
 

Brogan

XenForo moderator
Staff member
#19
I've only just started looking at the permissions but if I've got this right....let's take this example.

I have a default Registered user group and have "Upload an avatar" set to "Allow" and the file size set to 10240 (10KB).

I also have a Premium Member user group and have Upload an avatar" set to "Default" and the file size set to 76800 (75KB).

By my reckoning, anyone who is already in the Registered user group who is then added to the Premium Member user group (via an account upgrade) as a Secondary user group, will still retain the ability to upload an avatar due to the inherited "Allow", but the maximum size will be increased to 75KB.

So for any additional (secondary) user groups, everything can remain on "Default" except for the specific permissions which differ from the primary group.

Is that correct?
 

Paul M

Well-known member
#20
Indeed - what is the rule for numeric "permissions" ? Does a larger value always override a smaller one (as this may not always be whats required).