Permissions should be defined in a permissions.yml file or a permission callback.

Created on 31 August 2023, 10 months ago
Updated 18 September 2023, 9 months ago

Problem/Motivation

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.

Since Drupal 8.0, modules are supposed to remove their data from the database when they are uninstalled. See Modules cannot be in a disabled state anymore β†’ , only installed and uninstalled. One exception has been that uninstalled modules did not remove the permissions they defined from user roles. Before Drupal 9.3.0, a site administrator could uninstall a module, then install it again, and the permissions previously assigned to user roles would be in effect. Starting with Drupal 9.3.0, the administrator must configure permissions again when re-installing the module.

An update function is provided to remove invalid permissions from existing roles. The update function logs the permissions removed from each role.

Source Permissions must exist β†’

Steps to reproduce

Please check https://github.com/goalgorilla/open_social/pull/3499 under "How to test" section.

Proposed resolution

- Remove deprecated permissions
- Remove granting conditional permissions on module install

Remaining tasks

User interface changes

N/A

API changes

N/A

Data model changes

N/A

πŸ“Œ Task
Status

Fixed

Version

11.10

Component

Code (back-end)

Created by

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Production build 0.69.0 2024