Created by: gwideman, Nov 8, 2011 9:29 pm
Revised by: gwideman, Mar 12, 2012 12:25 am (11 revisions)

In this article I explore a core use case for permissions that are needed in a content management system which is intended to supporting collaboration.

Overview

Simplistic "broadcast" permissions

Many wiki and simple CMS systems implement only the capability to accord users different levels of permission which pertains to the the entirety of site content. This is serviceable where a single individual contributor, or small group of cooperative contributors, take responsibility for the site as a whole, and are mainly broadcasting the content to the rest of the world.
However, this scheme does not support sophisticated collaborations within and between diverse groups of users with varying needs for selective control over who sees and can edit what..

Permissions to support collaboration

For more complete control over who can do what we need something more sophisticated. At the point where a user accesses a piece of content, the system must determine whether the combination of:
  • this individual user
  • this individual content item
  • this particular request action
... is to be allowed. Of course this requires that at some previous time someone has established those rules. Therein lies the challenge.
Permissions could be defined at that finest level of granularity (for every combination of user, content item, and action). This idea is illustrated by the following matrix:

User 1
User 2
User 3
User 4
...
Content A
...
...
...
...
...
Content B
...
...
...
...
...
Content C

Allowed?
  • View
  • Comment
  • Edit
  • Delete
  • Publish
  • ...



Site admin feature X
...
  • Manage X
...
...
...
Site admin feature Y
...
...
...
...
...
...
...
...
...
...
...
The figure above highlights an immediate problem: The number of combinations of Users, Content items, and possible actions, rapidly gets very large and unwieldy as the number of users and number of content items grows. Clearly it is impractical to manage permissions by manually setting the permissions for every combination of user and content item (and admin feature).

Making permissions tractable: "Set of Content" and "Group of users"

To make the task more tractable, most permissions systems offer mechanisms to manage settings at a coarser level of granularity.
Finest
granularity
Coarser
granularity
Meaning of coarser-granularity concept
User
Group of users
Set of users who share access (of some kind) to a set of content
Content item
Set of content items
Set of content items for which it's convenient to accord access collectively to a group of users
Action permission
Roles
Collections of fine-grained access permissions. Example: "Contributor" role can view and edit content, but not change the site's theme or add or remove users.
Note that "Group of users" and "Set of content items" only make sense in combination with each other: "Who should be a member of this group?"... "Depends what content items we are including in the content set we are giving them permissions for!", and vice versa.
So this suggests a concept to capture the core idea of this association of "group of users" with "set of content". For want of a better term, "Project" is often used. Elsewhere, the term "Group" stands for this concept, meaning both "group of users" and "group of content", or maybe "grouping together of users and content". (Note: "Project" as used here does not relate well to "Project" as used on wikispaces.)
In this terminology, Project has:
  • A set of associated content items
  • A set of associated users
    • A user's association to a project will include the property of what role(s) the user may play with respect to the project's content items, and perhaps a role in the administration of the project.
Notes:
  • Elaborations that a system may implement
    • A user definitely can be associated with more than one project
    • A content item could be associated with more than one project.
    • A user may have more than one role in a project
    • Permissions may need additional variations according to the different phases in the lifecycle of a content item, for example prior to initial publication versus after publication.

[ E-R diagram! ]

Representative set of permissions.

The following sections show some representative roles that a system might offer, and the permissions each role might include.
Here I've also added the wrinkle that the permissions pertain not just to a document of a particular project, but to a document at a particular phase of its lifecycle. So that expands the "permissions matrix" like this:
  • Project x User role x Document phase
  • (... where Project has already identified the association of a set of users with a set of documents.)

"Draft" phase

A piece of content is in preparation, not yet ready for initial consumption

Actions on a document
User roles
Create
Delete
Edit
View
Comment
Publish
Project mgr, or
Doc author/owner
Y
Y
Y
Y
Y
Y
Project contributor


Y
Y
Y

Project consumer






Prospective consumer






Random public






"Published" phase

A piece of content is published to a wider audience, and accepting ongoing refinements and updates.

Actions on a document
User roles
Create
Delete
Edit
View
Comment
Unpublish,
new rev
Project mgr, or
Doc author/owner [1]
Y
Y?
Y
Y
Y
Y
Content contributor


Y
Y
Y

Content consumer



Y
Y

Prospective consumer



Y
Y?

Random public



Y?


In these tables, most of these permissions are relationships between a group of users and a set of content. For example: With respect to a set of documents called "ProjectX", Fred, Marie and Bob have "Content contributor" roles.
[1] The exception to this group-to-set pattern is the role of "lead author (owner)", which is between an individual document and an individual author. In some scenarios, all of a project's documents might be initiated, deleted and published by a manager. In other scenarios, content contributors could perform these actions. In the latter case, once a document has been created, it is often useful for the system to regard the creator as having special rights over the document.
The roles shown here are not optimum for all situations, but in my observation they do parallel a very common set of relationships that people have with documents and other kinds of data, and even with products in general.

Management of users, projects

In addition to managing content, there will be responsibilities for managing users and projects. That is to say, managing which users are accorded which roles. This responsibility might be accorded in different ways; here are two alternatives:

Super admin takes care of user admin

Admin role
Create project
Assign project mgr
Assign users' roles
Super admin
Y
Y
Y

Super admin delegates user admin to project mgr

Admin role
Create project
Assign project mgr
Assign users' roles
Super admin
Y
Y
Y
Project mgr


Y
As portrayed here, management of users generally needs to be separate from management of content per se. For example, a permission to edit a page should never be tied to a permission to set user roles or to edit the structure or look-and-feel of the website.