[META] Implement complete coverage of validatable config schema across plugins and entities

Thank you @michaellander for cicking this of. I'm in full support of this idea and also added a related issue at 📌 Config validation for ECA models Active which was triggered by Wim Leers when he first saw ECA in action.

In that related issue, @lammensj already got started with schema improvements for ECA config parts that are not yet down to the plugin level. Compared to the plugin level, that's probably the easier part, but still also very important.

That leads me to the one big question mark that I can't get my head around to yet: when each plugin has its own schema being defined, that doesn't do much yet in terms of validation or improving the reliability. This is because the configuration for an individual plugin will never be stored as config at any time. The only exception would be if the action UI module were used where one could preconfigure actions for later use. But that is a very uncommon way and that module was just recently extracted from Drupal core and doesn't see much maintenance: action module → .

When ECA saves an ECA model in a config entity, that is constructed of the parts that are being worked on in the related issues followed by a list of plugins, each of which having a configuration property that contains a simple list of key-value pairs.

If we wanted to cover that part in the ECA schema as well, we would have to have an aggregate of all the plugin schemas in the ECA schema. Or is there a way to refer to the plugin-specific schema by the plugin ID, including for all those unknown plugins that come from contrib modules?

If we wanted to cover that part in the ECA schema as well, we would have to have an aggregate of all the plugin schemas in the ECA schema. Or is there a way to refer to the plugin-specific schema by the plugin ID, including for all those unknown plugins that come from contrib modules?

You only need to define schema for the actions you are defining, and then you are correct, you can just have an argument for the plugin_id to handle all actions, irregardless of if they are in your purview.
Here are a few Action schema snippets from core:

//from web/core/config/schema/core.entity.schema.yml
action.configuration.action_send_email_action:
  type: mapping
  label: 'Send email configuration'
  mapping:
    recipient:
      type: string
      label: 'Recipient'
    subject:
      type: label
      label: 'Subject'
    message:
      type: text
      label: 'Message'

and

//from web/core/modules/user/config/schema/user.schema.yml
action.configuration.user_add_role_action:
  type: mapping
  label: 'Configuration for the add role action'
  mapping:
    rid:
      type: string
      label: 'The ID of the role to add'

Which would be covered by:

   type: action.configuration.[plugin_id]

@michaellander we're ready with the 3.0.x branch. It is a major refactoring of the integration with modelers, i.e. all of that code has been extracted from ECA. That only affects the eca_ui submodule, everything else is still the same.

ECA 3.0.x will require Drupal 11.2 or later. That way we don't have to bother about any BC.

Would you mind if we now change the target of this and all related issues to that new branch? The plan to release this is in June 2025 together with Drupal 11.2 - so not too far in the future.

That sounds good! 3.0.x can be the new target.

Great. We will have to update all the child issues as well and probably also have to rebase all the forks.

Do we have any estimate by when there's something for review?

Let me follow up with @gantal. I know locally he was testing them against 3.0.x but he was running into a number of automated test failures and was trying to locate the issue. Will get you an answer shortly.