Having used Tridion for nearly a decade, I’ve wrestled with the best way to tackle permissions several times. In our case, with our CMS containing over 250,000 pieces of content, controlling access is critical – but it’s also daunting and extremely time consuming to re-do if you get it wrong.
The approach that I eventually settled on works well. It’s powerful, easy to understand and quick to roll out.
If you don’t use Tridion, you might be wondering what all the fuss is about. Surely it’s just a case of giving different user groups permission to read, write or delete different types of content? Well, that’s true, but because the Tridion content management system is more complex than most, the list of things that require access control is fairly long:
- Publications as a whole (think “websites”)
- Schemas (the definitions of different kinds of content)
- Categories (the way that content can be classified)
- Folders (where content is stored)
- Structure Groups (the structure of your websites)
- Targets (where content can be published to)
- Publishing Statuses (the steps along the content creation production line)
Another difficulty is the fact that the GUI doesn’t make the permissions very visible. You can’t glance at a list of folders, for example, and see what the permissions are. You have to open each one to check what permissions are applied and this simply isn’t practical when you’re dealing with large numbers of them.
However, if it’s possible to create a permissions model that’s predictable and logical, there’s less of a need for it to be constantly visible.
My system divides permissions up into three types:
- Ability (eg Intranet Component Editor, Website Page Editor) – specific to Publication
- Content type (eg Job vacancies) – across all Publications
- Team (eg Marketing) – across all Publications
None of these are enough to manage user permissions on their own – a user is given all three of these types (in actual fact they are Tridion User Groups) in combination.
Here’s an example.
Jane needs access to publish the corporate employee handbook as downloads to the Intranet. The groups she’ll need to be a member of are:
- Ability: Master Component Editor
- Content Type: Downloads
- Team: Human Resources
Ability: Master Component Editor
This group gives read access to the Building Blocks Management folder in the Master publication – granting access to the root folder where all content is stored.
Content Type: Downloads
This group does several things – it gives:
- Read access to the folder where Download Components are stored
- Read access to the folder containing the Downloads Schema
- Read access to the folder containing the Downloads Component Templates
- Read access to the Categories used in the Downloads Schema
Team: Human Resources
This group gives write and delete permissions to the Human Resources folder inside the Downloads folder.
Assigning these three groups in combination gives the user the detailed permissions they need but keeps the groups re-usable and modular. The system can be expanded with more Ability groups such as:
- Ability: Intranet Publisher (gives access to the Intranet Publication Target)
- Ability: Website Page Editor (gives read access to the Website Publication’s Root Structure Group)
We’re using this system to help us manage almost 200 devolved authors over four Publications. I hope it helps you too.