Knowledge Base Article

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:

  1. Go to Settings > Roles and Permissions.
  2. In the Community Permission Defaults section, click Edit.
  3. (Optional) To jump to a specific permission to manage, enter it in the Find a permission field.
  4. 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:

Updated 6 months ago
Version 11.0
  • It would be great if Khoros supplied a way to export a list of the permissions, descriptions, recommendations and default settings into a CSV format. While setting up the community I find it easier to create a spreadsheet and make decisions there for default and role permissions before putting it all into place in the platform. 

  • JohnD's avatar
    JohnD
    Khoros Alumni (Retired)

    CyJervis - To clarify, you just want an export of the list of permissions, descriptions, and recommendations to refer to offline, not to be able to set/manage role permissions for re-import, correct.

    We don't have that ability at this time, but I can bring this idea to the team. You can also suggest this idea here.

     

  • That is correct JohnD, I would only need to export the permissions, etc. Yesterday I copied and pasted all the fields into a spreadsheet so my team can start mapping out what our base permissions will be and and the permissions for our different roles. It would be easier to just be able to export the list and settings for the defaults or roles.

    As for making setting changes, I prefer making those myself as if I uploaded a file I would still feel the need to double check them all anyway. Others may think differently.


  • Can we please get a feature request in so that admins can track who made designer changes and when the changes were made?

  • LarryI's avatar
    LarryI
    Khoros Expert

    classen That is on my team's radar. Right now, you will be able to see commits via your Github repo so you can see who did what. We are looking to expose that within the community admin / designer panels.