RuntimeException: Adding non-existent permissions to a role is not allowed

This is a support request with steps to reproduce. Are you reporting a bug?

Frankly I am not sure that it is a bug or wether I did something wrong. Should I change it to a big report instead?

At some time Drupal’s PHP module was involved in this process but I don’t see it in the reproduction steps.

There is no additional PHP module installed.
It appears to be a permissions issue after migrating from Drupal 7 to Drupal 10
Not sure what to do about it.

The php_code text format originates from the PHP module, which is why I said that.

Did a fresh install. Sogar it is working. Must be an issue with permission migration.

It appears to be a permissions issue after migrating from Drupal 7 to Drupal 10

With 100% certainty, this is the root cause. core/modules/user/migrations/d7_user_role.yml migrates permissions with bypass: true, so any unmapped permission is migrated as-is, even if it's not valid.

This is entirely unrelated to CKEditor 5 😊

Currently dealing with this issue for a site that's not based on D7 migration.

I used config-import for my base install, which included permissions that don't exist because the modules that provide them are not enabled.

Now I can't save the user permissions form.

Seems like the form should not be trying to save permissions that weren't specified on the form?
And also that config-import shouldn't allow import of permissions that don't exist?

Reassigning to user module, since I don't think this is limited to migration.

We may let drupal automatically remove such "non-existent permissions" during role save.

We may let drupal automatically remove such "non-existent permissions" during role save.

I think this would be wrong.

Imagine the following scenario:
- A module dynamically provides a permission depending on an external condition or a config value.
- The external condition or config value is temporarily changed.
- The role is saved, the permission is lost.
- The external condition or config goes back to its original state.
- The permission is no longer on the role!

Not good.

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.

Imagine the following scenario:
- A module dynamically provides a permission depending on an external condition or a config value.
- The external condition or config value is temporarily changed.
- The role is saved, the permission is lost.
- The external condition or config goes back to its original state.
- The permission is no longer on the role!

I don't think this is a problem, and in fact this is how config works everywhere.

Yes, Permissions can have dependencies on config and states.
Yes, if a dependent state or config changes, permissions can also change.
If a module provides dynamic permissions, then it's up to the module to make that clear by communicating the changes; and it's up to the administrator to be cognizant of how config and state changes can impact permissions.

This is how every module interacts with the config system, and Permissions should not be an exception.

Under the proposed scenario, it's not enough just to uninstall a module.
Now I also have to go and revoke all the permissions provided by that module?
After I delete a content type, I also have to revoke permissions for that content type?
It's too much.

For the original report (in the issue summary):

I agree with Comments #5 through #8. Something went wrong when migrating permissions. If you migrated to Drupal 9 and then upgraded to Drupal 10, then the invalid permissions should have been deleted in the D10 upgrade: there is an update function for that. If you migrated directly to D10, then the invalid permissions should never have been added.

When I say "should have", I allow for the possibility that there is a bug.

The relevant change records are

• Permissions must exist →
• Migrate only permissions that exist on the destination →

I do not see a comment from @creact since last May, so I assume things are working as expected. I am considering closing this issue as "works as designed".

By the way, the steps to reproduce in the issue summary are not enough from a fresh install of Drupal.

Comments #9 through #13 are not directly related to the initial purpose of this issue.

I am moving the issue back to the queue for the migration system. In order to control issue scope, please open a new issue for the User module if you want to follow up on those comments.

From #9:

I used config-import for my base install, which included permissions that don't exist because the modules that provide them are not enabled.

When I import configuration, I include core.extension, which manages the installed modules (and themes). I have never had a problem with enabling permissions that are not defined by enabled modules. The config dependencies should guarantee that the user.role.* configuration depends on the modules and other configuration that provide the permissions.

Again, I used the word "should". If a contrib module provides permissions, then it should specify the dependencies of those permissions (if any). If it does not, then things can go wrong. See the first change record in my previous comment.

Also from #9:

1. Seems like the form should not be trying to save permissions that weren't specified on the form?
2. And also that config-import shouldn't allow import of permissions that don't exist?

(1) is a reasonable request. The Permission form lists only valid permissions (provided by some module). If you somehow get into a state where a role has invalid permissions, then maybe submitting the form should fix that for you instead of giving a WSOD.

I think (2) is worth considering, but less likely to happen. As I said above, you should not run into trouble if your config import includes core.extension.

If you want to advocate for either of these changes, then first look for existing issues. If there are none, then create one (or two). You are much more likely to get an issue done if the issue description matches the discussion and patches/MRs on the issue.

From #13:

This is how every module interacts with the config system, and Permissions should not be an exception.

Permissions are not config, but user roles are. This complicates the dependencies, and it was debated on #2953111: Only migrate role permissions that exist on the destination → .

Reasonable conclusions here, thanks.

I haven't run into this in a while, but I'll start a new thread elsewhere if I do.

Just noting here that patch #11 worked well for me. I looked at the fatal error with the listed permissions and confirmed they're no longer relevant to my site, so I just wanted them gone so I can move on. The error blocked me from performing database updates or changing text format configuration, and there's no other solution listed here (not sure about 3375860 🐛 "Adding non-existent permissions to a role is not allowed." exception is thrown for profile installations Needs work ).

A patch that more carefully considers implications and possibilities would be nice, but I think #11 is good to add temporarily for getting past the issue, and then removing the patch just in case.

Just adding my two cents..
Encountered this error during a D10 upgrade, the error appeared whilst doing a drush cim

Solution for me was to navigate to the admin/people/permissions form, save, then rerun drush cim. This got me past the error assuming as the submit function cleared out those redundant/removed roles.

Encountered this error during a D10 upgrade, the error appeared whilst doing a drush cim

If you manage site configuration using drush cex and drush cim, then it is important to capture any config changes from update functions. The process I use is

1. Install a local copy of the site with the same code and database as the live site.
2. drush cim (especially if using the config_split module).
3. Update the code.
4. drush updatedb
5. drush cex
6. Commit any config changes to my Git repository.

When upgrading to Drupal 10, Step 4 should remove any invalid permissions. If you skip Steps 5 and 6, then any later drush cim will bring them back.

Solution for me was to navigate to the admin/people/permissions form, save, then rerun drush cim.

I do not think that will work. I think there were additional steps that you are overlooking.

I have experimented this error on text formats config update manually, not on drush cim or drush updatedb, and #11 fixed it.

Solution for me was to navigate to the admin/people/permissions form, save, then rerun drush cim.

For me it returned the same error as I had in text formats form, previously to apply #11 patch.

Upgrading from D9 to D10 I was able to solve this issue by using single config import via the UI.

/admin/config/development/configuration/single/import

Selecting config type Role.

Paste in an edited version of user.role.anonymous.yml and user.role.authenticated.yml.

I had this issue in 10.2.1 - seems to be fixed by patch in #11

My zombie permissions were:

RuntimeException: Adding non-existent permissions to a role is not allowed. 
The incorrect permissions are "configure all page node layout overrides", "configure editable page node layout overrides". in Drupal\user\Entity\Role->calculateDependencies() (line 207 of /web/core/modules/user/src/Entity/Role.php).

I hit this issue too. I had uninstalled some aqcuia lighting modules and entity browser. The permissions never got removed during the uninstall and after that I'd hit this error when trying to save permisions or unintall other modules.

I tried to manually remove the permissions from the roles config.yml. This solved the issue locally but on config import on a test eviro, the modules were deleted before the updated permissions imported and I hit this error again.

Looks like patch in #11 fixed the issue.

Just to let know who ever works on this:
I did a clean install of D10.2.2 + Commerce
In Commerce I tested several ideas and later removed these product types.
Now I get this error every time I change (any) permissions on any user:

RuntimeException: Adding non-existent permissions to a role is not allowed. The incorrect permissions are "create default commerce_product", "create test_goods commerce_product", "delete any default commerce_product", "delete any test_goods commerce_product", "delete own default commerce_product", "delete own test_goods commerce_product", "update any default commerce_product", "update any test_goods commerce_product", "update own default commerce_product", "update own test_goods commerce_product", "view default commerce_product", "view test_goods commerce_product". in Drupal\user\Entity\Role->calculateDependencies() (line 207 of [site]/web/core/modules/user/src/Entity/Role.php).

Just googling for "Drupal RuntimeException: Adding non-existent permissions to a role is not allowed." yields plenty of such issues, reported with various modules while the problem appears to be in core.

However, the set permissions are stored to the role, so I assume the rruntime error occurs after sving permissions (still on 10.2.2, not 11-dev).

I just ran into this error again. In case others find this, I've been successfully using this drush script to remove invalid permissions without patching core:
https://www.drupal.org/node/3193348#comment-14969643 →

10.2.4 - Patch #11 Fixed it

10.2.5 - Patch #11 Fixed it

Sorry but this is not only related to migrations. While building a fresh site, I created a Content moderation workflow state & transition, set up permissions on it, then deleted the transition & state, and now I can't save the /admin/people/permissions form anymore, with this error on the latest Drupal 10.3.x-dev:
(basically the related workflow transition were somehow not deleted even if they are not visible in the UI):

RuntimeException: Adding non-existent permissions to a role is not allowed. The incorrect permissions are "use rfp transition schedule". in Drupal\user\Entity\Role->calculateDependencies() (line 207 of core/modules/user/src/Entity/Role.php).
Drupal\Core\Config\Entity\ConfigEntityBase->preSave(Object) (Line: 179)
Drupal\user\Entity\Role->preSave(Object) (Line: 528)
Drupal\Core\Entity\EntityStorageBase->doPreSave(Object) (Line: 483)
Drupal\Core\Entity\EntityStorageBase->save(Object) (Line: 257)
Drupal\Core\Config\Entity\ConfigEntityStorage->save(Object) (Line: 354)
Drupal\Core\Entity\EntityBase->save() (Line: 609)
Drupal\Core\Config\Entity\ConfigEntityBase->save() (Line: 1010)
user_role_grant_permissions('delegate', Array) (Line: 984)
user_role_change_permissions('delegate', Array) (Line: 257)
Drupal\user\Form\UserPermissionsForm->submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 129)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 67)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 597)
Drupal\Core\Form\FormBuilder->processForm('user_admin_permissions', Array, Object) (Line: 326)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 637)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 53)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 736)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

10.2.5 - Patch #11 Fixed it for me. Thanks!

hi
i was also having this issue with permission related to devel module.
Patch #11 also worked for me on 10.2.5 + php.8.2

Thanks

I've been seeing the same error having created, altered and deleted some transitions on a fresh 10.2 site. The patch at #11 allowed permissions to be updated without the error. Thank you for the patch

#11 worked for me, thanks very much!

#11 worked for me as well on Drupal 10.2.6 and PHP 8.2, thanks very much!

#11 also worked for me. Fairly fresh install of Drupal 10.2.6. Issue came up when I installed Field Permissions, but the site had been a little glitchy with roles even before I installed Field Permissions (I was just in denial about it). The permissions that it was fussing over seemed to be related to Civicrm Event (though I had disabled Civicrm Event).

Thank you for the fix!!

#11 worked perfectly, but since we are revoking the permission which is not valid, it would be handy if those permissions are displayed as logs. I have modified patch #11 and added the code that logs the invalid permissions before revoking them.

I like the logging added at #36.

I can't see any reason why this shouldn't be RTBC. Enough users have found the earlier patch at #11 to be beneficial and have not flagged up any problems.

The Needs Review Queue Bot → tested this issue.

While you are making the above changes, we recommend that you convert this patch to a merge request → . Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)