Access control in Sitellite is based on the relations between several things:

Users

Users are what have access (or not) to things in the system. The things users have access to are items in collections (ie. a web page or a file), applications, and anything else that could be considered a "resource".

A given object in the system (ie. a web page) can be restricted based on its access level, its current status, the team it belongs to, and whether a particular user is allowed to access the WebPages resource at all. Aside from the teams, all of these depend on which role a user belongs to.

Roles

Roles define what a user is allowed to do in the system. They control the read and write permissions of a user to the access levels, statuses, and resources.

Roles also determine whether you're an administrative user or not. If not, you're considered a public web site member, and you wouldn't see Sitellite's administrative/site editing features.

Some examples of roles are:

• Editor
• Writer
• Master

Teams

A user belongs to a single team. This creates groupings which imply a degree of workflow in the web site editing process. For example, if a writer creates a new web page with a pending status, its obvious that the editor that should be notified is the one belonging to the same team as the writer.

While a user only belongs to a single team, users can be assigned read and write access to items owned by other teams on an individual basis. The default when creating users in Sitellite is that they can access any team.

Some examples of teams might be:

• Developers
• Human Resources
• Sales

Access Levels

Access levels denote whether an item, such as a web page or application, should be public, semi-private, or private. Using multiple access levels, you can create groups of web site users that can see separate members-only content areas, depending on the role of the user. For example, member users may be able to see certain additional members-only pages, but subscriber users may be shown additional pages not visible to member users.

The built-in access levels include:

• Public - Visible to all.
• Member - Visible to users of the member role or above.
• Subscriber - Visible to users of the subscriber role or above. Subscribers are typically more privileged than members.
• Private - Visible only to admin-level users.

Statuses

Statuses determine the editorial stage of a piece of content, ie. whether it is just a draft, waiting to be approved, approved and visible on the site, or archived. When a role is restricted to certain access levels, you can control who can post items live to the web site and who should require an editor's approval to do so. For example, if a writer doesn't have write access to the approved role, then they will have to publish to pending and have their document reviewed by the editor on their team.

The built-in statuses include:

• Approved - Live on the site.
• Archived - Taken off of the site.
• Draft - Still being revised.
• Pending - Submitted for editorial approval.
• Queued - Approved but waiting to be published live by the SchedulerApp.
• Rejected - Rejected by an editor.

Resources

Resources are an abstract list that represent actual collections or applications or other components of a Sitellite web site. If a user tries to access a collection, Sitellite checks for a resource of the same name, and if found requires that the user has the privilege to view that resource. If a user tries to access an application, Sitellite checks for a resource of the same name, but with the addition of the prefix app_ (ie. app_sitetracker), and if found requires that the user has the privilege to view that resource.

There is also a delete resource that Sitellite uses to verify that a user has the privilege to delete items from the site.

Disabling Users

You can disable an individual user by setting the Disabled property to Yes. Similarly, you can disable all users of a given role or team in the same manner by editing the role or team.