Common CMS roles and access levels

Question

I am currently writing a CMS and remember someone (it might have been on here) criticise the existing CMS for not having a robust enough user permissions system. I've got a method planned out but it I feel it has fallen into the usual trap of being a bit too fine-grained which makes understanding and implementing it a horror for end users.

I think having a range of default user roles with permissions would be the answer to this, so I suppose my question is this:

What are the default roles you would like to see in a CMS and what sort of permissions would be associated with these?

Thanks in advance!

Answer 1

Have you researched existing solutions like RBAC? Whilst such a system would most likely be complete overkill for the particular nut you're trying to crack it would at least help to boost confidence that you're on the right track.

That aside, the general roles I'd expect would be along the lines of:

Administator - Total control of the system, can view logs (as you should be logging all changes), etc. plus...

Publisher - Can put content live plus...

Author - Can create content

However, how these roles are applied across the system is where things get tricky, as a specific user would presumably have different rights to different content areas/modules.

Answer 2

Administrator - can create users + all below

Editor - can edit posts of others + all below

Author - can write posts, edit own posts

Answer 3

This is the "best practice" I have ended up with in most projects and am very happy with:

1. Roles

When it comes to roles, I recommend great flexibility, i.e. the ability to create and define user accounts and groups freely (roles like "contributor", "manager" etc. are not hard-coded, but put into a configuration file that can be changed per application). The role configuration is unaccessible to the user, but the engine itself should be free from hard-coded roles.

2. Rights

Rights is where things need to be easy to understand and implement.

I have made very good experiences working with, and checking against, very fine-grained rights on the code / API level:

• see
• view
• edit
• change name
• rename
• delete
• move
• change rights
• etc.

but the user never sees those. For them, they are grouped into a very small number of "right groups":

• Read Only
• Edit
• Administer = Move, rename....

The user never sees the "move" right, but only the "Administer" rights group.

That way, you retain the full power of fine-grained rights in your code for the future - you can, for example, easily accommodate for a rule like "interns must be able to edit pages, but not be able to change their titles, nor to delete them", adding a valuable asset to the CMS. For the end user, this functionality remains invisible, and the rights system easy to use.

Answer 4

For most applications, so I think it'll be true for CMSs as well, my customers usually prefer a rights-oriented approach. Here is how it goes :

1. You list the main actions. In your CMS that would be : Create and edit content; Delete content; Classify/categorize content; Validate content; Publish content; Manage users; Etc.
2. You define what actions are allowed or denied for each user

To make things a little better, you can create several roles (Editor; Administrator) to make typical users creation easier (by pre-filling the form when a role is chosen).

Answer 5

I have a custom CMS built on the Zend Framework that uses Zend's ACL to extends some basic roles (so you can deny resources specifically for additional users or allow others to access resources they normally couldn't). My basic roles go from CMS users all the way down to website "members" as follows (I just use one users table to store all my authentication).

Developer

Edit any content, edit layouts, settings, configuration. Use special tools that can call shell scripts and force cron jobs.

Admin

Edit any content, edit layouts, settings.

Author

Edit content.

Member

Can view the login screen, forgot password and bug report.

Now, Zend has a nice ACL implementation so you can easily extends your base ACL class and add new roles that extend from the basic roles. So I might make an "Admin" who has access to one of the Developer tools (e.g. purge or cache management) or lock an author to only be able to manage blogs (and not for example news).

Answer 6

I asked this question a little bit ago and got the following response.

admin           //Manage everything
manager         //Manage most aspects of the site
editor          //Scheduling and managing content
author          //Write important content
contributors    //Authors with limited rights
moderator       //Moderate user content
member          //Special user access
subscriber      //Paying Average Joe
user            //Average Joe

Answer 7

I wouldn't necessarily dismiss the fine grained control system you have now. If you have one that is adaptable focus on hiding away the complexity by providing a simplified interface (eg use the facade pattern or the adapter pattern). The benefits are that you provide users with the simplified version (simple permissions like 'admin' can 'delete' a 'post') while still retaining the fine grained features should you need them later (eg more complicated permission handling is to allow to delete posts when the post is your own post in category X). Then you can provide an alternative to the simplified version for that need in some places.

Answer 8

Admin : The one with all the rights

Author : The one who has all rights to a specific content (like a blog author who owns the blog), also has the permissions to add/invite users to collaborate/view the content

Collaborator : The one who can edit/add content to which the author has given rights, cannot delete the content or invite/add more collaborators

Viewer : The one who can view the content if the author has invited to view

Editors : The one who can approve/edit all types of content

Having a fine grain control is not a bad idea if you expect advanced users/developers to use the CMS. But for novice CMS managers, the basic roles make the system much more usable.