Closed (outdated)
Project:
Field Inheritance
Version:
3.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
13 Jun 2024 at 09:17 UTC
Updated:
30 Dec 2025 at 17:44 UTC
Jump to comment: Most recent
I discovered this problem in the recurring_events module:
https://www.drupal.org/project/recurring_events/issues/3357979
As it is right now, field_inheritance only has a single permission.
This means that when you add new instances that should use field inheritance, it does not work, unless you have that permission.
This patch adds a separate permission for also being allowed to actually use field inheritance.
I've also added a details wrapper around the fields, to make the admin experience a bit more friendly.
Important - should we migrate existing users that have the original permission, to also have this permission?
| Comment | File | Size | Author |
|---|---|---|---|
| field_inheritance_permission.patch | 1.53 KB | ras-ben |
Comments
Comment #2
ras-ben commentedComment #3
plopescMoving to 3.x branch. Considered as stable blocker.
Comment #4
plopescPostponing on #3500250: Store relation with the parent entity in the database instead of the State API. We might not need this one if the other goes in.
Comment #5
plopescComment #6
plopescComment #7
plopescComment #8
plopescAfter #3500250: Store relation with the parent entity in the database instead of the State API, the Field Inheritance form is a field widget. And we can use the widget visibility rules for this.
Also, other contrib modules like Field Permissions can help to add more granularity.
Comment #9
plopescComment #10
camilo.escobar commentedThe patch provided here seems useful for sites that cannot immediately upgrade to Field Inheritance v3 and need to remain on version 2 for the time being.
For example, some sites are using version 2 of the Recurring Events module, which requires
"drupal/field_inheritance": "^2". While there is a3.0.xbranch of the Recurring Events module that introduces a dependency on"drupal/field_inheritance": "^3", it is still a development branch and has not been released yet. As a result, sites may reasonably prefer to stay on version 2 for now.Given this context, the proposed approach - introducing a new, separate permission - seems like a practical way to address the issue for sites that must remain on version 2, while still allowing them to plan for a future upgrade to version 3, where the inheritance form field is converted into a widget and its usage and visibility can be handled by modules such as Field Permissions.