Faulty configuration results in WSOD saving permissions

Changes are committed to 11.x, the main development branch, and then backported according to our policies.

simohell → changed the visibility of the branch 3464893-faulty-configuration-results to hidden.

Merge request code is from @kala4ek patch in 💬 RuntimeException: Adding non-existent permissions to a role is not allowed Active and idea of adding log message from @Jaswinsingh at the same thread.

For UX review issues:
- this issue arises from fault in other modules. Is it wise to hide the errors caused by them from the user?
- there is a manual solution to the issue https://www.drupal.org/project/rip →
- which is better for the user, automatic or manual solution?
- does logging add value? should it be silent or maybe a status message?

benjifisher → credited AaronBauman → .

benjifisher → credited donquixote → .

benjifisher → credited Jaswinsingh → .

benjifisher → credited kala4ek → .

The issue summary needs a few updates, so I am adding the issue tag for that.

Steps to reproduce

At least the "todo" comment is honest. ;)

The easiest way to reproduce the problem is with config import. There are various ways to do config import: drush cim with or without the --partial option; from /admin/config/development/configuration/full/import (default "Full archive" sub-tab or the "Single item" one). I am not sure which of these can be used to cause the problem.

If a module declares permissions in a *.permissions.yml file, then those permissions will be removed from user roles when the module is uninstalled.

A module can also add permissions that depend on some config. For example, the node module creates "edit own ..." and "edit any ..." permissions for each content type. If the module neglects to declare the dependency, then those permissions might not be deleted when the config object is removed. (They will still be deleted when the module is uninstalled.)

That is what happened in 📌 Define permission dependencies Needs review . I am adding that as a related issue.

It might be worth testing #3358586-29: RuntimeException: Adding non-existent permissions to a role is not allowed → . That comment claims to have steps to reproduce the bug. If it works, then we should add credit to this issue for @kopeboy. See also #32 there: maybe there is something that needs fixing in the core workflows module.

Proposed resolution

This is subject to change, but for now let's describe what the current MR does.

"Add a check ...": when do we check? During config import, when a user role is saved, when the Permissions form is saved?

I am adding credit for some of the contributors to the other issue. I intend to close that one.

Adding block_permissions 🐛 "RuntimeException: Adding non-existent permissions to a role is not allowed." after module deinstallation Active as another example of a module that adds permissions related to other modules, but those permissions are not correctly removed when the other module is removed.

@capysara:

Thanks for mentioning that issue. I added a comment there and updated the proposed resolution in the issue summary.

One of the automated tests checks for the exception. We have to update the test now that we try to fix the problem instead of throwing an exception.

Another related issue: 🐛 D10 Changing allowed roles causes runtime exception when updating permissions Active for Administer Users by Role. It can be solved as #12/#13