Installation of Drupal fails when having dynamic permissions based on a config entity added during installation

I added test coverage in the MR that will fail and reproduces the bug.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Namespace appears to be off.

Seems failure in MR is legit to issue. Seems to be a permission problem.

@JeroenT do I understand correctly that the merge request triggers the bug but does not fix it?

@Liam Morland, Yes. The MR contains a test that triggers the bug.
I haven't found a fix for it, yet.

This seems to be a general problem with left-over permissions on existing roles.

My comment from the other issue 🐛 RuntimeException: Adding non-existent permissions to a role is not allowed Active :

Here is what I propose instead:
On the "Manage permissions" form, left-over permissions are displayed in a dedicated section.
The admin / site builder can uncheck the permissions that no longer exist, or they can leave them in place.

Any other time when a role is saved outside of the permissions form, orphan permissions are just silently left unchanged.

Steps to reproduce:

1. Edit block.permissions.yml (or any other module permissions file). Add tmp perm: {title: 'Temporary permission'}.
   (by using block module, the permission will show up at the top of the permissions form)
2. Visit "admin/people/permissions". Assign the tmp perm to "Content editor" role (or any other role). Save the form.
3. Remove the "tmp perm" from block.permissions.yml.
4. Visit "admin/people/permissions". Save the form.

Result:
RuntimeException: Adding non-existent permissions to a role is not allowed. The incorrect permissions are "tmp perm". in Drupal\user\Entity\Role->calculateDependencies() (line 207 of core/modules/user/src/Entity/Role.php).

Also any other process that saves a role with orphan permissions causes this.

This error message was introduced in
#2571235: [regression] Roles should depend on objects that are building the granted permissions →
https://git.drupalcode.org/project/drupal/-/commit/cffb02aad63664e7930a3...

It was converted to a runtime exception in
#3261248: Remove deprecated user.module functions →
https://git.drupalcode.org/project/drupal/-/commit/dcc51c80a2ee2a26dd397...

One problem if we want to keep orphan permissions is that we cannot calculate their dependencies.

Workaround, if we ever encounter this error in a Drupal project:

Declare the bad permission in one of the *.permissions.yml files, visit admin/people/permissions to unset it from all roles, then remove the declaration again.

I don't think that's the same issue. The pemission UI should catch and handle that exception.

The actual issue here is pretty much by design, it's a chicken/egg situation with a permission that has a config dependency on itself aka the role. It can't be fixed without bypassing the strict permission validation that we have now, but the workaround is fairly easy: Add the permission in a second step after install/config import.

That is not a great work-around because config export will export the config and then import will import it. This will trigger this issue during functional tests.

I'm not saying it's great, but there's nothing else.

This is _only_ about a dependency on the role being created right now. A dependency on any other config entity works fine as long as you ensure that the config dependency is there and that config is imported first.