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 me

Answer 1

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.