Drupal is being chosen as a platform for building websites, among other things, due to its flexibility. If you want a system ideally suited to your business model and better than the competition's systems, Drupal will prove to be perfect. One of the areas you can customise in Drupal is the user permissions system. Take a few minutes to learn about the permission management abilities of Drupal.

General information

Drupal allows you to manage access from the admin panel and from the code level. In this post, I will present these two possibilities and the most common examples of their use.

Roles and permissions in the Drupal core

If this is your first time dealing with Drupal and its permission system, you should know that there are three elements used for granting permissions:

1. User
2. Role
3. Permission

When installing Drupal, you create a root administrator account in the system (identifier 1 in the database). It can be compared to the root user in Unix systems. This user has access to all subpages and settings in the system.

You can add more users to the system. These could be, e.g. the editors responsible for creating the content, or the moderators deciding whether to post the added comments.

If you want to assign a permission to a given user, you do it indirectly by assigning a role to them. There is no association between a user and permissions in Drupal. There is a user-role association and a role-permission association.

How to add an editor role and assign the appropriate permissions to it

This is probably the most common issue encountered in Drupal. You need to let users into your system, but you want to limit their rights to the content management only. You do not want to give the rights to change the system configuration or to add new users.

In order to achieve this, follow these steps:

1. Add a new role on the page "/admin/people/roles/add/".
2. Assign the selected permissions to the role on the page "/admin/people/permissions/". For the content-related ones, check out the "Node" section. Below you can find more information on the permission list.
3. Assign the selected user to the new role on the page "/admin/people/".

Then log-in into the account of the selected user and check out whether they have the appropriate permissions. Maybe you need to extend them or take them away. If you are unfamiliar with the Drupal's permission system, such a test with logging-in into the user account is always worth carrying out.

You do not need to know the password to the user account you want to log-in into. You just need to install the module Masquerade. Thanks to it, you can log-in into the account of any user.

Drupal core permissions overview

When entering the page "/admin/people/permissions/" for the first time, one can get a little scared. This is probably the longest configuration page in Drupal.

Let us start with the table header. You will always see the word "PERMISSION" in the first column. In the next cells of the first row, there will be the names of the roles. The more roles you add (you can add them on the page /admin/people/roles/add/), the more of them you will see in this table.

Then, looking at the first column in its entirety, you will see a long list of permissions. The permissions are divided into sections. The sections are the names of modules. The "Node" section mentioned earlier is named so because the permissions in this section are defined in the "node" module (you will find it on your disk in the core/modules/node directory).

Some sections have only one permission, e.g. the "Block" section has the "Administer blocks" permission only. Others have many more of them.

If this is your first time dealing with Drupal permission settings, I suggest that you read the names of all permissions. The names themselves explain what a given permission is for.

Anonymous & Authenticated

There are two system roles in Drupal that cannot be removed:

1. Anonymous User
2. Authenticated User

The first of these roles is responsible for all non-logged-in users. For example: if you want to add the ability to view user profiles for all non-logged-in for the "View user information" permission, tick the checkbox in the "Anonymous User" column.

"Authenticated User" is the role assigned to all logged-in users. It is important here to understand the permission inheritance. If you assign a permission to "Authenticated User", then all other roles (except anonymous) will be given this permission immediately.

Example: You have the "Editor" role in the system. You assign the "View user information" permission to the "Authenticated User" role. Everyone with the "Editor" role will also be given the permission because they are also considered to be logged-in users.

Moreover, keep in mind that if you select any permission for the Anonymous role (e.g. "View user information" again), but do not select it for the "Authenticated User", the logged-in users will not be able to access the selected section ("View user information" – they will not have access to user profiles).

Worth remembering

• In Drupal, you can add an unlimited number of roles.
• The list of permissions is defined by modules in modulename.permissions.yml files (more on this can be found further in the text). 
• The "Authenticated" and "Anonymous" roles are separate – if you select something for "Anonymous" only, the logged-in users will not be given this permission.
• To test permissions, it is good to use the Masquerade module.

Own permissions in the code

Sometimes there is a need to define your own permissions, e.g. to administration pages defined by new modules or to modify access to the pages defined by the Drupal core.

How to define a permission

You just need to add the modulename.permissions.yml file in the new module (or in the existing one, if you already have your own modules created). If you do not know how to create your own modules, I encourage you to visit the website.

The permission file is a file in the YML format. A simple example can be found in the Popup Message module, right here.

Being defined in the file is a unique name for the permission (e.g. "popup message administration"), and then – the names being displayed on the page "/admin/people/permissions/". You can provide a title in the "title" parameter and additionally – a more detailed description in the "description" parameter.

This is enough to define new permissions. After creating the file and clearing the cache, you will see the new permissions on the "/admin/people/permissions/" page.

How to use a permission

Most often, permissions are being used when defining routing. Take a look at the file.

In the "requirements" section, you can add the "permission" parameter. In this way, you can define the users (or rather roles) with what permission can display the page defined in routing.

The second method is to check out the permissions in your code. User object in Drupal has the "hasPermission" method. In this way, you can check out whether a given user has the selected permission.

// Get the current user
$user = \Drupal::currentUser();
// Check for permission
if ($user->hasPermission('display popup message')) {
// Do something.
}

It is worth to take a look at the hasPermission method here. As you can see, the user ID is being checked there. If the id equals 1, the user gets access without further checking if they have selected roles.

How to check whether the user has a role

Drupal also offers a ready-made method to check whether a given user has a role with a specific name. Provided below is an example of how you can do it in the code.

// Get the current user
$user = \Drupal::currentUser();
// Check for permission
if ($user->hasRole('editor')) {
// Do something.
}

Additionally, there are also methods related to the Authenticated and Anonymous roles:

• $user-> isAuthenticated();
• $user-> isAnonymous();

How to check permissions for operations on an entity

In the application code, you can also check the permissions to operate on selected entities (e.g. Node or User). You can perform certain operations, e.g. depending on whether the user has the right to edit a given entity or to display an entity.

Entities in Drupal have the method access($operation = 'view', AccountInterface $account = NULL, $return_as_object = FALSE). A simple example of use is provided below:

$nid = 545;
$node = \Drupal\node\Entity\Node::load($nid);
$user = \Drupal::currentUser();
if ($node->access('edit', $user)) {
// Do something
}

Defining content permissions

Drupal allows you to manage access to display and edit at the level of a single entry (node). This topic was thoroughly described in our other blog post. Grzegorz Pietrzak described it in the article Drupal Node grants.

Ready-made modules for Drupal related to permissions

There are already many ready-made modules extending the capabilities of the Drupal core. You should check them out before you start writing your own permission-related modules.

Below is a list of a few selected modules that are worth checking out and testing:

• Block Content Permissions
• Block Region Permissions
• Menu Admin per Menu
• Override Node Options
• Menu Item Role Access
• Protected Pages
• Administer Users by Role
• Custom Permissions
• Vocabulary Permissions Per Role
• Disable user 1 edit

Also, check the page and take a look at other modules. Maybe some of them you will find useful.

Summary

Drupal is a very flexible system. Just looking at the possibilities regarding permissions, you can see the multitude of configuration possibilities. If you are building a large website with many editor levels or an internal application (e.g. an intranet system) where the users must have limited permissions, Drupal will do the job very well.

If you need support from Drupal specialists on permissions or other issues, use the services of our Drupal developers.