Publish nodes permission
jgoldberg - January 25, 2008 - 16:25
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | node system |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Description
In our instance of Drupal, we allow authenticated users to publish to the front page. The only way to give users this privilege is to give them access to the "administer nodes" permission:
$form['options'] = array(
'#type' => 'fieldset',
'#access' => user_access('administer nodes'),
'#title' => t('Publishing options'),
'#collapsible' => TRUE,
'#collapsed' => TRUE,
'#weight' => 25,
);
...However, because of the way node_access is implemented, having the "administer nodes" privilege gives you full access to all node operations, including editing other users nodes:
function node_access($op, $node, $account = NULL) {
...
if (user_access('administer nodes', $account)) {
return TRUE;
}The patch included creates a new permission, "publish nodes," which allows an admin to select which groups should be able to publish nodes, thus separating the privilege from the ability to administer nodes.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| node.patch | 1.37 KB | Ignored | None | None |
#1
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.
#2
Yeah, it should probably wait until 7. I do want to emphasize that I still think this is a defect; the ability to publish and promote should not be tied directly to the ability to edit nodes.
#3
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.
#4
Webchick, I'm not sure if I understand what are you are proposing.
#5
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.
#6
Now that a 7.x branch is open, can we reconsider this patch.
#7
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.
#8
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 can't agree more. A separate permissions section for nodes would be very nice.
#9
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.
#10
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
#11
@ jacobroufa - You might want to also check out Does an unpublished status mean Draft or Disabled? which I opened along with this ticket. In the mean time, you might want to check out the Views module; you may be able to leverage it if you are trying to pull up lists of unpublished nodes.
#12
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!
#13
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.
#14
@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!
#15
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.
#16
Putting this back to active, since it looks like the module will be turned into a patch later.
#17
@ jacobroufa: I'm not sure my patch addresses whatever problem you are having. The main purpose of it is to untie the ability to manage a node's publish status from the ability to administer nodes (edit other users' posts, for example).
#18
Will need reroll with the permission description.
#19
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
#20
This project sounds interesting. I would like to use "publishcontent" on my Drupal 6 installation. So what is the status of this project?
#21
Rerolled a patch that meets the 7.x permission guidelines.
#22
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)
#23
#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.
#24
The last submitted patch failed testing.
#25
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.
#26
Subscribing.