Managing Permissions

Essentially, a system admin can do anything they want to. They have full access to every Jive SBS feature at every space level. Generally speaking, though, a good best practice is to delegate lower-level administrative and moderation access to other people. For example, a person who uses a particular sub-space regularly is probably a better person to act as that space's administrator, or to moderate content in the space. Delegating frees the system administrator to focus on system issues, rather than on space or content issues.

A space admin has access to administrative features for the space they've been assigned to administer, along with any sub-spaces beneath it (although their space admin access can be revoked in each of those sub-spaces). 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.

You'll find a detailed description of what a space admin can do in Managing Spaces.

User and group admins can create and edit user and group accounts. These are global permission levels that only a system administrator can grant. A user admin can create and edit user accounts, while a group admin can create and edit group accounts. Neither of these permission level grants a person the ability to set permissions — only to manage account information.

Managing Users and Groups provides more information about what user and group admin can do.

Granting moderator permission gives someone two kinds of abilities.

• 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.

Where you set content moderator permission depends on which content you want moderated. For all, though, you grant content moderator permission in the admin console at Spaces > Permissions > Admins & Moderators.

But you'll choose a different scope by selecting the change space link on the Admins & Moderators page.

Note that as a failsafe 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's no moderator there, it goes to the root space moderator's queue.
2. If content would be moderated at the root space 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 they'll 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 on these, see Managing Spaces. For a detailed look at what content moderators do, see Moderating Content.

For non-administrative people, you can assign fine-grained access to application features. Features set a the root space level are inherited by sub-spaces.

You grant permissions — that is, give access to particular people or groups — with the Grant New Permission tab. This works in basically the same way whether you're granting administrative access or access to space features. In both cases, you select the permission you want to grant, enter the name for a user or group account receiving the access, then click Grant New Permission. To grant permissions, in the admin console go to Spaces > Permissions, then select the space you want to grant permission for. Click Admin & Moderator or Space Permissions to reach the page that describes permissions already set for the space.

The following shows the Grant New Permission tab for space features.

The admin console is available to system admins, space admins, and user and group admins. In some cases, features available in the console are also available in the end user interface. The following table lists the pages of the admin console, indicating who has access to the page: system admin, space admin, user admin, or group admin. Page names are linked to related documentation.

The following sections describes how Jive SBS provides access to end user features based on permission levels. Needless to say, whether a given feature — such as the ability to edit a thread — is available to anyone will depend on whether the feature has been enabled for the space's users. These sections focus on typical defaults and illustrate in particular how access is different for administrators and moderators.

The following table lists commands for discussions. It shows which commands are available depending on a person's permission level. Some of these are in the Actions list that's displayed when you're viewing the discussion, while others are visible at the bottom of a reply.

Command	Location	Description	System Admin	Space Admin	Content Moderator	Creator	Viewer
Edit thread	Actions list	Edit the original message.
Lock thread	Actions list	Set the thread so that no one can reply.
Move thread	Actions list	Move the thread to another space.
Delete thread	Actions list	Delete the thread from Jive SBS
Receive/stop email notifications	Actions list	Control email notifications for yourself (as the person logged in).
Send as email	Actions list	Send an email about the thread to other people.
Convert thread to document	Actions list	Create a new document using the text of the thread.
View as PDF	Actions list	View the thread as PDF file.
View print preview	Actions list	View the thread as it will be printed.
Edit	Reply body	Edit the text of a reply.
Delete	Reply body	Delete a reply.
Branch	Reply body	Create a new discussion thread using the reply as the first message.
Abuse (with reporting enabled)	Reply body	Report an abusive post to administrators.
Reply	Reply body	Add a reply to the thread.

The following table lists commands for documents. It shows which commands are available depending on a person's permission level. All of these are in the Actions list that's displayed when you're viewing the document.

Command	Location	Description	System Admin	Space Admin	Content Moderator	Creator	Viewer
Edit document	Actions list	Open the document in the editing window.
Manage versions	Actions list	View the document's version history.
Move document	Actions list	Move the document to another space.
Manage collaboration	Actions list	Specify who edits and approves the document, and whether comments are allowed.
Delete document	Actions list	Delete the document from Jive SBS.
Receive/stop email notifications	Actions list	Control email notifications for yourself (as the person logged in).
Send as email	Actions list	Send an email about the document to other people.
View as PDF	Actions list	Open the document as PDF file.
View print preview	Actions list	View the document as it will be printed.

A person's access to space-level features is determined by their permissions level. These features are typically available when a person is looking at the space's All Content tab. In addition, a system or space admin has access to the customize link on the Overview tab, through which they can customize the layout of the Overview tab.

Command	Location	Description	System Admin	Space Admin	Content Moderator	Viewer
Start a discussion	Actions list	Create a new discussion.
Create a document	Actions list	Create a new document.
Write a blog post	Actions list	Create a new post to the space's blog. Any set as an author on the blog can post to it, and only those set as an author can post.
Create an announcement	Actions list	Create an announcement that will be visible in the space.
Create a poll	Actions list	Create a poll that will be visible on the All Content page, or (optionally) the space overview.
Create a tag group	Actions list	Create a tag group to collect tags.
Create a sub-space	Actions list	Create a space that's inside another space.
Create a project	Actions list	Create a new project to organize tasks.

In the inherited scheme, the newly created sub-space inherits permissions from its immediate parent space. By default, as shown here, the green-tinted permissions are granted, while those without a green tint (but with cleared boxes) are not granted.

In the open scheme, access is open for registered users but several of the permissions are explicitly revoked for anonymous users. In particular, these users can see the space, documents, and comments, but they can't contribute by creating content, voting in polls, and so on.

Notice that the ability to create blog posts is revoked even for registered users. That's by design — typically, a blog's role is to convey the thoughts of a particular user or team. Revoking permission here gives you the ability to grant it as needed.

The restricted access scheme is designed to exclude anonymous users but provide access for registered users.

The private scheme revokes permission for everyone accept the system administrator. This scheme is useful if you want to create a space that's unavailable to everyone, with the idea that you're going to explicitly allow access only to certain users or groups. After you create the space, you can grant permissions to those who'll be using it.