Module Description
The field inheritance module can be considered to be a field-level entity reference alternative. It allows site administrators to inherit any field from any entity into any other entity. For example, imagine a site has an entity, or content type, named 'employee' and each employee can work in a specific branch or location of the company. In order to display the address of their branch or location on their view page traditionally an administrator would either tag that user with a specific taxonomy term, which in turn would also be tagged to an entity, or content type, called 'location' - thus making a three-way connection from employee-to-term-to-location. Alternatively, using an entity reference, an administrator could directly link the employee to a location entity. Both approaches then require a developer to extract the address field from the location entity and display it on the employee entity.
Using field inheritance is different. An administrator sets up field inheritance mappings which dictate which fields of which entity bundles are inherited to which other entity bundles. In the example of the employee and location, a mapping would be made to inherit the address field from the location entity bundle to the employee entity bundle. Then, automatically, a new field will appear on the employee entity's manage display, which can be placed in whatever order using whatever appropriate field formatters available, as if it were a real field on the employee entity.
This will pull in the address field data directly into the view, and the administrator can use whatever field formatters are available for an address field when it comes to displaying that field in a specific view mode. With one field inheritance mapping, an address could be displayed in text, or as a map, on different display modes of the employee.
When editing a specific employee entity, a content editor can specify which entity to use as the source of the inheritance. So much like creating an entity reference to the location entity, a content editor can enter the name of the location and it will connect the dots, and inherit the data. This way, if the underlying address data of a location changes, it will update automatically to any employee entities that are inheriting from that entity - without the need for any changes to the employee(s) themselves.
Known Incompatibilities There are 2 known incompatibility issues with Drupal Core at this time:
#2981047: Allow adding computed bundle fields in Views - This prevents inherited fields from being used in Views. However, applying the patch or MR within the issue does resolve this problem, depending on which core version is being used.
#2280639: Add the FieldStorageDefinition class to define field storage definitions in hook_entity_field_storage_info() - This prevents computed bundle fields from working as they expect to have a storage definition, which is not applicable. This issue has been circumvented with a custom FieldStorageDefinition which extends and modifies BaseFieldDefinition.
Using field inheritance is different. An administrator sets up field inheritance mappings which dictate which fields of which entity bundles are inherited to which other entity bundles. In the example of the employee and location, a mapping would be made to inherit the address field from the location entity bundle to the employee entity bundle. Then, automatically, a new field will appear on the employee entity's manage display, which can be placed in whatever order using whatever appropriate field formatters available, as if it were a real field on the employee entity.
This will pull in the address field data directly into the view, and the administrator can use whatever field formatters are available for an address field when it comes to displaying that field in a specific view mode. With one field inheritance mapping, an address could be displayed in text, or as a map, on different display modes of the employee.
When editing a specific employee entity, a content editor can specify which entity to use as the source of the inheritance. So much like creating an entity reference to the location entity, a content editor can enter the name of the location and it will connect the dots, and inherit the data. This way, if the underlying address data of a location changes, it will update automatically to any employee entities that are inheriting from that entity - without the need for any changes to the employee(s) themselves.
Known Incompatibilities There are 2 known incompatibility issues with Drupal Core at this time:
#2981047: Allow adding computed bundle fields in Views - This prevents inherited fields from being used in Views. However, applying the patch or MR within the issue does resolve this problem, depending on which core version is being used.
#2280639: Add the FieldStorageDefinition class to define field storage definitions in hook_entity_field_storage_info() - This prevents computed bundle fields from working as they expect to have a storage definition, which is not applicable. This issue has been circumvented with a custom FieldStorageDefinition which extends and modifies BaseFieldDefinition.
Module Link
Project Usage
928
Security Covered
Not Covered By Security Advisory
Version Available
Production
Module Summary
The field inheritance module aims to solve the problem of easily inheriting fields from one entity to another in Drupal, allowing for efficient data management and display customization.
Data Name
field_inheritance