Introduction to Drupal 8 module : Permissions by field

The powerful access control system provided by Drupal 8 and permissions can prove to be a decisive criterion for choosing Drupal. This system is the basis of modules as Organic Group or Domain access, which respectively implement groups within the same site and implement a virtual multi-site architecture.

But these powerful modules, because they also provide a configuration and management interface, are complex and therefore longer to port on Drupal 8. However, it is possible to achieve similar functionality, albeit without their native functional richness, based on this same access control system, for grouping content, users, and to modulate the access rights to these contents, permissions based on existing relations between the users and contents.

The Permissions by field module allows us to control access to contents of a Drupal site in several generic methods, relying on the power of Entity Reference and the Drupal Field API, and to be able to delegate complex management access rights to content publishers according to their needs.

Discover this module and the different possible use cases.

General operating principle

Once installed, Permissions by field  provide a new field type, named Permissions by field. These fields are based on the Entity Reference field type and add additional properties to determine access rights with respect to the referenced entity and the selected options. The field is somehow a lock on its contents, lock whose key is the referenced entity. Suffice while users have the same field, which reference the same entity, to get the key to open the lock on the content and be able to view, update or delete according to the rights that have been associated to the lock.

The module supports the following entity types to generate access rights based on relation with them :

• Contents
• Taxonomy terms
• The roles of the users
• And users. In this latter case, it can give rights to users directly referenced by the field or give these rights to users that reference the user referenced by the field.

We will discover the different use cases provided by this module, and configurations necessary to implement flexible access rights.

Access rights management depending on content

The configuration of a field Permissions by field  to reference content type entities will allow us to achieve an Organic Group (very) light feature very easily. To take the example presented in the figure above, we can associate with the content type Article a Pbf field (Pbf for Permissions by field) that will reference the content type Group. We will then have the possibility of combining articles to one or more groups, and determine for each of these groups the level of rights granted to the group. Similarly, involving another Pbf field to users, field must have the same name machine as created on the content type article, we will associate these users with one or more groups, and because of this association these users will have the rights defined on each article related to their common groups.

Look in pictures how to set up such a functional.

After creating two content types, Article and Group, we add a field Permissions by field to the content type Article. We customize the machine name field: field_pbf_group.

We then set the entity type we can reference, and the number of allowed values. We choose here to be able to reference content, with an unlimited allowed number of values.

We can then set the field's configuration. Configuring fields Permissions by field is very similar to that the Entity Reference field types. This new field type adds configuration options to the field referencing the target entities to determine the access permissions for users referencing the same target entities (in our example, the target entities are the content type Group)

The configuration options granting the permissions on content created are:

• Public: the use of access rights will be those configured globally on the site. The typical use case is to link this content to a group leaving all accessible to visitors, or users "non-members" of the group, according to the configured access rights on the site. Selecting this option disables all other options below that will be inoperative.
• Grant view: users referencing the same target entity will have the rights to view content
• Grant update: users referencing the same target entity will have the rights to edit content
• Grant delete: users referencing the same target entity will have the rights to delete content

We can then associate an article to the node Group 1 and make this article available throughout the site, according to the general permissions set on the site.

Or give access to this article to the members of Group 1(i.e. users who reference group 1 with the same Permissions by field field), with the view and edit rights.

Or give no access to this article, except of course the content's author that will always have all the permissions on his content.

Note that these permissions are not operative until the moment the content is published. If the content is not published, so it's on a draft status, the general site permissions apply (according to the permissions View unpublished content).

Set permissions per node or globally

We can configure how the permissions set by a field Permissions by field will be available to users.

The permissions granted are set node per node.

Either the permissions are set globally.

We can select the desired behavior on the widget settings of Permissions by field, on the manage form display page of the content type.

 

Note that this is in the widget settings form we can also configure the default access rights checked when creating new content, if we choose to configure node by node access rights.

User configuration

To finalize our configuration, it remains to add a field Permissions by field to the users.

We proceed as for the addition of the field on the content type, taking care to use the same machine name (field_pbf_group in our example). We can then associate users to the various groups present on the site..

It is then possible to let users select themselves the groups they wish to join, by editing their profile, or to allow only certain users or roles who can access and edit these fields associated with the users, using a small custom module or with the help of the Field permissions module.

Note that the Permissions by field module is in active development and provide some basic logic to automate the data entry for these fields attached to users, under certain condition (cf. Fields synchronization section below).

Access rights management depending on taxonomy term

Permissions by field module also allows us to determine the access rights relative to a reference to a taxonomy term. The operation and configuration is exactly the same as that based on the reference to a content, but we based this time on terms.

This can permit to modulate some permissions, for example according to some sections of the site, or reproduce this construction of group described above but this time focused on taxonomy term.

Access rights management depending on roles

Permissions by field also allows us to modulate the access rights to content according to user's role. We can create a field on the Article content type that will reference the different roles configured on the site. It's here a common use case implemented by many modules.

For each article, we can then adjust the permissions granted on that content based on user roles.

For example, to grant update rights to the role Editor, and view rights to the role Contributor.

Access rights management depending on users

We can grant rights directly to registered users. But we can also grant these rights to users that reference the registered users. The method you choose to grant the rights must be defined in field settings.

So we add a field Permissions by field to the content type Article and select this time users as the target entity of the field. In the field configuration we can select what method we will use to grant rights under the registered users.

We can then either

• Give configured permissions to users directly referenced by this field
• Give permissions configured to users directly referenced by this field and those who reference from a Pbf field the referenced users

Grant rights directly to some users

The operation of this use case is in fact very simple. We then have the possibility to grant different permissions by user on the content, allowing to play finely on the access rights, content by content, and user by user.

Granting rights to users referencing the user referenced by the field Permissions by field

 

This use case, no doubt rare, permits addressing a permissions management in logical networks between users of a site. Establishing links between users of the site through a field Permissions by field, such as allowing users to connect to other users (friends, relationships, etc.), then we can grant access rights to relations or friends a user who is referenced by the contents.

The configuration of this use case is so similar to that based on the content or terms of taxonomy. The key will be to create a field whose machine name will be identical to the type of content and users Article.

Field's synchronization

You can set up synchronization between two Pbf fields. The typical use case is to reference users from a content type group, to select members of a group, and to synchronize the field associated with these users in order to reference this group who then have the corresponding rights on the contents related to these groups.

To synchronize two fields Permissions by fields, we need two conditions:

• On the host entity (content type), the Pbf field must reference entity type user.
• The user entity type must have a Pbf field which reference the same content type.

Turn to an example to better understand the principle.

We create a Pbf field (machine name : field_group_user) on the content type group and we set it to reference users. If we take the configuration steps described in the section Access rights management depending on content, users have a Pbf field (machine name : field_pbf_group) that reference bundle Group.

We can then configure the field attached to the group to automatically synchronize with the detected field associated to users.

Thus, when a user is referenced from a group, his field will be synchronized with this group, and then inherit the key associated with this group, allowing it to access content that has the corresponding lock.

We also have an option to synchronize back the field attached on the group if the user changes the referenced content (group) from his profile. We then have a two-way synchronization fields. Thus a user can select himself the groups to which he wishes to participate, and the associated field referencing the group "members" of this group will be updated accordingly.

Conversely if the option (Allow Targeted field from users to synchronize this field) is not checked, only the changes made in the Group content will synchronize the field associated with the users.

And we can check that the field associated with the user is synchronized from its configuration page.

This synchronization option can be used to quickly implement simplified management of group's members, whether from the group (by the user who have edit right on the group, rights which may be granted from the same field referencing users), or whether from each user's profile, leaving them free choice to join or leave the groups available.

Manage complex content access permissions

Permissions by field, relying on the fields and on Entity Reference to modulate the various permissions of the content, is used to address many use cases. It is also possible to associate to the same content different fields Permissions by field to set up a complex and flexible system of access rights, accessible to content manager, and not just to administrators or site builders.

Permissions by field is a very simple module. It relies primarily on the power and flexibility of the Entity Reference fields. He can afford to implement complex permissions, whether based on content, taxonomy terms, the user's roles, or a simpler permission's system to address typical use case of spaces, sections or private groups / public within a site.

Because it is based on Entity Reference, we can use Views to create all necessary views based on the relationship established between content, taxonomy terms, roles and users. While offering no native interface to provide a members management, their roles, etc, within a private area as Organic Group module or Group do, Permissions by field may address many use cases simpler that does not require the full power of these modules.