PermissionsForm should not use overridden permissions

Thanks for raising this!

Some steps to reproduce would be helpful here. Also, do we need an update/post update hook to clean up possible improperly stored values?

Patch from #2 doesn't work if the overridden permissions are hidden from display based on the chosen filters, the config still gets polluted with the hidden overriden values on save.

Will have to dig deeper, I'll probably take another whack at it this week.

Thanks for the update. Setting to NW.

Added a hidden_permissions form element with an array value for all hidden permission values, and extended submitForm() to merge these with the submitted values and save all permissions.

Also updated issue summary.

I'm not sure an update hook is needed, it might in fact muddy waters depending on use cases.

Something to keep an eye on: there's work being done for Drupal core 11.x to address the general issue of saving overridden config entities - https://www.drupal.org/project/drupal/issues/2910353 🐛 Prevent saving config entities when configuration overrides are applied Needs work

Thanks for the work on this. Target should be 2.0.x branch with merge request instead please. Thanks!

Does this problem exist for the permissions page with our without the Filter Permissions module?

I can't tell if the originally reported issue is mostly overlapping with the use case for having a module like https://www.drupal.org/project/config_override_warn → to give site builders an idea of which field values might not be displayed or saved as expected due to being overridden somewhere like settings.php. Along with the patch in https://www.drupal.org/project/config_override_warn/issues/3275425 ✨ Warn when permissions are overridden Needs review , perhaps that would be a solution to the originally reported issue.