Managing Permissions

Use this guide to learn about granting permissions to people for access to content and administrative features.

When assigning permissions, you follow these basic steps:

Create user groups that capture how you want to grant access to the community's features. Each user group you create can represent a different category of people, from a permissions perspective. You might have user groups for administrators, managers, moderators, bloggers, people in the HR department, people in the Products department, and so on. You create user groups based on how you want to structure access to your community's features.
In each permissions area (administrative, space, social groups, and so on), add the user groups that should have some form of access to the area. For each group you add, assign permissions that capture that group's access. When you assign permissions, you're usually doing one of the following:
- Assign a permission level. For administrative permissions and in spaces, you can use permission levels to assign bundled access permissions. You can also create your own space permission level.
- Assign one or more access permissions. For blogs, social groups, and the rest, you work in a more a la carte way, assigning access by choose from a list of usually fine-grained options.
- Create a user override for special cases. For example, you might want all but one or two people in a particular user group to have the permissions you assigned to the group. For those one or two, you can create a user override that assigns specific exceptions.

The following illustrates the basic pieces of the permissions model. You grant access to people by assigning to them the permissions offered by each of the permission areas.

Starting with User Groups

You'll ease the job of assigning and managing permissions by starting with a set of user groups that reflect the kinds of access you'll be granting. These groups can be defined in an external user identity system (such as an LDAP system) or in the application database.

The application includes two system-defined user groups: Everyone and All Registered Users. These are a good place to start when managing permissions that are in effect across the community. After you've figured out how permissions should be applied for these broad groups, you can start assigning permissions based to user groups you create.

System-Defined User Groups: Everyone and All Registered Users

The application includes two groups that are defined by the system: Everyone and All Registered Users. Consider whether these groups represent different levels of knowledge or trust about the people in them. You probably feel you have more knowledge or trust about someone who has registered to use the application than you do about someone who is using the application anonymously. These groups provide a convenient, built-in way to manage a people's access to application features.

Everyone includes anyone who visits the site, including anonymous users. Think hard about what you want people to be able to do anonymously, but weigh that against the need to engage people to encourage them to participate. (Note that users who merely view content are not counted among the number of users your license provides for.)
All Registered Users includes people who have entered registration information and logged in for access. Use this group when you want to ensure certain kinds of access go only to people who have an account on the system.

Your User Groups

Your user groups will reflect your community's organizational groups. They could be relatively few, with separate groups for those who manage, moderate, and administer the community. They could also be many, with groups representing departments of a company, people with specific privileges (such as blogging), virtual teams within the organization, and so on.

For more on creating and managing groups, see Managing User Groups.

User Overrides

For those cases, when there are exceptions to the rules you've defined, you can create user overrides. User overrides provide a user-by-user way to express those exceptions. You might be further limiting the user's access, but you could also be broadening it, such as to lend an administrative flavor to the user's access.

Permission Areas

Permission areas represent a mix of roles, places, and content types. They include:

Administrative -- administrative and moderation permissions through which people have access to system-wide settings. Most of these provide access to the admin console. With the exception of the Full Access permission level, these don't provide access to content.
Space -- per-space permissions for administering or moderating the space, as well as for working with content there.
Blog -- permissions related to global blogs (such as system and personal blogs) to view and create blogs, comment on global blog posts, and so on.
Social group -- permissions to view and create social groups, as well as work with attachments and images in content there.
Home page -- permissions to create and interact with content that can appear on the communities home page, including announcements, polls, and videos there.
Private message -- permissions to create, send and receive private messages, as well as to add attachments to messages.
Mobile -- permission to access the community from a mobile device, such as an iPhone.

Keep in mind that there are a few wrinkles in the permissions model. For example, the "blogs" area applies only to global blogs, such as system blogs and personal blogs (neither of which belong, strictly speaking to a place). This leaves out blogs in spaces, social groups, and projects, whose permissions are managed in different ways as described in Managing Blog Permissions.

Access Rules

Each permission area exposes its own set of permissions that are based on what you can do in the area. When you add user groups to an area, you assign access from among the permissions that the area offers.

For two of the areas -- administrative and space permissions -- the permissions are bundled into permission levels to make managing permissions for the area easier. In both of these areas, communities tend to set permissions along a similar set of themes. The permission levels are designed to reflect those themes.

Note: You can't break out the bundled permissions in the administrative area as you can with space permissions.

Setting Permissions

You can set home page permissions in the admin console on a permissions page.

On the page, under Groups with access, assign permissions to user groups:
- To assign permissions to a user group not yet listed:
  1. Click Add group.
  2. Enter the name of the user group to add.
  3. Click the Select Permissions button.
  4. In the dialog box, select check boxes for the permission levels you want to apply for the user group.
- To edit permissions for a user group already listed:
  1. Locate the group in the list.
  2. Next to its permission level, click edit permissions.
  3. In the dialog box, select check boxes for the permission levels you want to apply for the user group.
Click the Set Permissions button.

Creating User Overrides

Create a user override to grant a particular set of permissions to an individual. You might need to create an override if:

A person requires a particular set of permissions for an area, but isn't (and shouldn't be) a member of a group to which you've already assigned permissions for the area.
A person is a member of a group to which you've assigned permissions for an area, but they require a different set of permissions than they've received as a member of the group -- in other words, they're an exception to the rule. For example, you might want to separately define their permissions in order to enhance or limit their access in the area.

Use the following steps to create a user override on the permissions page you're editing:

Under User Overrides, click Create a user override.
In the box, start typing the name of the user for whom you want to set the override. Click the popup that displays the user's name.
Click the Set override button to view the permissions you can set.
In the permissions box for the person you selected, select and clear check boxes as needed. In the end you want the list of checked items to reflect the permissions the person should have. Note that you merely clear a check box to remove a permission -- there's no need to explicitly revoke the permission.
Click Set Permissions to save the override you've created.