Custom Permission Levels and User Overrides for Spaces

Overview

This article provides information on the custom permission levels, and user overrides for 'Spaces' which can be assigned to allow (or restrict) specific permissions to handle corner cases.

Information

When you create a custom permission level or a user override, you design exceptions to existing rules. Such exceptions could replace permission levels included by default 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 blog under a space. You might also create a user override for a particular user who will be the administrator of a space, managing its permissions, and creating sub-spaces under it.

Please see Creating Custom Permission Levels for Spaces and Creating User Overrides for Spaces to learn how to perform the respective task.

Customization Categories

When you create any customization, your options are divided into three categories:

No Access

Available for a user override only, this option lets you exclude a particular user from access to the space. This category is designed as a single user approach. To prevent access for a group of people instead, ensure that those people are not included in the groups that have access. To restrict access to a space that contains sensitive information, create a user group that provides for people who should have access, leaving out people who should not have it.

Access Space

Available in custom permission levels and user overrides, this category provides fine-grained control using which you assign permissions specific to each type of content. This category is useful if you want to create a permission level that grants access to create discussion threads but lets someone only view documents. When you select this category while customizing, you have access to a list of the types of content, each with a list of the access levels available for it. You choose an access level for each type of content.

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

Advanced Access

The advanced access level for each type of content provides even finer control of permissions. After you select advanced access level, select checkboxes for the permissions which you want to be customizable.

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

The following options are also available for customization.

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. Use this category to assign administrative roles that are specific to the space. The following table briefly describes the available access levels with more details provided in the sections below.

Full Control

Someone with full control has access to administrative features for the space, along with any sub-spaces under it. A space administrator can create sub-spaces, set content defaults, and set permissions for the space. The administrator can see content that is in a moderator queue but has not been approved yet, as well as designate other space administrators.

Moderate

Granting moderator permission gives someone two areas of access:

• A content moderator can approve or reject content before it is published. Setting this up involves not only assigning content moderation permission but also turning on moderation for the kinds of content that you want to be moderated. Note that this ability is not inherited in sub-spaces; the moderator can approve or reject content only in the place where they have been assigned permission.
• A content moderator has access to certain links for handling content after it is 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. These abilities are inherited by sub-spaces of the space in which the permission is granted.

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:

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

The above applies to new requests only. For example, if a request is in the queue when moderators are removed, the request remains in the queue until someone approves or rejects it. Existing requests are not routed to the next queue up. If there is only one moderator and is deleted from the system, then requests currently in the queue will be orphaned even after a new moderator is assigned. If moderation permissions are revoked for someone, the user will still have access to the requests currently in the queue but will not be able to approve or reject them.

For more information, please see Moderation in Jive.

Back to top