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.)

I think the message added by the logger is confusing. I ran into this issue when trying to deploy updates to a site. Somehow a couple of roles had permissions left that no longer existed. (Workflow permissions from a content type that was removed). The updates were trying to add new permissions that did exist to the role, but the extant permissions were triggering this error.

In my case, silently removing the permissions that no longer exist is what I'd like to happen. The decision to remove those permissions has already been made. The fact that they're still assigned to a role is an error, and one that we can easily correct for people. Logging an error saying "Adding non-existent permissions to a role is not allowed." is confusing, as nothing was trying to add non-existent permissions.

I've gone with patch #11 and it's worked well for me.

+1 for patch 11 and @rupertj 100% agree with you

The decision to remove those permissions has already been made. The fact that they're still assigned to a role is an error

+1 for patch #36. Very useful, thank you.

patch #11 working here too!

Odai Atieh → made their first commit to this issue’s fork.

I used patch from #36 succesfully.

There are scripts, including the module https://www.drupal.org/project/rip → , but since these errors result in a WSOD I think it is preferabe to have an automated Core solution for it.

Let's check the approach (automated removal vs. manual drush command) and the log message at a UX meeting.

For the record, I have this issue, in my case with permissions left behind by the Forums module, which I have uninstalled. As with others, patch in #11/#36 works for me. I second the motion for an automated solution in core.

As I said in Comment #15, this issue is a bug report for the migration subsystem (the Migrate API). Not all bug reports are valid.

In order to control scope, please open a new issue if you would like to propose a change to the user module, even if the idea for that change started in the comments on this issue.

I opened a new issue 🐛 Faulty configuration results in WSOD saving permissions Needs review against the user module

@simohell, thanks for opening #3464893. We can continue the discussion over there. I have already added credit there for some of the more helpful comments on this issue.

Again, this issue is originally about the behavior of the Migrate API. I am closing it: works as designed.

The patch in #11 worked for me.

I had removed a menu, and apparently having the permission to manage that menu was not removed from the system.

Adding additional features and defining the permissions for them, caused this error, preventing the save of additional permissions.

The patch fixed it, allowing the permission change to be made, and config export cleared up the orphaned permission.

I just removed an entity browser and now I can't delete content anymore of uninstall entity_browser.
I'm not seeing how this is a migration sub system issue, it seems like a bug in Core but I'm sure I'm missing something :)

Patch #36 came to the rescue (again).

Had a similar issue pop up: Upgrade manager told me that this permission was assigned to a role in a text format called php_code. There was no such text format. I created one, assigning it to the role the Upgrade Status page said had it, and saved that. Refreshed the Upgrade Status page and now there's no error.

This site was never D7. It's a fresh D9 site from scratch. Nothing brought over from the D7 site. We're working on upgrading to D10.

Hm not sure if I agree with the Status change. It would be probably better to discuss where this should be moved to (if not exist yet in other scope). No matter what the original reporter attempted to report the underlying issue I see here is that modules can break things in core which they should not be allowed to do. I doubt that this can be narrowed down to migration system only.

Adding non-existent permissions to a role is not allowed.

Is for me a very clear and explicit impasse error message which makes me ask: how can a non-existent permission be added to anything in any process? A non-existent permission should be simply ignored, removed, or at least provide options to remove them.

Related

• https://www.drupal.org/node/3193348 →
• https://drupal.stackexchange.com/questions/317456/getting-rid-of-orphan-...

@dqd it 'feels' to me like perhaps the issues is with Drupal's uninstall process. In this queue alone we've seen examples of text formats, part of core, and contributed modules. I've run into this so many times that I'm feeling a tinge of anxiety each time I uninstall something. Somehow, some way, permissions are not always removed when they should be and it feels almost random.

I've wondered if caching plays a role but I haven't been able to determine that.

There's enough background here that it will be hard to transfer to a new issue and the migrate bug was fixed elsewhere. Re-opening and moving to user.

Needs an issue summary update. I think removing the permissions, with logging, is worth looking into as an alternative to the exception. It's clear dozens of people are hitting this on runtime and the exception is supposed to prevent developer error, not put a site in a nearot unrecoverable state.

Drupal 10.3.5:
I have the same problem and #11 fixed.
It is almost a year ago. Couldn't it be implemented in the upcoming update of Drupal 10???

i confirm that #11 solves the issue. Drupal 10.3.5

This just happened to me too, Drupal 10.3.5.

I think removing modules and permissions at the same time seemd to prevent config import on production.

Patch in #11 saved my tofu!

Not had a chance to read through the discussion, but it would be good to find a way to avoid this exception preventing deployments where permissions and related modules are all being removed at the same time. Happy to help test further!

Patch #11 allowed me to fix the invalid permissions as reported by resaving the permissions form then I was able to uninstall a module that provided the invalid permissions.

Needs an issue summary update. I think removing the permissions, with logging, is worth looking into as an alternative to the exception. It's clear dozens of people are hitting this on runtime and the exception is supposed to prevent developer error, not put a site in a nearot unrecoverable state.

This makes sense to me. I think logging and removing is going to be the way to go.

Just adding another case example, I got this error again after I deleted a field that was configured to use custom field permissions (field_permissions module) and then tried to alter permissions for an unrelated flag. Once more #11 fixed the issue.

I recieved this error also but it was based on Field Permissions → trying to add field level permissions to " Entity Extra Field → . Normally Field Permissions → has a permissions form in the edit form of a field.

I was able to apply patch #11 successfully.

It took care of my issue.

I can confirm that #11 works on 10.3.9. Thanks!

I came across when I was getting site encountered and error. I got to that by installing table responsive modules, which required that I turn them on in the "/admin/config/content/formats/manage/basic_html?destination=/admin/config/content/formats."

When doing so, got the error, log reported:
Uncaught PHP Exception RuntimeException: "Adding non-existent permissions to a role is not allowed. The incorrect permissions are "view block_title on block_content", "view dynamic_token_field:node-card_link on node", "view node_title on node"." at /.../core/modules/user/src/Entity/Role.php line 210

Interestingly, the ckeditor settings were applied and tables are responsive :)

This issue made me look at the sites permissions, click save, got the same error.

The dynamic_token_field:node-card_link in the error was due to a display suite field I had deleted sometime ago. I re-added it and added to a test content the CKeditor save error when away, but the permissions error remained.

I manually applied patch #11 as other had noted. Had bit of trouble with copy/paste, so I went slow. First, I commented out the "-" line. Errors went away. Then added:

foreach ($invalid_permissions as $invalid_permission) {
$this->revokePermission($invalid_permission);
}

Everything works. I could re-delete my no longer loved ds field.

My question is how do we know the foreach is doing what we think it is doing. Removing the exception prevents the crash, but is the problem solved?

I'm not a deep drupal dev. So, not sure.

There is also another simple use-case how to run into this.

1. Install Drupal standard profile.
2. Enable translation of terms for the Tags vocabulary.
3. Go to permisions form and add translate tags taxonomy_term to at least one role
4. Go back to the vocabulary and disable translation of terms in the Tags vocabulary.
5. Go back to the permissions form and try to save it without changes.

You will get:

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

Drupal\Core\Config\Entity\ConfigEntityBase->preSave(Object) (Line: 182)
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: 614)
Drupal\Core\Config\Entity\ConfigEntityBase->save() (Line: 1010)
user_role_grant_permissions('content_editor', Array) (Line: 984)
user_role_change_permissions('content_editor', 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: 638)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 121)
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: 741)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

This seems like a very common use-case which can happen on sites and should not result in error.

Patch 11 also solved the problem for me. Thanks!

Patch #11 solved the issue for me as well.

#69 makes this critical.

Patch #36 solved my issue.

My issue was after I added a new field to a content type with permissions configuration done, then deleted it later, the field is not clean up in the system, the permission was stuck on missing fields and can't save configurations.

Hope this help anyone with the same issue.
Thank you for all the efforts.

Updated the issue summary with the simplest steps to reproduce from #69, proposed resolution and remaining tasks.

The log message text could be the following (1. what triggered the error, 2. how it was resolved automatically, 3. the scope of error) implemented in the manner of the patch from #36

\Drupal::logger('role')->error('Invalid permission detected. Revoked the following invalid permissions: "' . implode('", "', $invalid_permissions) . '".');

It should be decided if role ID and label need to be also added as recommended by @alexpott

If this gets into 11.2 we can backport through to earlier branches, but adding the tag for additional attention.