The attached patch extends Drupal's permission system with six additional permissions.

It adds a "view unpublished nodes" permission that enables users to view any nodes regardless of their state. The "edit any node" let's the user update any node without giving him permission to change the node's state, authoring information and access to the node administration system (i.e. node type configuration).

Additionally, the same two permissions are added to the page.module and the story.module with the respective names ("edit any story", "view unpublished stories", "edit any page", "view unpublished pages").

The general nodes permission overrides the individual settings per module.

CommentFileSizeAuthor
#21 node_permissions_4.patch3.18 KBkkaefer
#19 node_permissions_3.patch3.19 KBkkaefer
#14 node_permissions_2.patch3.12 KBkkaefer
node_permissions_1.patch2.93 KBkkaefer

Comments

moshe weitzman’s picture

moshe weitzman commented

seems reasonable to me. anyone else?

Crell’s picture

Crell commented
Status: Needs review » Needs work

I'm generally in favor of more finely grained permissions in general. However, I'm not sure if I like the "edit any node" set.

The "view unpublished nodes" permission and its kin, I like essentially as is.

However, I'm not sure if I see "edit any node" as the right way to break the permissions down. If you're trying to differentiate "edit node content" from "edit node metadata", why not break it down that way? I can see a case to allow certain classes of moderator to be able to publish/unpublish nodes, but not actually change the content. That would be the opposite of what you're doing in this patch, but there's no coverage there. I'd rather see "edit node" broken into "edit node content" and "edit node information", with "administer nodes" automatically implying both.

Does that make sense to anyone besides me? :-)

eaton’s picture

eaton commented

I think 'editing' and 'administering' are fair ways to put the distinction you're talking about. For a general user, editing a node involves altering its contents. 'Administering' involves publishing and unpublishing, altering comment statuses, deleting, etc. Referring to 'meta-data' and 'content' results in a new set of Drupal terminology that isn't used elsewhere in the system.

+1 for the patch and the permissions it proposes.

kkaefer’s picture

kkaefer commented

All together, I'd vote for a completely new permission page. I know there are serveral mockups but nothing really convinced me until now. Especially for this more fine-grained node permission system, it would be useful to show the user that a certain permission (in this case "edit any node") overrides another node (in this case "edit any page" and "edit any story"). This could be done using JavaScript to check and disable the two "child" permissions.

Crell’s picture

Crell commented

Even in the current permissions setup, having descriptions on permissions would be helpful. :-)

kkaefer’s picture

kkaefer commented

Oh yeah, descriptions for permissions are really great! Why don't I come up with such ideas... ;-)

Crell’s picture

Crell commented

hehe. Hey, I think it's a good idea, too, but no one has set that patch ready to commit. If you think it is, please do so. Otherwise the Big People(tm) won't look at it, as they're busy elsewhere.

kkaefer’s picture

kkaefer commented

Is there any chance that this will get into Drupal 4.7?

Gman’s picture

Gman commented

I am curious about this too. Currently, I can set a role so edit certain nodes, like a book page. But if the workflow sets it to 'unpublish', this person can't view the node ("Access Denied"), but they can edit it (example: node/29/edit).

So unless someone has the administer Nodes permission they can't see unpublished nodes, even if they are allowed to edit them.

I would die if this could be solved. Does the view module enable this???

Thanks

kkaefer’s picture

kkaefer commented

views.module can't solve this problem (from what I know). But this patch can. I'll try to get it into core in the next several weeks.

Steve Dondley’s picture

Steve Dondley commented

Big +1 on the view unpublished nodes permission. Just what I need.

Steve Dondley’s picture

Steve Dondley commented

Patch fails to apply with 4.7.2

kkaefer’s picture

kkaefer commented

Well, the patch is more than half a year old... Of course it doesn't apply anymore. l'll reroll a patch against current HEAD.

kkaefer’s picture

kkaefer commented
Status: Needs work » Needs review
StatusFileSize
new node_permissions_2.patch3.12 KB

Rerolled the patch. Should apply against HEAD cleanly.

Mojah’s picture

Mojah commented

Great work Timcn. Thank you.

It solved the issue I was having with unpublished user nodes. Now users can view and edit their unpublished nodes.

dries’s picture

dries commented

Node lists would show nodes you don't have access to; there is no way this permission could be used in SQL queries. The only way to fix this, is to use the query rewrite mechanism. Actually, we're moving towards eliminating the "$op == 'view'"-part of the _access hooks.

I'm tempted to mark this "won't fix".

kkaefer’s picture

kkaefer commented

Dries, I read your comment multiple times but still I don't understand what you mean. The "view unpublished nodes" permission lets a user view any content, regardless of it's published/unpublished state. "edit any node" does the same with editing the node regardless of the node's author.

As you can see from the thread, there are a lot of people who need such features. At the moment, you basically can't work with a team of authors on a site without a sophisticated node_access module (which are all quite messy). This patch is IMO the simplest and cleanest way to allow certain users to edit nodes they didn't create *without* giving them full access rights ("administer content").

pwolanin’s picture

pwolanin commented

Needs to be coordinated with http://drupal.org/node/72343 , to some degree.

I like the sugggestion in #2, since there is an unfilled need for this in 4.7 I'm trying to address with a separate module for 4.7.

kkaefer’s picture

kkaefer commented
StatusFileSize
new node_permissions_3.patch3.19 KB

Updated patch against HEAD.

beginner’s picture

beginner commented

Is there any issue open about changing the "$op == 'view'"-part of the _access hooks?

kkaefer’s picture

kkaefer commented
StatusFileSize
new node_permissions_4.patch3.18 KB

Rerolled the patch. I still need some feedback and reviews.

moshe weitzman’s picture

moshe weitzman commented

i'm a bit wary of adding more permissions like this since they make it impossible to control access via node access API. the return TRUE clause avoids all the calls to node_access table. for example, in order to do a workflow or private forum, admin has to disable all of these permissions. not a big deal, but it is confusing for admins i think.

inforeto’s picture

inforeto commented

what is the current way to view and edit your own created nodes while they await moderation?

kkaefer’s picture

kkaefer commented
Status: Needs review » Closed (fixed)

This is now partially implemented in node_types.inc (the part of CCK that is in core now).