Field Permissions
Set field-level permissions to control who can create, edit, or view specific fields on any entity type.
field_permissions
Install
composer require 'drupal/field_permissions:8.x-1.4'
composer require 'drupal/field_permissions:8.x-1.3'
Overview
The Field Permissions module allows site administrators to set granular, field-level permissions for fields attached to any kind of entity (nodes, users, taxonomy terms, etc.). This provides fine-grained access control beyond the standard entity-level permissions that Drupal provides.
Permissions can be configured for viewing or editing fields in all contexts, or only when the field belongs to content owned by the current user. Special permissions can also be set for editing fields during entity creation.
Field permissions are not enabled by default. Administrators must explicitly enable permissions for each field where this level of access control is needed, keeping sites simple while allowing advanced control when required.
Features
- Field-level access control for any entity type (nodes, users, taxonomy terms, comments, etc.)
- Three permission modes: Public (inherits entity permissions), Private (author and admin only), and Custom (full permission matrix)
- Custom permissions include five operations per field: Create own value, Edit own value, Edit anyone's value, View own value, View anyone's value
- Centralized field permissions report showing permission status for all fields at a glance
- Visual indicators showing whether all users or only some users have specific permissions
- Permission matrix integrated directly into the field settings form for easy configuration
- Support for JSON:API field filter access control
- Extensible plugin system for custom permission types
- Migration support from Drupal 7 to Drupal 8/9/10/11
- Works with any entity type that supports configurable fields
Use Cases
Private user profile fields
Create private fields on user profiles that only the user themselves (and administrators) can see. For example, store sensitive information like phone numbers or addresses that users can view and edit on their own profile but cannot see on other users' profiles.
Editorial workflow fields
Add fields to content types that only editors and administrators can see and edit. For example, an 'Editorial Notes' field that content authors cannot view, allowing editors to leave internal comments about content.
Premium content access
Create fields that store premium content visible only to paid subscribers. Grant 'view' permission only to the 'subscriber' role while allowing all authenticated users to see the rest of the content.
Content ownership verification
Allow users to edit certain fields only on their own content. For instance, users can update a 'Status' field on nodes they created but cannot modify this field on content created by others.
Staff-only contact information
On a staff directory, make certain contact fields (like personal phone numbers) private so only the staff member can view their own information, while public contact info remains visible to all.
Moderation and quality control
Add fields for internal quality scores or moderation flags that moderators can edit on any content but authors cannot see, enabling transparent moderation workflows without exposing internal processes to content creators.
Tips
- Always test field permission configurations with a non-administrator account to verify they work as expected
- Use the Field Permissions report at Administration > Reports > Field permissions to get a quick overview of all field permission settings
- Remember that permission settings apply to all instances of a field storage, not individual field instances - changing permissions on one bundle affects all bundles using that field
- When migrating from Drupal 7, field permission settings will be automatically migrated if you have the Field Permissions module enabled during migration
- Consider using 'Private' mode for simple author-only access instead of setting up complex custom permissions
- The 'access private fields' permission is a powerful permission - only grant it to highly trusted roles
Technical Details
Admin Pages 2
/admin/reports/fields/permissions
A comprehensive report showing all fields in the system and their current permission settings. For each field, it displays the field name, field type, entity type, bundles where it's used, and permission status. Fields with custom permissions show visual indicators for each permission type (Create, Edit own, Edit anyone's, View own, View anyone's) indicating whether all users have that permission or not.
/admin/structure/types/manage/{bundle}/fields/{field_config}/edit
When editing any field's settings, a 'Field visibility and permissions' section is added at the bottom of the form (visible only to users with 'administer field permissions' permission). This allows configuring per-field access control. Note: This section does not appear on comment fields.
Permissions 7
Hooks 4
hook_entity_field_access
Implements field access control by delegating to the appropriate permission type plugin. Returns AccessResult::forbidden() if the user does not have access to the field based on the configured permission type.
hook_field_permission_type_plugin_alter
Allows modules to alter the discovered field permission type plugins. Can be used to remove, modify, or replace permission type plugins.
hook_jsonapi_entity_field_filter_access
Controls access to fields when filtering via JSON:API. Prevents access to fields with restricted permissions in JSON:API filter queries.
hook_migration_plugins_alter
Adds the d7_field_permission_settings process plugin to migrate field permission settings from Drupal 7.
Troubleshooting 5
Ensure you have the 'Administer field permissions' permission. Also note that field permissions are not available for comment fields.
Custom permissions only appear after a field is configured to use 'Custom permissions' type. Set the field to use custom permissions first, then the permissions will appear at Administration > People > Permissions.
This is by design. Administrator roles automatically have all permissions, including field permissions. The checkboxes are disabled to indicate this.
For custom permissions, ensure the role has the 'Create own value for field' permission. For private fields, all users can edit private fields on entities they are creating.
This is expected behavior. Users cannot filter on fields they don't have view access to. Grant the appropriate view permission to allow filtering.
Security Notes 5
- The 'administer field permissions' permission should only be granted to trusted administrators as it allows configuring access to all fields
- The 'access private fields' permission bypasses all private field restrictions - use with extreme caution
- Field permissions add a layer of access control but do not encrypt data - sensitive data should still be protected at the database level if required
- When using custom permissions, regularly audit which roles have access to sensitive fields
- Remember that users with full administrative access (uid 1 or roles marked as admin) bypass all field permission checks