XF 1.4 permissions explained

SEDA Ian

New member
i've read, re-read and read again the help file and i'm left stumped.

i don't get it.

is there a video somewhere that explains node permissions...simply?

if I set explicit category permissions for the different user groups and then set the permissions for all nodes inside that root node to "inherit" does it take on the category permissions unless I choose otherwise?

Why would I use revoke? Is this specifically when you may have users that are in multiple user groups?

my head hurts!
 
Ok so just so that I understand specifically the revoke permission...

If in a category node a group has a revoke permission on starting new topics yet in a forum node has the ability to start a topic, the higher permission takes over yes?
 
Hi everyone...

Ok so I read Brogan's document regarding implementing permissions across multiple user groups, it was most helpful so I spent most of yesterday re-doing all my groups and now it works great and after 3 or so years of actually having XenForo I now understand the permissions system. I was so overcomplicating it for myself by setting explicit permissions for all the nodes, for all the groups...when I could just make one little change instead.

Most helpful thanks!
 
Man, I'm glad I found these. We're really struggling with Xenforo permissions on the test server we set up to migrate from vBulletin. Reading some of these sentences from the help section on permissions, I can't see how the sentences even make sense:

"Adding a user to the Moderating user group does not make them a moderator, it only accords the user title and permissions associated with that user group."
 
Why doesn't it make sense?
User groups are primarily for styling and permissions.
Anyone can have the "delete thread" permission but that doesn't necessarily make them a moderator.

A moderator is a role, which has to be explicitly applied.
 
Hmmm, to me it's counterintuitive, as if the Police Academy said "I placed a new officer on the list of officers, gave her the badge and permissions, but that' doesn't make her an officer."
 
Giving someone permission to do something doesn't make them, in your analogy, an officer. I can make an arrest but it doesn't make be a police officer (it's a citizen's arrest).

The forum permissions are one thing and can be given to anyone. Adding someone as a Moderator in the ACP gives them access to the Moderator bar and Reports if they also have the relevant permissions.
 
I'm not seeing how to determine the hierarchy of group permissions.

For example, I would have thought the place to start would be Unregistered since we have some nodes that are not visible until you're a member. Does Registered inherit from Unregistered? it sounds like Moderating inherits from Registered. Super Moderators inherit from Moderating?

What about ones we create?
 
Unregistered/Unconfirmed is an entirely separate user group in terms of the hierarchy. You can set up its permissions however you want. Registered should be everyone's primary user group. Staff or other user groups should be secondary.

Everything you want members of the Registered user group to have set as Allow and anything you don't want them to have leave as Not Set (No). Then for the Administrative and Moderating user groups, everything that's set to Allow for Registered leave as Not Set (No) for Administrative and Moderating and they'll inherit. Anything that Registered doesn't have that you want Administrative and Moderating to have set to Allow.
 
Very helpful, thanks! Almost there, but I want to make sure I understand a use case of:

Inherited Allow + Revoke = Overall No
Allow + Revoke = Overall Yes

I have:

Public forum 1 (Set to Allow for registered)
- Public subforum 1
- Private subforum 2 (Set to Allow for moderators, Not set for registered)

If I set node permissions for registered to Revoke for subforum 2, am I safe? Do I need to check the box that makes subforum 2 private? Do I need to set node permission for subforum2 for registered to No? Or will any one of these three do the trick?
 
There are two ways of doing it.

1. Set the node as private
2. Allow the 'View node' permission for the desired user group(s) or user(s).

or

1. Revoke the 'View node' permission for the Registered user group
2. Allow the 'View node' permission for the desired user group(s) or user(s).
 
Yikes, sorry, me again. I was explaining group permissions to our ops team who are doing the conversion from vBulletin and they asked some questions that caused me to wonder. I said I thought the following statements were true, but I'd check:

1. Unregistered and Admin do not inherit from other groups. And other groups do not inherit from them.

2. All groups inherit from Registered. So if I create a new group, it inherits all of Registered's permissions, it doesn't inherit from some other group like Moderating.

3. There is one level of inheritance in groups. So Moderating inherits from Registered, Super Moderators inherit from Registered, but Super Moderators does not inherit from Moderating.

Truth or misunderstandings?
 
User groups do not inherit permissions from other user groups, they are all independent. However, a user will have the permissions from all of the user groups they are in. The guide on implementing permissions across multiple user groups explains how this works.

So for example, if a use is a member of Registered, Group X and Group Y the combined permissions from all of these groups is what the user will have. They will not have any permissions from Group Z because they are not a member of that group.
 
What Martok said.

This is the exact reason, as I stated earlier, why it's urged that everyone's primary user group is Registered. It makes it so much easier to make changes later down the road. For example, if you previously disallowed all user groups from editing posts, but you now wanted to allow them to do so, if everyone had different primary user groups based on who they were (administrator, moderator, etc.) and zero secondary user groups, you would have to change the corresponding permission for each user group. However, if you had user groups properly set up, where everyone's primary user group was Registered and those of higher rank (administrators, moderators, etc.) had secondary user groups, you would only have to change the corresponding permission for the Registered user group.
 
Back
Top Bottom