- Issue created by @kristiaanvandeneynde
- 🇧🇪Belgium kristiaanvandeneynde Antwerp, Belgium
Okay I just realized we can kill the wizard with this approach + 📌 Create a new editor flow that does not involve wizards or custom pages Active
First of all we will need to remove the wizard, but not with the automatic selection of the group from the other issue. This can be done as follows:
- Adjust GroupRelationshipCardinalityValidator so it works with new referenced entities
- Create a service that attaches (part of) GroupRelationship form to another Group or entity form. This will only attach the form if there are any custom fields on it that are accessible.
- If it can't attach a form, it will still attach a submit handler that creates a blank GroupRelationship (GR) entity with either the newly created Group or groupable entity added to it.
- If it can attach a form, we attach a validation handler and submit handler along with the form:
- Validation handler builds the original form's entity and assigns it to the GR's correct reference's "entity" property. It then calls validate() on that and flags violations on the GR subform.
- Submit handler builds and saves the original form's entity, then assigns that to the GR it builds and saves the GR.
- Double check that cardinality is properly reported even if fields for group and entity are hidden. Should be fine because we call $entity->validate() ourselves
- 🇧🇪Belgium kristiaanvandeneynde Antwerp, Belgium
We also need to make sure that, when we're on a config form that got modified by our service, we do not call ConfigWrapperStorage->wrapEntity() during the form validation step as that actually saves a ConfigWrapper in the system for a config entity that may not get saved after all. It should be harmless if that happens, but better safe than sorry.
We should instead manually create one so that it has isNew() still set. It's only for validation purposes, so the wrapper should never get saved.