Store relation with the parent entity in the database instead of the State API

I like this approach, and the idea of having a field where the information is stored tied to the entity instead of a separated storage.

I don't see the point of the environment specific storage, as we should consider the relationship between the entities as content, which is not intended to be shared across environments. Or are you talking about scenarios where modules like default_content are in place?

Moving into this would definitely solve #3526200: Field Inheritance data is not removed from the database when the entities are deleted nor the module uninstalled and would give other benefits, like using a widget instead of a form alter to handle the inheritance form.

On the other hand, it could be a big BC change for modules and projects depending heavily on this module, like Recurring Events.

I will try to take a look into this for 3.0.0. If I see this is not possible in the timeframe I have to work on this module, I would postpone this one for a future 4.x branch.

Thank you for your proposal!

Created an initial MR that more or less work:

Features implemented:

• Stores the Field Inheritance data in a BaseField for enabled entity types
• hook_form_alter has been replaced with a Field Widget
• No need to set the list of enabled bundles, since the widget visibility logic can take care of it
• Created upgrade path from previous version
• Created FieldStorageDefinitionSubscriber to set default values as a workaround for #3300404: Handle nullable serialized field columns

Todos:

• Take care of field instantiation at config update event instead of Config Form submit to avoid issues when installing the module or deploying cahnges in the list of entity types
• Improve upgrade path to only make the widget visible to the enabled bundles
• Add some kind of confirmation step before submitting the Config form changes indicating that some data might be lost when disabling entity types

Notes:

• #3526200: Field Inheritance data is not removed from the database when the entities are deleted nor the module uninstalled Should not be necessary anymore because Filed API takes care of data consistency
• #3454350: Create seperate permission for adding field inheritance Should not be necessary because there are modules like field_permissions can take care of it

MR is ready for review. It includes the upgrade path from the old DB structure based on the keyvalue storage to the new entity based approach.

All the @todos mentioned in #4 have been addressed in the MR

I have an existing recurring events site with the default inheritances (title/description) and additional inheritances (a media entity reference from the event series) and updated to this branch and ran the database updates. Everything worked as expected.

I tested the base field and ensured that skipping inheritances on a per-entity basis worked and it was all fine.

Very nice work.

MR merged.

Thank you all for your help here!