Aurora: Permission descriptions
Each Khoros community permission enables users to perform specific actions. These permissions are assigned (either by default or manually) to different community roles.
Permissions are grouped by feature area on the node where you’re assigning them:
- Accepted Solutions
- Analytics
- Badges
- Blogs
- Boards
- Case Portal
- Categories
- Community
- Content
- Escalations
- Events
- Following
- Groups
- Ideas
- Inbox
- Knowledge Bases
- Likes
- Media
- Member Management
- Member Profiles
- Mentions
- Moderation
- SEO
- Tags
- Widgets
A description and a recommendation as to the type of member who should be granted this permission are displayed by each of the permissions so you know exactly what you’re granting and to whom. You can set permissions globally or at the node level (category or board) in the community structure. For each permission, you can keep the out-of-the-box default setting or explicitly Grant or Deny permissions as needed.
About permission levels
Permissions can be set to Inherit, Deny, Grant, or Assign.
- Inherit – Person has the permission defined in the node or node-level role above the current level. Therefore, this level does not display when you’re managing community permissions defaults but does display for the category, group, and board levels. You can hover your cursor over the Inherit button to see whether the inherited value is Deny or Grant (the button is also displayed as red for Deny and green for Grant).
- Deny – Person does not have the ability to take action described by the permission.
- Grant – Person has the ability to take action described by the permission.
- Assign – Person has the ability to take action described by the permission and has the ability to grant the permission to other members. Typically, this should be given only to Administrator roles.
If you look at the Administrator role, you'll notice that all permissions are set to Assign since Admins can grant permissions to other users. As a general rule, only Admins should be able to Assign permissions to others. There are a few use cases where this could change, but typically speaking, Administrators should be the only ones that have the ability to manage permissions in the community.
The different permission levels cascade down to any nodes below them, but certain permissions at higher nodes will override lower-node permissions:
|
Assign |
Overrides any other permissions given at lower-level nodes |
|
Explicit Grant |
Overrides Default Deny, Explicit Deny, and Default Grant at lower-level nodes |
|
Explicit Deny |
Overrides Default Grant and Default Deny but not Explicit Grant at lower-level notes |
|
Default Grant |
Overrides Default Deny but not Explicit Deny at lower-level nodes |
|
Default Deny |
Does not override anything at lower-level nodes |
Note: If there are conflicts within roles, the explicit exists to override the default.
So for example, if you set a permission to Assign at a particular level, all levels below that for that permission will be overridden even if they are set to Deny (including if you manually/explicitly set it to Deny).
Note: It is a community management best practice to modify permissions at a role level rather than at a user level to ensure consistency across the community.
Manage community permission defaults
Setting community permission defaults enables you to grant the base permissions for all members of the community.
To manage community permission defaults:
- Go to Settings > Roles and Permissions.
- In the Community Permission Defaults section, click Edit.
- (Optional) To jump to a specific permission to manage, enter it in the Find a permission field.
- Set Deny or Grant access for the settings in each area.
Each permission entry displays a description and recommended deny/grant status, as shown in this example:
