Given the need of the Node Access Rebuild Progressive module existing, you might not want any users with access to content editing all node content (e.g. normal mid-level content users), to be able to trigger a rebuild and potentially take the site content offline or in inconsistent state whilst its rebuilding.
So would rather have that left for a user with a higher administrative or more specific permission.
Restrict access to users with a more granular rebuild node access permissions permission rather than administer nodes.
In the user interface it is called "Rebuild content access permissions".
Provide issue fork/patch.
N/A
A new rebuild node access permissions permission has now been introduced to handle who may trigger site rebuilds.
| Comment | File | Size | Author |
|---|
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
codebymikey commentedComment #3
codebymikey commentedAttached a patch supporting Drupal 10.0.x.
Comment #6
codebymikey commentedComment #8
acbramley commentedThis 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.
Comment #10
quadrexdevUpdated 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
Comment #11
smustgrave commentedI'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.
Comment #12
quadrexdevThanks 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
Comment #13
acbramley commentedCR added, I'm not sure if we also need a presave hook here for exported config in modules/profiles
Comment #14
smustgrave commentedAll feedback for this one appears to be addressed!
Comment #15
catchThe 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.
Comment #16
acbramley commentedUpdated 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
Comment #17
acbramley commentedAdded the presave hook but debugging locally and it doesn't fire during the post update...
Comment #18
acbramley commentedAfter 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 nodesand withoutrebuild 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?
Comment #19
catchI 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.
Comment #20
acbramley commentedPerfect, in that case I've reverted all the presave code.
Comment #21
ressaWorking on Setting up an environment to test merge requests 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?
Comment #22
smustgrave commentedUpdated 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.
Comment #23
benjifisherI 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 nodespermission 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 nodespermission. There is also an issue to add one of those permissions to core: #214190: Add administer node published status permission. 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.Comment #24
smustgrave commentedShould we put back into review ?
Comment #25
codebymikey commentedI think having a granular permission makes sense in this case. Mainly for the reason that the
administer nodepermission 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 nodesis 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 nodepermission, same as the currentbypass node accesspermission.Comment #26
acbramley commentedI 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.Comment #27
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #28
acbramley commentedComment #29
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #30
acbramley commentedComment #31
smustgrave commentedSeems like a good rebase.
Comment #32
berdirJust to add my thoughts, I think the long-term plan should be to completely drop administer nodes permission. It's been a very weird permission every since bypass node access and access content overviews was split off from it and it's just all kinds of random bits that are still using it. It's very confusing to understand what it actually does. The status permission is being split, the same should possibly be done for promote/sticky. And because it allows access to status/promote/sticky, you either need to use contrib projects or it is in fact actually given to mid-level content users.
Comment #33
berdirSee also other existing issues such as #2842960: Improve 'administer content' permission description and #2959611: "Revision log message" only accessible with "Administer Content" permission
Comment #34
alexpottComment #35
alexpottCommitted 09d8cb8 and pushed to 11.x. Thanks!