Custom Permission Levels and User Overrides for Spaces

When you create a custom permission level or a user override, you're designing exceptions to existing rules. Those exceptions could replace permission levels included by default, permission levels you've created, or one-off overrides for particular users.

For example, you might want to create a custom permission level for a group of people who should be the only ones to post to a space's blog. Or you might create a user override for a particular user who will be a space's administrator, managing its permissions, creating spaces beneath it, and so on.

When you create this kind of customization, your options are divided into three categories (described in detail below):

No access: Available for a user override only, this option lets you simply exclude a particular user from access to the space. This is designed as a user-by-user approach. To prevent access for a group of people instead, ensure that those people aren't included in groups that do have access. For example, to restrict access to a space that contains sensitive information, create a user group that contains people who should have access, taking care to leave out those people who shouldn't have it.
Access space: Available in custom permission levels and user overrides, this category provides fine-grained control with which you assign permissions specific to each content type. Want to create a permission level that grants access to create discussion threads but only view documents? This is what you want.
Manage space: Available in custom permission levels and user overrides, this category provides a way to create administrative roles for the space. Each space should have an administrator, even if that role is inherited from a parent space. But typically, the roles available in this category will go to very few people.

The following sections give details on the options available for each of the categories.

No Access

The user has no access to the space and won't be able to see content from it. Pretty straightforward.

Access Space

Use this category to craft custom content-specific access in the space. When you select this category while customizing, you have access to a list of the content types, each with a list of the access levels available for it. Choose an access level for each content type.

The following table lists the access levels that each content type permission level includes, along with the specific permissions each allows.

Table 1. Access Granted for Each Content Type Permission Level
Content Type Permission	View	Create	Reply	Comment	Rate	Vote
Create	Yes	Yes	Yes	Yes	Yes	Yes
Create (for discussions)	Yes	Yes	Yes	Yes	Yes	Yes
Contribute	Yes	No	Yes	Yes	Yes	Yes
View	Yes	No	No	No	No	No
Advanced	See the specifics below.

The Advanced access level for each content type provides even finer-grained control of permissions for a content type. After you select Advanced, select check boxes for the permissions you want the customization to allow.

The following table lists what's available in the Advanced level for each content type.

Table 2. Access Settings Available for Each Content Type
Content Type	View	Create	Reply	Comment/Reply	Rate	Vote
Document	Yes	Yes	No	Yes	Yes	No
Discussion	Yes	Yes	Yes	No	No	No
Blog Post	Yes	Yes	No	Yes	No	No
Poll	Yes	Yes	No	Yes	No	Yes
Video	Yes	Yes	No	Yes	Yes	No

The following are also available as "on or off" options.

Option	Access Granted
Create Project	Create a project in the space.
Create Announcement	Create an announcement in the space.

Manage Space

Use this category to assign administrative roles that are specific to the space. The following table describes the two access levels that are available.

Option	Access Granted
Full Control	Customize the space overview page, edit space details, delete any space content, create subspaces, manage permissions for that space, delete the space, create a category, and manage the space blog.
Moderate	Moderate and edit all content in the space. Selecting this option enables the moderation queue for all content in the space.

Full Control -- Someone with full control has access to administrative features for the space, along with any sub-spaces beneath it. A space administrator can create sub-spaces, set content defaults, and set permissions for the space. They can see content that is in a moderator's queue but hasn't been approved yet. They can even designate other space administrators.

Moderate -- Granting moderator permission gives someone two areas of access:

A content moderator has access to certain links for handling content after it's published. Through these they can manage content by editing, moving, and deleting it as the need arises. For example, a content moderator might lock a discussion thread that is no longer useful or move a document to another space. These abilities are inherited by sub-spaces of the space in which the permission is granted.
A content moderator can approve or reject content before it's published. When moderation is on for the context in which the content was created (such as the space, social group, or even globally), the content moderator for that context will be able to accept or reject the content in a moderation queue. Setting this up involves not only assigning content moderation permission, but also turning on moderation for those kinds of content you want moderated. This ability is not inherited in sub-spaces; the moderator can approve or reject content only in the context where they've been assigned permission.

Note that as a fail-safe to ensure that moderated requests always have a place to go, new requests are routed in the following order:

If content would be moderated at the sub-space level but there's no moderator there, it goes to the system moderator's queue.
If content would be moderated at the system level but there's no moderator there, it goes to the system administrator's queue.

This applies to new requests only. For example, if a request is in the queue when moderators are removed, the requests will remain in the queue until someone approves or rejects them there. Existing requests won't be routed to the next queue up. If there's only one moderator and that person is deleted from the system, then requests currently in the queue will be orphaned even after a new moderator is assigned to that area. If moderation permissions are merely revoked (or un-granted) for someone, then that person will still have access to the requests currently in the queue but won't be able to approve or reject them.

Keep in mind that in order to have moderators approve and reject content in a moderation queue, moderation will need to be enabled for specific content types in the console at Spaces > Settings > Moderation Settings. For more about this, be sure to read the Moderation section.