Restrict who can "Rebuild permissions" to users with the "administer site configuration" permission

Attached a patch supporting Drupal 10.0.x.

codebymikey → changed the visibility of the branch 3418353-restrict-who-can to hidden.

This would need an upgrade path to add the new permission to any role that has administer nodes so there's no access regression for existing sites. Also needs a reroll.

Updated the issue branch with changes from 11.x, added post_update hook to grant the new permission

The errors in the pipeline look to be unrelated to this issue, so I would assume MR could be reviewed now

I'm 50/50 that we should add test coverage for the update hook. We add coverage for most update hooks but this one is pretty simple.

But moving to NW as this would be a new permission to be declared.

Thanks for the feedback, @smustgrave

I added a simple test to verify that the new permission is added by the post update hook, just in case

CR added, I'm not sure if we also need a presave hook here for exported config in modules/profiles

All feedback for this one appears to be addressed!

The title doesn't match either the issue summary or the MR. Also I'm not entirely sure why that option wasn't taken - e.g. requiring both 'administer site configuration' and 'administer nodes' at the same time.

Updated title. I think a new permission is the best approach here, if we used administer site configuration we'd still need an upgrade path.

Keeping at NW because I think we do need the ConfigUpdater dance here in a presave hook

Added the presave hook but debugging locally and it doesn't fire during the post update...

After all that I'm actually unsure how we should do this. With this presave hook it's impossible now to save a role with administer nodes and without rebuild node access permissions...

Throwing a deprecation didn't feel right either because it's a valid case to have one permission without the other, but we need to be able to notify modules with exported config.

@catch any ideas?

I don't really count roles as exported config to be shipped with modules to be honest, it's pretty rare in general. So in the case I think it's fine to skip the presave. It's not like we're renaming a permission, exported roles will be validz they just might not cover this permission.

Perfect, in that case I've reverted all the presave code.

Working on https://www.drupal.org/community/contributor-guide/reference-information... → I tried the patch here, which is used as an example.

I then looked for "Rebuild node access permissions" in the user interface at /admin/people/permissions, but then realized that it is called "Rebuild content access permissions" ...

Should it perhaps be one or the other both places, for consistency?

Updated the CR for 11.3

Applied one suggestion to the MR as I saw recently there's a push to not have assertion messages.

Everything else seems fine. Update hook runs without issue.

I did not notice this issue before today, or I would have commented earlier.

I am not sure that we should add a new permission for rebuilding permissions.

First, the administer nodes permission is already marked as restricted. It should not be granted to "normal mid-level content users" (to use the phrase from the issue summary). Instead of introducing a new, restricted permission I think we should encourage site owners to be more careful about granting the existing one.

Along with https://www.drupal.org/sa-core-2025-002 → , I released the Granular Node Permissions → module. That provides permissions suitable for less-privileged roles, so that common tasks can be done without the administer nodes permission. There is also an issue to add one of those permissions to core: ✨ Publish nodes permission Postponed: needs info . The goals of the contrib module and the core issue are the same: make it easier to get work done without the restricted permission, so that site owners can be more stingy about granting it.

Should we put back into review ?

I think having a granular permission makes sense in this case. Mainly for the reason that the administer node permission is typically used in relation to regular node entity operations, and flagging that the user is allowed to make those changes to the node without needing a specific permission for the bundle or field.

My current use case is for a "site admin" role that can essentially do most of the same actions as a regular admin as far as nodes are concerned (apart from rebuilding access), such as view and edit nodes of all bundle types without needing to be explicitly granted permission every time a new one is introduced, the current administer nodes is also currently used for other functionality like views and potentially in other contrib modules, that make use of the permission, so trying to move to the contrib solution probably wouldn't work for me here.

The rebuilding node action seems like a special operation that doesn't necessarily need to be linked to administer node permission, same as the current bypass node access permission.

I agree with @codebymikey, it seems strange to want more granularity to control specific options on a node but not to detach the rebuilding of permissions from administer nodes.