Add administer node published status permission

This is a very good idea.

But... it seems more like a feature request for 7. As has been often pointed out, it is late in the day for adding new permissions in 6.

What if we did an #access property on each of those checkboxes. Then contrib could do whatever it wanted, without adding another 50,000 permissions.

haha. chalk that up to trying to write a reply just before dinner. :) please disregard.

I misread your description of the patch as you doing an if (user_access('publish nodes')) around the fieldset, rather than an #access property. I see now that you're just changing the permission the #access property checks.

It's a good idea. There's an issue somewhere to do the same thing for 'sticky' as well, although I can't find it right now.

The node permissions section is getting very long, but we should find a way to deal with that in the ui, and ideally get rid of "administer nodes" entirely since it mainly causes confusion.

I think this is just one more symptom of the need for a more comprehensive user access system. See this feature request for one idea.

As it is, can that patch submitted above be used in D5 or D6? I am not a developer but desparately in need of something like this for a project I'm working on... I can't give users of a certain role Administer Nodes permissions because then they have too much control, but they need to be able to access Unpublished nodes of one nodetype in order to do their job. Unless someone has another idea as to how I might accomplish that? I think the idea behind this patch is a great one and I look forward to seeing it develop into more of a feature in D7

Using Views to get a list of the unpublished nodes is not the issue though... Allowing someone other than the creator of that node to even see it, let alone edit, review, and publish it is the issue. Even if the person (not creator) trying to view this node has permissions to view, edit, and edit own nodetype, they still can't. Thanks for putting up this patch jgoldberg!

jacob: if you create a view that doesn't filter by whether a post is published or not (or only shows unpublished nodes) - then any user will be able to read them from the view since it bypasses the access restriction completely - just make it a "full node" view so they can read the whole thing.

@catch :

i need to be able to edit the nodes, not just view them. there are very detailed solutions such as nodeaccess or taxonomy access control that will bypass the core access structure. i dont need that level of granularity... just a per nodetype administrative access to view edit and publish unpublished nodes.
thanks for the help!

I installed the patch and it didn't really do anything useful aside from creating an "administer nodes" permission that wasn't called that. Same thing, different name. http://drupal.org/project/publishcontent is a project I've created after hacking around core a bit and deciding that I need to make it a module, not hack core (bad practice). This module, once completed (working on transferring hack to module now and should be out in a week or two) will give another level of permission of "publish content" for each nodetype in the system, in addition to the create, edit, and edit own permissions. This allows a role to view, edit, and publish unpublished nodes of each nodetype selected. First version will be 5.x with 6.x coming out shortly after. I will also propose that this become a part of core in 7.x as per the wish list presented in Dries' State of Drupal address at the beginning of Drupalcon this year.

Putting this back to active, since it looks like the module will be turned into a patch later.

Will need reroll with the permission description.

Where can we get this one: http://drupal.org/project/publishcontent ?

We really need this module in this scenario:
We have several installations. Some posts are transfered from one system to others with feedAPI. On the receiving platform, the authors should not edit the posts, put unpublish them.
So, this module is really a fantastic idea!
DG, maximago.de

This project sounds interesting. I would like to use "publishcontent" on my Drupal 6 installation. So what is the status of this project?

This patch just changes the option for all publishing options to a new permission.

The following patch (against drupal 6.2) gives more granular control (only over publishing items - as this is all I needed to add permissions for)

#282122: D7UX: "Save draft" and "Publish" buttons on node forms is (kind of) dependent on this patch.

Mez: If you want your patch to be considered, you must submit it against D7. Features are not added to the stable version.

Subscribing (and bumping)... I've been wondering lately about the fact that as of D6 we have granular "delete" permissions in Drupal but not granular "publish/unpublish" permissions. It seems like the latter would often be more useful.

Subscribing.

subscribing

This sounds useful, but too late for Drupal 7.

I need this as well!

subscribing

Subscribing - also would like this functionality

Yes, we need this.

subscribing - it would be great to see this in core.

I have found the Publish Content (http://drupal.org/project/publishcontent) module in D6 that allows:

"publish *all* content": you can publish any node
"publish 'nodetype' content": you can publish any node whose type is 'nodetype'
"unpublish *all* content": you can unpublish any node
"publish 'nodetype' content": you can publish any node whose type is 'nodetype'

If someone could kindly port it to Drupal 7 then it would allow this functionality until it is implemented in D8?

#22: publish_own.diff queued for re-testing.

Subscribing....

This feature wont be available in D7???

In most projects, i need the users to be able to publish/unpublish a content, this means giving "administer nodes" permission.
Not only this gives node options that the user doesnt need and even doesnt understand (revisions, menu settings, authoring etc...), but sometimes, when some users should only manage their own content, they have full access to all nodes.

I think this feature should be included in Drupal core as soon as possible, so we wont need to find solutions with extra modules or custom code for each project configuration. This is always a tricky issue to resolve!

Subscribing!

I dont understand why this wasnt fixed in D7 itself. Need to have this in D8 surely.

Is it possible to get this small patch in D7?

Subscribe

Subscribe...

Subscribe

The reason this wasn't fixed in D7 is that not enough people worked on reviewing and testing it to get it in. It doesn't happen by magic.

This also isn't a major issue - especially when the feature is easy to add via a contrib module.

Anyway, here is a reroll of the patch for Drupal 8.

It sounds like we actually have two options being discussed here: a single "publish nodes" permission (i.e., the original patch in this issue), or a granular set of permissions ("publish own X content", "publish any X content").

I think the second makes a lot of sense, especially since we have granular delete permissions already, and the use case of, e.g., allowing someone to unpublish forum posts but not allowing them to unpublish very important things like the front page of the website is a strong one (though at least in the core interface you can only unpublish things you're also able to edit, so that use case is partially met regardless). However, adding 'publish' as a major option to the core node access system (on the level of the existing CRUD permissions) kind of seems like a big step, especially because there are a lot of people who find the core published/unpublished flag too limiting and want to completely ignore or bypass it.

So for now, I went with a reroll of the simpler, original patch from #21. I added a D7->D8 update function, and also made it so the permission only allows you to control the published status; having it also allow you to control "sticky" and "promoted to front page" just seemed too weird to me (and perhaps I'm anticipating #1123696: Does 'Save' publish my content? which will hopefully break up the publishing options fieldset so the published status is configured separately from those other settings).

tagging

I tried to run the patch in #43 but the file structure of drupal 8 has changed.

Here is the error message outut I am getting:

theamoeba@~/development/drupal8> git apply -v publish-nodes-214190-43.patch
Checking patch modules/node/node.install...
error: modules/node/node.install: No such file or directory
Checking patch modules/node/node.js...
error: modules/node/node.js: No such file or directory
Checking patch modules/node/node.module...
error: modules/node/node.module: No such file or directory
Checking patch modules/node/node.pages.inc...
error: modules/node/node.pages.inc: No such file or directory
Checking patch modules/node/node.test...
error: modules/node/node.test: No such file or directory
Checking patch modules/translation/translation.test...
error: modules/translation/translation.test: No such file or directory
Checking patch modules/trigger/trigger.test...
error: modules/trigger/trigger.test: No such file or directory

I have altered the patch and it applies just fine. The new permission seems to work as well.

I forgot to attach the altered patch in #45.

I have tested the patch and everything is working. I do not see the publish to front page toggle though. The user can now publish and unpublish content.

The new permission:

The option on the node add and edit page:

Please consider creating a defaultAccess() implementation for the base field "status" of node, if you want to create such a new permission. (Issue #2098355: Missing default access for all node fields).

I would love to see these permissions in d8 core.
I would also split the "(un)publish 'nodetype' content" permissions into "(un)publish own 'nodetype' content" and "(un)publish any 'nodetype' content".

Also see https://www.drupal.org/project/override_node_options

This would still be a great feature to add to Drupal 8. Thanks @axel.rutz for sharing the Override Node Options module as an alternative solution.

bump :) Override node options saved the day... but it would be great if core would not handle this "administrative fields" as special ones and it would provide a way to grant access to those with granular permissions.

Right now this issue is so outdated that it is hard for me to see if this is asking for the functionality of the administer content permission. But it does seem like that. (also see https://www.drupal.org/project/drupal/issues/2842960).

This would mean that either this issue is outdated and can be closed. Or this still needs steps to separate the separate permissions. Meaning you can toggle publication separately from other options like promote to front page.

For anyone looking to allow the publication of pages for specific roles the 'administer content' permission seems to be the way to go.

The point of this issue is to have a dedicated permission just for that. administer content also allows to change the author, promote/sticky flags and other things that you might not want to allow.

Is this still something that core needs to support? We have 2 well maintained modules mentioned here https://www.drupal.org/project/override_node_options and https://www.drupal.org/project/publishcontent

Core also provides content moderation for much finer control over publishing workflows and permissions.

IMHO, yes, this is something core should do. Reading the comments, we've got "yes this is a good idea" from all sorts of folks who are either past or current release managers, product managers, etc. It's fairly absurd that we have granular permissions for delete, but not publish/unpublish. Yes, content moderation provides more advanced publishing workflows. But for something so fundamental to a content management system as publish status, I think core needs to solve this.

Just marked #2798601: Add dedicated permission for toggling content published status duplicate with this, which had 35 followers.
I imagine there are other duplicates lurking in the issue queue for this.
This is a very common need. Further evidence core should provide this out of the box.

Thanks!
-Derek

@dww no worries! Lots of these very old issues have those types of comments that have since gone stale so I'm asking the question as of 2025 with all our new tools :)

Ready for a review, happy to change any of the text around the permission (name/description)

Left a suggestion for a title/description update.

But what would the workflow be if you have access to edit a node but can't change the status? Would it just resave the current status?

If you are another contributor eager to jump in, please allow the previous poster(s) at least 48 hours to respond to feedback first, so they have the opportunity to finish what they started!

But what would the workflow be if you have access to edit a node but can't change the status? Would it just resave the current status?

It would be the exact same as it currently is for a user without administer nodes (stays in the same status).

Ready to go now

Won't this need an upgrade path

@smustgrave no because we aren't changing existing functionality, just adding the ability for users to be granted a new permission to change the status.

I see then everything seems to be working as expected.
Tested with the editor role from the standard install.

Think all feedback has been addressed

Couple of questions:

1. Do we refer to this field as 'status' anywhere else in the UI or is it always 'Published/Unpublished' - or to put it differently, should the the permission be something like 'administer node published status'.

2. Is there any desire to add this as a generic permission for all entities? I guess we're pretty far from being able to do that.

3. Is there any consideration for content_moderation or workspaces module where workflow changes can result in an entity being published? I think the answer to this is probably no, because they already do what they do with their own permissions, but just in case.

1. I don't think so via the UI, I'm not fussed if we want to change it
2. That'd be nice, but then we have BC concerns as we'd have to implement a generic field access hook for anything with a status key, etc.
3. CM hides the status field, I'm not sure about workspaces.

Can chalk this up to site configuration but I tested this on a project today. The content type has published default to checked. I applied this patch so that certain editors can't publish the page, but since the default is published it still saved as such. All the editor can't do now is unpublish it.

As a Drupal core product manager, I agree this would be a generally good feature to have. 'Administer node published status' sounds like a better name indeed.

Let's go for 'administer node published status' given #86.

Adding #3160748: Support "View any unpublished [entity_type]" and "Administer [entity_type]" permissions as related, which itself has a bunch of related issues that are relevant here.

Feedback appears to be addressed for this one.

I scanned the comments and didn't find any unanswered questions or remaining work. I read the MR and left a suggestion to improve a message. I also updated credit.

Back to RTBC

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

@needs-review-queue-bot you are wrong!

I discussed this issue with @berdir and we agreed that leaving the "administer nodes" permission as an OR is a good thing here because

I didn't really look at the code in the status issue yet, but I think one important difference between those two issues is their impact. one is a route permission on a rarely used form, that's going to be very rarely customized/integrated/tested/... the other is field access on node status. tons of tests, default config and other things are going to be impacted by it, so not dropping the administer nodes permission yet I think is a good thing

We were thinking about the differences in approach between this issue and #3418353: Add new permission for rebuild permissions form

I creditted @ifrik and @sidgrafix from the duplicate issue #2798601: Add dedicated permission for toggling content published status

Committed 54e0120 and pushed to 11.x. Thanks!

Great to see this get in, thank you! Update the permission name in the CR and IS.