Disallow automatic membership outside of form approach

Created on 23 May 2025, 16 days ago

Problem/Motivation

Group types have a configuration that says authors automatically become members of the group they created. This is good, but the fact that it also happens for programmatically created groups is bad. Our test set-ups are overly complicated because of it and migrations are a pain in the ass.

Steps to reproduce

N/A

Proposed resolution

We need to make this a "create form only" thing, so that calls to our API do not magically behave different depending on what was configured on the group type. So the configuration option remains, but it only applies to form submission.

Remaining tasks

  1. Make this behavior form-only
  2. Write change record
  3. Adjust tests that relied on old behavior

User interface changes

N/A

API changes

No longer create members when group is created through code.

Data model changes

N/A

📌 Task
Status

Active

Version

4.0

Component

Code

Created by

🇧🇪Belgium kristiaanvandeneynde Antwerp, Belgium

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • 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:

    1. Adjust GroupRelationshipCardinalityValidator so it works with new referenced entities
    2. 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.
    3. 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.

Production build 0.71.5 2024