One of the greatest things about Drupal is the ease at which you can create different types of content – aptly named “content types”. A typical Drupal installation is preconfigured to include article and basic page content types. Depending on other enabled core modules, forum, poll, and blog post are thrown into the mix as well. Custom types can also be created, which we’ll discuss now.
The Beauty of Content Types
When we approach a new website for one of our clients, one of the first things we brainstorm is which content types will be necessary to achieve the desired end result. Many content types are common to many projects such as basic page, blog article, company member bio, store location, or gallery.
The ability to structure a site (and then layout nodes specifically to the type of content represented) was one of Drupal’s most persuasive arguments when FliteHaus selected its content management system (CMS) of choice.
Root Permissions vs. Client Permissions
The one area that we, as a company, had to iron out – and have been perfecting over the last few years – is the assignment of permissions for these content types. Anyone who has seen the Drupal permissions page knows it is a nightmare of checkboxes that must be precisely managed. While we – the core admins of the site – need to have full control over all aspects of the content, we also need to lock down certain areas that clients need to stay out of.
A Content Type-Based Roles and Permissions Solution
After deliberating over how to structure our roles and permissions, we’ve solidly decided on a system of creating roles based on content types. For any given site we might have a “page admin”, “blog admin”, “gallery admin” and so on. In addition, we can also have roles like “blog author” that may add/edit/delete their own content, but not all blog content site-wide.
Here are just a few of the things that we consider for each role:
1- Will this role be able to create this type of content?
Many times we omit this permission for the page admin just to keep the site architecture in tact.
2- Will this role need the ability to edit all types of this content, or just the pieces created by this user?
Blog sections in our clients sites will usually have a “blog admin” and a “blog author” role, assigned to the appropriate users.
3- Does this role need Full HTML access or just Filtered HTML for textareas?
Textareas are, unfortunately, a great place for uninformed authors to overdo it, so we sometimes strip permissions to just what’s necessary.
4- What other administrative privileges does this role need (unpublish content, view content directory, change authoring info, set page titles, etc)?
This is mostly for blog admins, but could include others. We often use a module called Override Node Options for many of these extra permissions.
5- If this is a webform admin, what should they be able to see as far as form submissions are concerned?
Sometimes we (and our clients) just prefer to have form results emailed to them and never even enter the backend for this information.
Roles per Content Type; Assigned to Users
What this system allows us to do is define the types of users we want to allow administering the content in the site. Once we’ve defined those types, we can assign the roles to users as necessary.
For instance, the main administrator for our client’s company may have all roles, a client’s HR staff member may have an “employee directory admin” role to add new hires and the “blog author” role to announce the new hire to the company.
Drupal will figure out what the highest level of access should be for any given user based on all the roles assigned. This keeps the user permission management to a minimum and focus on user types.
This has been our strategy and it has served us well. If you are setting up permissions in a different way, even in a different content management system, I’d love to hear about it! Leave me a note in the comments!