## Problem/Motivation `ExportRecipe::doExport()` turns every `user.role.*` in a model's dependency closure into an `ensure_exists` plus a `grantPermissions` action, and it takes the permissions straight from the generating site: ```php if (str_starts_with($configName, 'user.role.')) { $actions[$configName] = [ 'ensure_exists' => ['label' => $config['label']], 'grantPermissions' => $config['permissions'], ]; } ``` `$config` is `$this->configStorage->read($configName)` — the live role on whatever site happens to be exporting. Nothing about it is authored by the model, and the model cannot override it. That publishes the generating site's permission set into a recipe other people apply. It has a second effect that is easy to miss: **a role declares config dependencies on whatever its permissions target**, and `getNestedDependencies()` walks those, so the permissions also drag unrelated config into the recipe. ### Measured on `drupal-eca-recipe/eca_lib_0007` The model depends on `user.role.content_editor`. On the site that had been used for exports: ``` user.role.content_editor permissions=24 dependencies.config = node.type.article | node.type.page | taxonomy.vocabulary.tags ``` The resulting export contained a 24-permission `grantPermissions` block, nine extra modules in `install` to provide those permissions, and three loose config entities written into the recipe's `config/` directory: `node.type.article.yml`, `node.type.page.yml` and `taxonomy.vocabulary.tags.yml`. None of those are anything the model declares. Had they been committed, the recipe would have created two content types and a vocabulary on every site applying it. `user.role.administrator` and `user.role.internal` are in the same closure and caused no trouble at all, because they have zero permissions and therefore zero dependencies. That is the whole mechanism in one comparison. ### A fresh site reduces this but does not fix it The obvious mitigation is to export only from a freshly installed site. Measured on a clean `drush si standard`, followed by `drush cr` — the cache rebuild matters, since reading config straight after the install returns stale values: ``` user.role.content_editor permissions=14 dependencies.config = taxonomy.vocabulary.tags ``` So a stock standard install still grants the role 14 permissions, three of which reference a bundle, and `taxonomy.vocabulary.tags` still enters the closure. Working from a fresh site makes the leak smaller and reproducible. It does not remove it, and it cannot, because the source is the live role rather than the model. ### Core models the opposite convention `core/recipes/content_editor_role` ships the role config as ```yaml permissions: { } dependencies: { } ``` and grants what it wants explicitly in its own `recipe.yml`. The role config carries no permissions, so it drags nothing behind it. ## Proposed resolution Stop deriving `grantPermissions` from live config. Emit `ensure_exists` for a role in the closure, so a recipe that references a role still creates it, and leave the permissions to the model. The mechanism for that already exists. `config_actions` landed in #3588519's sibling #3588517 and its `actions` value is `type: ignore`, so a model can already express ```yaml config_actions: - config: user.role.content_editor actions: grantPermissions: - 'access administration pages' ``` and `doExport()` already lets a model-expressed config action win over the derived one. The auto-derivation predates that key and is now both redundant and harmful: it is the only part of the recipe payload that is read from the site rather than from the model. Dropping it also removes the second symptom for free. With no permissions copied in, the role's dependencies stop entering the closure, and the loose config entities stop being written. ## Remaining tasks - Remove the `grantPermissions` derivation, keeping `ensure_exists`. - Confirm a model-declared `config_actions` entry for the same role still applies. - Cover both in `ExportRecipe` tests: a role with permissions in the closure emits no grants, and the role's own config dependencies do not reach `config/`. - Note the change for existing recipes, which will lose a `grantPermissions` block on their next export and may need to declare it via `config_actions`. ## User interface changes None. ## API changes `ExportRecipe` output changes for any model whose closure contains a role carrying permissions.