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?

CommentFileSizeAuthor
field_inheritance_permission.patch1.53 KBras-ben

Comments

ras-ben created an issue. See original summary.

ras-ben’s picture

Status: Active » Needs review
plopesc’s picture

Version: 2.0.x-dev » 3.x-dev
Issue tags: +stable blocker

Moving to 3.x branch. Considered as stable blocker.

plopesc’s picture

Title: Create seperate permission for adding field inheritance » [PP-1] Create seperate permission for adding field inheritance
Related issues: +#3500250: Store relation with the parent entity in the database instead of the State API

Postponing 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.

plopesc’s picture

Status: Needs review » Postponed (maintainer needs more info)
plopesc’s picture

Status: Postponed (maintainer needs more info) » Postponed
plopesc’s picture

Issue tags: -stable blocker
plopesc’s picture

Status: Postponed » Closed (outdated)

After #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.

plopesc’s picture

Title: [PP-1] Create seperate permission for adding field inheritance » Create seperate permission for adding field inheritance
camilo.escobar’s picture

The 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 a 3.0.x branch 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.