Aurora: Best practices: roles and permissions

When you first launch a community, permissions and roles are fairly easy to manage because there are a limited number of roles, ranks, and members. As your community grows, you will need to add new ranks and roles to further segment your membership and reward the most active participants.

Although you can set individual member permissions one at a time (not recommended), Khoros Communities are designed to help you manage permissions through a hierarchy of roles at the community, category, and board levels. The advantage to this approach, aside from the obvious reduction in the sheer number of moving parts, is a more predictable and manageable permissions structure.

The cornerstone of this structure is a link the system creates between roles that have the same name, but that exist at different levels in the community. When you assign roles to members at the community level, they automatically inherit membership in roles that have the same name at the category and board levels. The settings for the new board-level role are stored with those of the higher-level role.

Best practices for working with permissions and roles

• Keep it simple, especially when first launching your community.
  In the early days of the community, before your active members emerge, you can get by with just a few default roles (Administrator, Moderator, and Khoros or community defaults). At this stage, you want to encourage participation by making it easy for new members to sign in and start posting. You can add roles later as you need them.
  
• Set your community-level defaults to the lowest common denominator in terms of access.
  These defaults apply to all new community members at all levels of the community and are typically the most restrictive settings. As members gain experience in the community and advance up through the ranks, you can give them additional permissions through roles that explicitly grant access. You can always override these defaults with role-based settings at the category or board level.
  
• Create roles at the community level, and then create category- or board-level versions of the same roles if you need them.
  The purpose of a category- or board-level role is to override the community-level settings for a specific category or board. Members who have the community-level role also get the permission settings from the lower-level roles. The names of the roles at all three levels must be exactly the same—including capitalization and spacing—for the connection between roles to work. For example, “Vip” and “VIP” are not the same. The lower-level settings apply only when members are at that level. For example, a category-level permission applies only to members in that category. Elsewhere in the community, community-level permissions are in effect.
  
• Always assign roles at the community level rather than at lower levels.
  This enables you to manage roles and permissions from a single location rather than having to go to each category, for example, and listing the members who have a role assigned to them. Members get the access allowed by the community-wide settings as well as the category-level or board-level override settings for specific categories or boards. The category- or board-level roles typically give members access to areas or features that are off-limits to the rest of the community.
  
• Always use roles to assign permissions.
  The system is designed to track membership in a role, not individual permission settings. As a result, you can easily determine which roles a member has or which members are assigned to the same role. While you cannot assign permissions to individual members, you can look up which roles & permissions are assigned to a particular member (see Look up a member's roles and permissions.)
  
• Observe these general tips:
• Configure permissions and roles to the Principle of Least Privilege. (Apply only the minimum required permissions for a role.)
• Change permissions within roles only where the default, inherited permission doesn't suffice.
• For each role, fully document the function of each role, its included permissions, and its purpose and location (for example, if it exists at child levels of community). Provide these details in the role description.
• Use an informative and consistent naming convention when creating roles. Clear and concise role names make roles much easier to scan and manage and enable new admins to intuit the meaning/purpose of a role.