Permissions and roles for happier users and admins

When you first install Drupal, you are given a lot of power. With all of the contributed modules available, you can do pretty much anything. You can also horribly mangle your site security, make your users hate having to use your site, and end up having to redo work from inexperienced users trying to (ahem) "help." So let's talk about users, permissions, and roles, and how you can use them to keep your Drupal installation merrily un-borked. If you've already been through adding roles and permissions once or twice, you should feel free to skip over the how-to's, and focus on the best practice sections.

One special user: the superadministrator who bypasses normal permissions checks

There is one extra-special user that everyone who has installed Drupal is familiar with: The Superadministrator. Drupal comes with exactly one superadministrator out of the box with a user id of 1. This user is usually named something like admin or root, and bypasses normal permissions checks. When you install Drupal, you are automatically logged in as the superadministrator.

Best practice

You should not be using this user for your day-to-day site maintenance unless you can guarantee that you will never make a mistake (in other words, you really shouldn’t be using this account for day-to-day tasks). Instead, make yourself another login that you use for mundane tasks like creating content, and then use the admin account for the rarer tasks, such as changing the site name. However, you SHOULD be using this user to start administrating roles and permissions as no other role will have that ability until the superuser grants it. 

Best practice

If you work in a team, don't use your personal email for the superadministrator. Use an email that all developers have access to, such as sysadmin@example.com or dev@example.com.

The principle of least privilege

For everyone else, we will rely on the User->Role->Permissions model. The principle of least privilege states that you want your users to be able to do their jobs on the site, but not anything more (definitely check out that page if you are unfamiliar with the finer points of this idea). First off, this prevents anyone who steals an account from being able to do too much damage ("Muhuwahaha, I will now commence commenting - UNMODERATED!"). Secondly, your site is guaranteed to have at least a few careless or inexperienced users, and minimizing access can prevent accidental data loss too (“oops! I thought it was ok to delete that /node view!”). You can easily use Drupal's roles and permissions system to implement this concept. 

Think of the relationships between users, roles, and permissions as the relationship between people, jobs, and tools. The user/people analogy should be pretty obvious and trivial, but I should mention that each person should have their own account and login or the model will begin to break down as you figure out how your users specialize. A role/job is a title given to a user/person that allows them to perform certain tasks. And a permission/tool is granted to a role/job so that a user/person can complete those tasks.

Best practice

Each user should have their own account, so that you can add permissions to each user individually instead of granting privileges to a single account that may not always apply to everyone who has access to it.

Best practice

Map out the people, jobs, and tasks that need to be done before applying any roles or permissions. Once you become familiar with the process, you will be capable of doing this quickly in your head, but in the meantime, map it out on paper. Add it to your site documentation too so that everyone on your team knows what each role is about, such as the following:

• Commenter: A trusted user who is allowed to post comments without moderation.
• Blogger: A user who can create blog posts.
• Content manager: An editor who can create basic pages around the site, edit other people’s blog posts, and moderate comments.
• Site builder: A user who can perform light site maintenance such as adding items to the menu, editing views, and administering blocks.

Permissions

Permissions are the tools that your users will use on a day-to-day basis. Generally, most permissions are positive: they grant users the ability to do a task but rarely take away the ability to do anything (we'll ignore those rare cases for the purposes of this blog post). Some common permissions: 

• Administer blocks
• Administer comments and comment settings
• Post comments
• Use the filtered text format
• Use the full HTML text format
• Administer menus and menu items
• View published content
• Article: Create new content
• Article: Edit any content
• Create and edit URL aliases
• Administer modules
• Use the site in maintenance mode

You can edit permissions for your site at example.com/admin/people/permissions. Notice that you only have two roles when you first create your installation: authenticated users and anonymous users. We'll get into adding roles shortly, but until then, think of these roles as two different types of users: authenticated users are people who are logged into your site, while anonymous users are not. Let's say you want both roles to be able to view comments, but only authenticated users will be able to post comments (which is a reasonable industry standard). You would edit the permissions to look like this (note that two different roles can share the same permission): 

When an authenticated user visits your site, they will see the form to add a comment, but the anonymous user will not. Both users will be able to see all comments.

You can go through the rest of the options in the permissions list on your own, but soon you will need some permissions that only apply to SOME of your logged-in users. 

Roles

To give certain logged-in users different permissions, you will need to create some new roles. Going back to the people, jobs, and tools analogy, you will be creating new jobs and then assigning different tools to each one.

For example, imagine that you want bloggers to be able to create blog posts, edit their own blog posts, and delete their own blog posts. You would create a new role at example.com/admin/people/permissions/roles and then edit the permission for that role. You don't want every blogger to be able to edit other people's blog posts, create views, or change the site name, so if I want to give those permissions to a user, I will need to grant them the appropriate role (moderater, site builder, administrator). The number of roles any site can use is unlimited, but here are some typical roles:

Any user can have more than one role. There's no reason that a user who is a site moderator should not also be able to comment, so it's perfectly normal to give a user two roles: moderator and commenter. 

With all this freedom, you may be wondering whether to create a role or add permissions to an existing role. Use the following guidelines to figure it out: 

Create a new role	Add the permission to an existing role
This is a new permission for a new role ("we've hired a blogger!") This is a new permission that will be shared among many different roles ("we've created a blog and all sales reps and developers can post to it!") This is a new permission that will apply to only some members of a role ("we want some bloggers to be able to post without going through moderation!")	This is a new permission that expands one specific role ("we want all of our content moderators to be able to edit all these new blog posts!") This is a new permission that applies to either anonymous or authenticated users ("we want everyone to be able to see our blog!")

Adding roles to users

Now that the roles and permissions are set up, it's time to grant roles to users. If you only have a few users on your site, you can do this on a case-by-case basis by going to their user page and hitting the edit button.

If you have many users you want to grant roles to at the same time, you can use the people tab at example.com/admin/people. Select the users to grant the roles to, select "Change user roles" from the operations drop-down, and then click "Execute."

Revoking rules is the same process; unchecking a role from a user's edit page with withdraw those permissions from their account, or you can bulk remove roles in the same manner as above.

Depending on your version of Drupal (and how up-to-date it is), you may have to log a user out and then back in again to see role and permission changes. If you're on Drupal 7 (and if you're just starting a site today, you really should be), then you're good to go.

Testing permissions

This is the step that always gets me. I "know" how permissions work, I "know" that I set them up properly, and yet... I forgot to tick off a box somewhere and now someone can't do something that they need to do. So to finalize this walk through of best practices, the big one is to test all your hard (ok, pretty easy) work. Create a dummy user with the role you're testing (and ONLY the role you're testing), and then log in and try to do what you need to do. I like to use an incognito window so I don't have to log out of my administrator window to test.

If you can do the functions of the role that you have set up, then YOU ARE DONE. You now have a reasonably secure site, although there are always ways to get more secure. Happy Drupalin'!