Add optional permission patching to config provider plugins

Open on Drupal.org →

Created on 26 March 2025, 29 days ago

Problem/Motivation

As of Drupal 9.3, core validates permissions during configuration import and installation. If a permission references a module that is not yet enabled—or if its dependencies are not satisfied—it is considered invalid and removed from the role configuration.

This causes problems for install profiles and distributions that define user roles with permissions from modules expected to be enabled later. These permissions are stripped during install, even if the modules are enabled in the same batch or later in the process.

See [#3193348]

Steps to reproduce

Create a user role configuration in a profile that includes permissions from a module that is not yet installed.
Install the site using that profile.
Enable the module that provides the missing permissions.
Observe that the role configuration remains incomplete — the permissions were never applied.

Proposed resolution

Add optional support in the config_provider plugin system to "patch" roles with valid permissions after all modules are installed.

Introduce a plugin definition flag supports_permission_patching (default FALSE).
If enabled, the plugin will:
- Use the user.permissions service to get all defined permissions.
- Iterate over existing role config (user.role.*) in the active config storage.
- Add any newly-available permissions that are valid and expected based on profile or provider storage.
- Rebuild the dependencies key for affected role configs.

Remaining tasks

Add supports_permission_patching to the plugin annotation class and document it.
Add role patching logic to ConfigProviderBase or a helper trait.
Add tests covering the permission patching flow.
Document the expected behavior in the README or plugin docs.

User interface changes

None.

Introduced terminology

Permission patching: Post-install correction of role config based on newly available permission definitions.

API changes

New optional plugin flag: supports_permission_patching
New internal method or trait to apply permission patching during config processing

Data model changes

None.

Release notes snippet

Config Provider plugins can now opt in to patching user role permissions after module install. This allows install profiles and distributions to safely define roles with permissions from modules that may not be installed at the time the role is created. Enable this feature by setting supports_permission_patching = TRUE in your config provider plugin annotation.

✨ Feature request

Status

Active

Version

3.0

Component

Code

Created by

🇺🇸United States trackleft2 Tucson, AZ 🇺🇸

Live updates comments and jobs are added and updated live.

Sign in to follow issues

Comments & Activities

Issue created by @trackleft2
Comment 29 days ago →
🇺🇸United States trackleft2 Tucson, AZ 🇺🇸
Comment 13 days ago →
🇨🇦Canada nedjo
Probably we should be doing this through core's config action API.

The old way of adding permissions dynamically with Configuration Synchronizer support was through the Config Actions Provider → module, which depends on the Config Actions → module. A sample usage is in the Drutopia Article module, which adds several permissions to an existing role.

However, the Config Actions module is deprecated for Drupal 11 with the note on the project page:

Please convert your config actions into the new Recipe system included in Core. No upgrade path from the config_actions modules into Recipes is planned.

The way to do config altering now is via the new config actions support rolled out as part of the core Recipes initiative. (Despite having the same name, these config actions are a completely different implementation than the Config Actions module.) See the developer documentation on core's config actions for details. Recipes that ship with core include config actions adding permissions to a role. An example is the basic_html_format_editor recipe.

✨ Add support for recipe-provided config Active would be needed for recipe-provided config actions to show up in Configuration Provider.

contrib.social Blog FAQ Discussions

Production build 0.71.5 2024