Nice suggestion. It works great.
Merged into 2.0.x and cherry-picked into 3.0.x
This feature has been provided through the new module Recurring Events Scheduler ( https://www.drupal.org/project/recurring_events_scheduler → )
Marking as Fixed to give proper credit to all the involved folks.
Postponing on 📌 Make 3.x branch compatible with Field Inheritance 3.0.0 Active since some of the bits there are required to make the tests green.
MR is green. Ready for review!
Merged MR that checks the field existence before a¡making any DB update.
plopesc → created an issue.
We can mark it as fixed since 3.0.0 was released yesterday.
Thank you all!
MR merged.
As you mention in the issue, the way how relationships are stored in 2.x branch require to explicitly define all the Field Mappings.
However, in 3.x branch, a new way to define the relationships has been defined in 📌 Allow to define entity based relationships to allow implicit assignments Active .
Migrating to 3.x and defining Entity Mappings instead of Field Mappings would solve the described scenario.
Thank you!
MR created
MR merged!
IS Updated
After
📌
Store relation with the parent entity in the database instead of the State API
Active
, 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.
After 📌 Store relation with the parent entity in the database instead of the State API Active this is not necessary anymore. The Field Inheritance information is stored at entity level and the upstream Drupal subsystems take care of it.
We can work on this one since 📌 Store relation with the parent entity in the database instead of the State API Active has been already merged.
MR merged.
Thank you all for your help here!
Create an issues-fixed list for stable release using the drupalorg-cli tool.
https://drupal-mrn.dev/ is a simple alternative that will make your life easier :)
Tested locally and works as expected.
Made some minor updates in the MR to reduce boilerplate code that can be removed once the module only supports PHP 8.1+
Hope to get a D11 release soon!
Code looks very good, tests are green and tested locally with no issues.
Marking as RTBC.
Thank you!
Feedback has been addressed and the new 3rd level item functionality works according to previous comments.
I would say this can be marked as RTBC now.
Checked and tested locally code in MR 12148 and it looks good to me.
The manipulator approach adds useful flexibility for the future without significantly impacting the current codebase — I think it's a solid direction.
I’ve added a couple of comments to the MR, but this is very close to being ready!
MR merged
Documentation fixed. Thank you!
Thank you for bringing this up!
MR created.
Description field added to v3! 🎉
As part of this MR, the schema architecture has been updated.
Functional MR created
Nice feature for 3.x branch
Postponing on 📌 Store relation with the parent entity in the database instead of the State API Active for now. But this is still open to discussion.
Hello @avpaderno,
I have not heard from the original maintainer along these last 15 days.
I'm still interested in moving forward this module.
Moving the issue to Needs Review to confirm if any other action item is necessary from my side.
Have a great week.
Postponing on 📌 Store relation with the parent entity in the database instead of the State API Active . Module architecture changes there will affect how tests might need to be addressed.
Hello @pfrenssen!
I really like the idea brought in this issue. Last week I started to work on a similar upgrade path for Field Inheritance module. You can see how it looks in 🌱 [META] 3.0.0 Plan Active .
Key part of the upgrade would be to integrate the Field Inheritance architecture changes introduced in 📌 Store relation with the parent entity in the database instead of the State API Active , which you actually suggested a while ago.
I'm wondering if we could define a similar approach for Recurring events, where a new 3.x branch is used to define Drupal 10.3+ releases based on Field Inhetance 3.x.
The reason why I preferred to use 10.3 instead of directly a new 11.x branch was to give sites the opportunity to have an stable environment with the new Field Inheritance architecture before moving to 11.x. This approach was taken by Drupal Commerce and the 3.x version. That was very convenient for us in other Commerce based projects, where the migration was taken in 2 steps to reduce friction points.
I'm open to help and collaborate with the migration of this module, given that it's a key requirement in some of our projects. At the same time a review and test of the new FI architecture would be very helpful to ensure that both modules are aligned.
Postponing on 📌 Store relation with the parent entity in the database instead of the State API Active . We might not need this one if the other goes in.
Postponing on 📌 Store relation with the parent entity in the database instead of the State API Active . We might not need this one if the other goes in.
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.
D7 already reached its EOL. This issue is not relevant anymore.
Thank you for using this module!
Thank you!
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 📌 Unserialize(): Passing null to parameter #1 ($data) of type string is deprecated in Drupal\Core\Entity\Sql\SqlContentEntityStorage Needs work
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:
- 🐛 Field Inheritance data is not removed from the database when the entities are deleted nor the module uninstalled Active Should not be necessary anymore because Filed API takes care of data consistency
- 📌 Create seperate permission for adding field inheritance Active Should not be necessary because there are modules like field_permissions can take care of it
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 🐛 Field Inheritance data is not removed from the database when the entities are deleted nor the module uninstalled Active 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!
plopesc → created an issue.
I see your point, but not sure how to approach it.
Technically each field_inheritance can depend on a different entity. Event Instance A might use the title of Event Series X and the location of EventSeries Y, hence we need an explicit action for defining them.
That's an edge case, but the approach taken there, even if smart, would not cover all the scenarios.
I was thinking in something more in the line of adding an option in the entity form that says "All the Inheritance from Entity:Bundle X will share the source" and store it as it is in the DB. Then, for entities with that option enabled, those fields will automatically be inherited. Meanwhile, regular fields with explicit assignation would remain as they now, waiting for an explicit assignation.
MR merged
Looks good to me.
Marking as RTBC as this will cover a high percentage of the use cases.
Our team will have to use an overridden version of the JS file in any case :)
Hi!
Hace you tried the v1.2.1 released recently?
It should give support for both Commerce v3 and Drupal 11.
Please let us know if that released does not work for you.
Thank you very much @qorban!
MR merged
MR ready
After asking @owenbush, we agreed that the extra value added by this feature is not worth the effrt to maintain the logic for that form.
This feature will be gone in 3.0.0 for now.
If someone else can provide a working alternative, we will be happy to include it in the module.
Sorry for the inconvenience
Marking as Fixed since I merged before I realized @lavanyatalwar was reviewing.
Please reopen if you find any issue.
Thank you!
Moving to 3.x
Moving to 3.x
Moving to 3.x branch. Considered as stable blocker.
Issue addressed in 3.x as well.
Thank you!
MR merged. Needs to be ported to 3.x.
Thank you
MR created
MR merged.
Moving to the 3.x branch
MR created
MR merged. Thank you!
Thank you for the MR @pfrenssen
Agree with your suggestion and opened a new 3.x branch where the MR points to now.
To ensure that there are no conflicts with this new 3.x branch, bumped the minimum requirement from 10.1 to 10.3.