LT Jennifer
Member
Having finally wrapped my head around permissions, I thought I'd write this short tutorial that describes permissions (as I understand them). If I have anything wrong, please feel free to reply with a correction.
Basic terms:
An individual permission is one thing a user can or cannot do. Example: Post new thread. I also call it a row because when you edit permissions, each shows up as a row in the permissions panel.
A permission set is a bundle of 96 or 31 individual permissions (or more if some were added by add-ons).
The default permission set is a group of individual permissions all set to Not Set (No). Actually, I doubt that such a set exists, but for the purpose of this tutorial let's assume that it does.
There is one set of group permissions that apply to all users in a particular group, such as Registered or Moderating.
Node permissions always specify which node and which group they belong to, and are relevant only if a user belongs to that group and is visiting that node. There are usually just a few node permission sets, but their number can range all the way from zero to the number of groups times the number of nodes.
For understanding the permission options, I like the following analogy (my notions are in capitals):
Not Set (No): MAYBE
Allow: YES
Never: NO
Inherit: ASK YOUR FATHER
Revoke: WE'LL SEE
The first thing that happens when deciding whether or not to permit an activity is to gather up all the permission sets that apply. That means the default permission set, all the permission sets of the groups the user belongs to, and all the node permission sets for the particular node that the user is visiting that are also for all the groups the user is in.
Of course, we are only interested in the specific individual permission that is being tested.
If the state of a node individual permission is Inherit, and there is a node permission set for the parent node, use that value instead (and if there isn't, or that's also Inherit, keep going up). For Inherit, if there is no higher node permission set (that doesn't say Inherit), just throw it away.
If a group permission is Allow, and the node permission for that group is Revoke, then throw away the Allow (but keep any other Allows).
Now look at all the remaining permission choices: if they are all Not Set (No) or Revoke, or there is at least one Never, don't allow the action. Otherwise, there must be at least one Allow and no Nevers, so do permit it.
If a node is marked as Private, then ignore all group permission sets and use only the applicable node permissions.
Example: Restricting the common user from posting in the Forum Rules subforum:
Create three node permission sets for Forum Rules: one for the Registered group, one for the Moderating group, and one for the Administrative group. In the node permissions, change the Post new thread and Post replies to Revoke for the Registered group, and Allow for the Moderating and Administrative groups. Update them all, and be sure to test them with Analyze Permissions.
JF
Basic terms:
An individual permission is one thing a user can or cannot do. Example: Post new thread. I also call it a row because when you edit permissions, each shows up as a row in the permissions panel.
A permission set is a bundle of 96 or 31 individual permissions (or more if some were added by add-ons).
The default permission set is a group of individual permissions all set to Not Set (No). Actually, I doubt that such a set exists, but for the purpose of this tutorial let's assume that it does.
There is one set of group permissions that apply to all users in a particular group, such as Registered or Moderating.
Node permissions always specify which node and which group they belong to, and are relevant only if a user belongs to that group and is visiting that node. There are usually just a few node permission sets, but their number can range all the way from zero to the number of groups times the number of nodes.
For understanding the permission options, I like the following analogy (my notions are in capitals):
Not Set (No): MAYBE
Allow: YES
Never: NO
Inherit: ASK YOUR FATHER
Revoke: WE'LL SEE
The first thing that happens when deciding whether or not to permit an activity is to gather up all the permission sets that apply. That means the default permission set, all the permission sets of the groups the user belongs to, and all the node permission sets for the particular node that the user is visiting that are also for all the groups the user is in.
Of course, we are only interested in the specific individual permission that is being tested.
If the state of a node individual permission is Inherit, and there is a node permission set for the parent node, use that value instead (and if there isn't, or that's also Inherit, keep going up). For Inherit, if there is no higher node permission set (that doesn't say Inherit), just throw it away.
If a group permission is Allow, and the node permission for that group is Revoke, then throw away the Allow (but keep any other Allows).
Now look at all the remaining permission choices: if they are all Not Set (No) or Revoke, or there is at least one Never, don't allow the action. Otherwise, there must be at least one Allow and no Nevers, so do permit it.
If a node is marked as Private, then ignore all group permission sets and use only the applicable node permissions.
Example: Restricting the common user from posting in the Forum Rules subforum:
Create three node permission sets for Forum Rules: one for the Registered group, one for the Moderating group, and one for the Administrative group. In the node permissions, change the Post new thread and Post replies to Revoke for the Registered group, and Allow for the Moderating and Administrative groups. Update them all, and be sure to test them with Analyze Permissions.
JF
Last edited:
