
home	Products	Use Cases	Buy	Customers	Company	News	Blog	Contact Us

Access Control and Security

Access Control Lists (ACLs) allow server and project administrators to easily manage access to the server and manage permissions in each project.

Groups can be created at the Server and the Project level to make permission management simple. It is also possible to refer to Groups defined in your Active Directory or LDAP server.

Users may belong to groups, and groups may belong to groups. Any given user inherits the sum of his or her "allow" permissions, minus any "deny" permissions.

The Server ACL Editor

In the server level ACL editor, you can assign server level permissions to individual users and to groups. Besides the typical permissions such as ability to Login and ability to access Server Setup as an admin, there are also permissions including whether a user can Access Address Book / User Profile information of other users, Edit Stylesheets (for customizations), Email content out of the server, or Export content from the server to PDF or WordML formats.

From this ACL Editor, you can easily access Project ACLs or see further detail regarding a given group's membership and their permissions.

The Project ACL Editor

Project permissions include whether an individual can read articles (or only read their own), comment, author, author via email, edit (or only edit their own), change labels once content is posted, create new labels, erase (or only erase their own) and manage the project. Project ACLs also include permissions for Moderation (Read Draft, Read History, Edit Locked, Lock, Publish, Publish Own)

The permissions are interesting (and exceptionally useful in enterprise contexts) when taken in combination. For example, I may only allow a group to read, comment and edit own articles. This way this group of users can comment and edit their own comments.

Here is the ACL List for the SalesDemo group in a project called HR. Most permissions are allowed to the group, but more sensitive permissions like Erase, Project Setup and Lock are held back. You can see that a group called Everyone (which is a system group consisting of all Named Accounts and Visitors) as well as three users (admin, jfrank and Einstein) may have different permissions.

Cross-Labeling to Extend Permission

You can use labels for many purposes in Traction (see Category Labels). Relative to permissions, when you apply a label from one project to an article in another project in Traction it may extend visibility of the article to a wider audience.

In this case, the Engineering project FYI label is applied to an article in the Executive Project.

Engineering project with an FYI label applied

As a result of the cross-labeling, the Executive project article is visible to the audience who can Read the Engineering project. Its like tagging a piece of paper for someone's attention, or forwarding an e-mail. The Visibility dialogue here shows that user's Admin and Bob can see the article as a result of their membership in Executive and Engineering projects. User Visitor (a system "user" representing anyone who has not logged in as a Named Account user) can see the article as a result of at least having Access and Read permission to the Engineering project AND Access permission to the Executive project.

Access Permission as a Project Firewall

The Access Permission is used to enable or disable a user or group's ability to find out about a project's existence. If a user does not have Access permission to a project, then the project will not show in any lists and cross-labeling (as in the example above) will have no effect for that user.

In the example above, it was not sufficient for Visitor to have Read access to the Engineering project, Visitor also had to have Access permission to executive. If Visitor were Denied or not Allowed the Access permission to Executive project, then the cross-labeling activity would have had no effect - the Executive article (and the Engineering FYI label on it) would have become invisible to the Visitor.