Same name in other branches

1. 8.x-1.x field_permission_example/field_permission_example.module \field_permission_example
2. 7.x-1.x field_permission_example/field_permission_example.module \field_permission_example
3. 4.0.x modules/field_permission_example/field_permission_example.module \field_permission_example

Example using permissions on a Field API field.

This example is a relatively simple text field you can attach to any fieldable entity.

In this module we demonstrate how to limit access to a field. Drupal's Field API gives you two operations to permit or restrict: view and edit. So you can then decide who gets to see fields, who can edit them, and who can manage them.

Our field is called field_permission_example_fieldnote. It has a simple default widget of a text area, and a default formatter that applies a CSS style to make it look like a sticky note.

In addition to demonstrating how to set up permissions-based access to a field, this module also demonstrates the absolute minimum required to implement a field, since it doesn't have any field settings.

If you wish to use this code as skeleton code for a field without permissions, you can simply omit field_permission_example.permissions.yml and remove field_permission_example_entity_field_access(). In addition, our call to field_permission_example_theme() is used to set up our description page for the example, which you don't need for a working field.

How does it work?

You can install this module and go to path /examples/field_permission_example for an introduction on how to use this field.

OK, how does the code work?

As with any permission system, we create a MODULE_NAME.permissions.yml file in order to define a few permissions. In our case, users will want to either view or edit fieldnote fields. And, similar to the way node permissions work, we'll also include a context of either their own content or any content. So that gives us 4 permissions which administrators can assign to various roles. See field_permission_example.permissions.yml for the list.

With our permissions defined in the YAML file, we can now handle requests for access. Those come in through hook_entity_field_access(), which we've implemented as field_permission_example_entity_field_access(). This function determines whether the user has the ability to view or edit the field in question by calling $account->hasPermission(). We also give special edit access to users with the 'bypass node access', 'administer content types' permissions, defined by the node module, and the 'administer the fieldnote field' we define for the module.

One tricky part is that our field won't always be attached to nodes. It could be attached to any type of entity. Fortunately, most content entities implement EntityOwnerInterface, which gives us a way to check this. An exception to this is the User entity; here, we just check to see that the account name matches that of $account. We can get the entity itself by calling $items->getEntity(), since these "know" what entity they belong to.

In a real application, we'd have use-case specific permissions which might be more complex than these. Or perhaps simpler.

You can see a more complex field implementation in field_example.module.

See also

Example: Field Types API

field_example.module

Field Types API

Field API

Parent topics

File

modules/field_permission_example/field_permission_example.module, line 8

Functions