Chapter 2: Built-in Roles

You should be starting to get a feel for how all the pieces of Sitellite access control system work together to form a whole. At this point, some examples should help solidify these concepts some more.

The main built-in user roles are:

• anonymous - A fictional public visitor role with read-only access to everything public (access level) and approved (status).
• editor - A site contributor who approves content for use on the live website.
• master - An all-powerful user role for performing administrative tasks.
• member - A registered version of the anonymous visitor, which grants them additional access to the member access level.
• writer - A site contributor whose content requires editor's approval before being shown on the website.

Sitellite's built-in workflow utilizes the writer and editor roles. A writer contributes content to the website but is not allowed to approve their own content, so their contributions require approval from an editor before they'll be seen on the website.

An editor is notified via email when a writer on their team has set the status of a content item to Pending. This means they feel the item is complete and ready for publishing.

The editor can then set the document to approved, in which case it becomes visible on the website, or to rejected, in which case an email is sent back to the creator of the item to correct the changes and resubmit it for approval if necessary.

Sitellite gives you the ability to define your own resources, teams, roles, access levels, and statuses. The defaults for most of these are usually a good starting point, but sometimes custom statuses for example are needed. All of these can be managed through the Admin menu in Sitellite's Control Panel. Creating a new status automatically makes this status available to each role in the role add/edit screens for example.

The most common customization is to require more strict team access. The steps for doing this are as follows:

1) Define all of the teams you will need for your website.

2) Create your users belonging to each of these teams and being of the appropriate user roles.

3) When creating the users, make sure you visit the Access tab on the add form and clearly define which teams the user should be able to access. Remember, the default is Read and Write to all teams.

4) Now these users will only be able to create and edit content owned by that team. Create this content and assign it to the appropriate team, or have the users from each team begin creating their own content.

Please note that a user will be able to assign team ownership to any team they can write to, not just their main team.

Next to team restrictions, another common customization is to require additional steps in the approval process. This can be accomplished as follows:

1) Define the additional steps of approval as individual statuses.

2) Create or edit the user roles as appropriate, granting Read and Write access to the specific statuses that a role must be limited to. Typically a user will need Read access to the step or status preceeding them, and Read and Write access to the status or statuses they can set an item to.

3) Create users for each of these steps. Make sure the users belong to the appropriate team. Users within a single workflow cycle must all be part of the same team, and identical or separate cycles can be performed by separate teams.

4) If workflow notifications are required to help communicate the next step to the appropriate user, you'll need to create a custom workflow action for that. Please refer to our workflow documentation for that. The cms_services_notice workflow action is a good example to work from as a starting point, since it provides the default notification behaviour built into the CMS already.