[meta] Make config actions more dynamic

I like it. Some use cases I can think of.

1. Add a field to multiple entity types using the setComponent config action.
2. Updating multiple filter.formats using the setFilterConfig config action.
3. Adding permissions to multiple user roles using the grantPermissions config action.

For clarity, I think the recipe snippet in the description should be.

config:
  actions:
    media.type.*:
      simple_config_update:
        queue_thumbnail_downloads: false

1. Today: apply a config action to a single config entity with a particular name (and you can repeat the config action with a different ID)
2. Proposal: apply a config action to ALL entities of a config entity type

🤔 Is this expressive enough?

I think it is, but I'm wondering if there's use cases we're not thinking of yet. It's fine to gradually expand what we can do, with one important caveat: the syntax we choose here MUST NOT prevent future evolution.

Also: setQueueThumbnailDownloadsStatus() on media types is a pretty obscure use case. Can you expand the issue summary with some more real-world use cases? 🙏

#6: You know...as I think about it, I can't find too many use cases where we'd need to, for example, do the same operation to every node type directly.

But I can easily imagine a situation where you'd want to, say, instantiate the same field on every content type. That's a completely different sort of operation, but I think we'll run into it a lot more often.

Clearly I need to rethink this a bit.

Issue summary is now updated with a more realistic use case. :)

#7++ that seems more common for sure!

every config object with a certain prefix

… or match a certain pattern, such as node.type.* or field.field.*.*.*. Not sure which terminology is the best match to maximize recipe authoring usability.

Would this allow us to remodel "Search api db defaults" as a recipe that can apply those (or at least some) defaults to all content types on a site?
A high level overview of what that module currently does is:
- Configures a search api server + index
- Adds and configures a view
- Adds a new view mode to basic page + article
- Adds all those bundles to search api

I think that'd be an excellent example :)

The current implementation is only on those, but it should do all node types.

See https://git.drupalcode.org/project/search_api/-/tree/8.x-1.x/modules/sea...

Another variation on this use case - what if you want to apply a polymorphic permission (such as "edit own page content", "edit own article content", etc. -- the same permission, but repeated for each bundle of an entity type) to a role?

In other words, what if you have a "super editor" role, and you want to give that role the ability to edit every possible content type, without knowing ahead of time what the content types were, and without going so far as to grant "administer nodes" (or "bypass node access")? I don't think a recipe could that right now.

It would be cool to be able to do a config action like this:

config:
  actions:
    user.role.super_editor:
      grantMultiBundlePermissions:
        entity_type: node
        permissions:
          - 'edit any %bundle content'
          - 'revert %bundle revisions'

Looks like we added so many needs/use cases that that warrants at least expanding this issue summary and potentially converting this to a meta/plan issue (and implementing each use case in a child issue, with cross-coordination in this issue)?

Adding some example use cases to the issue summary.

Fixing an HTML error in the issue summary.

Distilled my thoughts on the patterns we're seeing emerge here.

Self-assigning to update the issue summary.

Adding #3422821: Add a mechanism for plugins that underlie config entities to expose config actions → to the issue summary.

All child and related issues have been completed. Thanks for all the work on this!

Automatically closed - issue fixed for 2 weeks with no activity.