Starting with Drupal 9.3.0, all permissions in a user role must be defined in a module.permissions.yml file or a permissions callback. Other permissions are now considered invalid. This includes permissions from uninstalled modules, permissions that depend on configuration that has been removed (such as a content type), and permissions of obscure origin.
In Drupal 9.3.0 or later, saving a role with an invalid permission will trigger a E_USER_DEPRECATED error. In Drupal 10, it will throw a runtime exception. (see
https://www.drupal.org/node/3193348 →
)
Impact
As we have quite some permissions to fix, this would result in Runtime Exceptions.
We are not going to be able to solve them before the D10 deadline, so we need to find a way around this.
1. Revert the RuntimeException in Core in a Open Social patch and trigger the original error. This allows us to still identify the issues.
2. Plan and Fix all individual permissions one by one correctly.
3. Re-revert the patch from point 1, to ensure we have correct permissions.
1. Revert the RuntimeException in Core in a Open Social patch and trigger the original error. This allows us to still identify the issues.
2. Plan and Fix all individual permissions one by one correctly.
3. Re-revert the patch from point 1, to ensure we have correct permissions.
Active
12.0
Code (back-end)
This has been fixed with Drupal 10.4.
if (!empty($invalid_permissions)) {
\Drupal::logger('user')->error('Non-existent permission(s) assigned to role "@label" (@id) were removed. Invalid permission(s): @permissions.', [
'@label' => $this->label(),
'@id' => $this->id(),
'@permissions' => implode(', ', $invalid_permissions),
]);
$this->permissions = $valid_permissions;
}