The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
"administer nodes" should be broken up. See #3418353: Add new permission for rebuild permissions form and #214190: Add administer node published status permission
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.
From @berdir in #3418353-32: Add new permission for rebuild permissions form
Proposed resolution
Replace "administer nodes" permission and deprecate it.
Comments
Comment #2
berdirI think introducing new permissions for all current checks is fairly straightforward, with an update function that adds the permission to all roles with the current administer nodes.
The tricky is bit is then the actual deprecation of that permission. Are we going to trigger a deprecation on hasPermission() calls with that? We might need to hardcode that, while we could add something to permissions.yml, we do not check that at runtime and we don't cache it, so that would be very slow.
Because there will likely be calls to it in contrib and custom code, so if we just remove the permission from the roles, things are going to break, so we can maybe only do this once you update to D13 or whatever.
Also, extra fun bits such as \Drupal\node\Hook\NodeViewsHooks::viewsQuerySubstitutions(), how do we deprecate that? the placeholders are all defined in advance before we know it's used or not. And that would trigger a deprecation on hasPermission()
Comment #3
alexpottComment #5
joachim commentedAdding more granular permissions is good, but we still need a main admin permission -- entity types should declare an `admin_permission` in their definition and node currently doesn't -- see #3575497: node entity type doesn't declare its admin_permission.