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

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 2

Creator - responsible for creating and editing content.

Editor - responsible for tuning the content message and the style of delivery, including translation and localization.

Publisher - responsible for releasing the content for use.

Administrator - responsible for managing access permissions to folders and files, usually accomplished by assigning access rights to user groups or roles.

Consumer, viewer or guest- the person who reads or otherwise takes in content after it is published or shared.

Answer 3

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 4

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 5

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 6

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).