manage node owner access through node_privacy_byrole

+1

As a Linux/Unix person, I really like the owner-group-world file permissions model. Node privacy by role already implements the latter of these two. It would be great if it also included an "owner" set of permissions for controlling access for the uid of the original creator of the node. Finally, we get the kind of privacy options that many individual users have wanted in Drupal. For example, as the default for a given node type, don't give any roles any permissions. But give the owner view, edit, and permissions permissions. Then the node creator can decide when/if to grant permissions for other groups or make it world readable. Finally, complete control for the owner.

Once again, a big +1 for this if it is possible to implement.

I've just been referred to this thread from here http://drupal.org/node/35563,

Another +1 for per user permissions.

I have a number of sites to build with the following system:

A client registers on a company site with a query or job spec. The company staff and the client can then discuss the spec and add detail unitil a quote can be produced. The job can then be developed until a draft document is approved by both the client and the comapny.

I cannot find a viable way of allowing one client and all staff to view that clients job details... unless I provide a role for every client. Surely there is a better way?

Add another request for this feature. I have a radio station site where I have to set up an individual group for each show, and I'd rather just be able to set permissions for each DJ. I use a fixed-width theme (Kubrick), and having so many roles makes the access control page look horrid.

Hrmm, I guess make this a third inquiry...

I'm designing a site such that users may define their own groups...groups will be made up of drupal IDs or simply emial addresses for futre assignment to a drupal ID. I have been wrestling w/ using a hybrid of the node_access hooks which will return true/false. Thereby allowing me to interact w/ the drupal core but also code up my own access restrictions to nodes.

If I'm missing something and the node_access system does just this, please by all means steer me in the right direction! :)

Using the node_access table is definitely the way to do this. You can create a module which adds an one or more rows to that table for every node created. You'll have to add something to the node create/edit form that lets you pick the users who have access (I'm thinking a comma separated list of usernames using the autocomplete feature). The behavior of node_access is not exactly intuitive, for protected nodes youd make an entry that grants view access in the realm 'user_access' or whatever you call the module and use a uid as the grant ID. For unprotected (public) nodes, you'd want to grant permission to ID 0. Then in hook_grants assign the current user her uid and 0. See the doc on drupaldocs.org to fill in any blanks my brief explanation may have left.

My other comment is to encourage anyone reading this thread to try an access control module I've contributed:
http://drupal.org/project/tac_lite.

Just to be clear, when I said writing a module to use node_access was the way to do this, I was referring to node privacy by user, not blado's specific request. Blado, you should investigate the organic groups module.

+1 It's a problem that I've just run into. I'm making a single user blog-ish site. On the one hand I want to avoid readers having to create accounts for themselves. But I also want some posts to be private. I could do privacy by role, but that will fail if I change my account policy in future. I'm using 4.6.x - any ideas would be appreciated.

Might still implement this in 5.x, so will keep this open.

I know Jon kept this open, but I think this is one of the few modules where the name clearly defines what it does.

Even I think I'm crazy for re-opening this, but as I get deeper in the code, I can see why Jon left this open. With a little mind bending and time, it could happen. Perhaps it could lead to a deprecation of the current module name.

http://code.google.com/p/google-highly-open-participation-drupal/issues/...

Isn't the kind of functionality you described by this task covered by the content access module (http://drupal.org/project/content_access)?

#12: yes, there's some cross over. This module is much older than content access. Adding and then backporting this feature to other versions could be useful for people who have used this module for years. I'm thinking it's not a big deal to add the feature, which is why it's a GHOP task.

This (the feature duplication) is one of the unfortunate side effects of having a moderator-free contribution repository, though I suspect Wolfgang knew what he was doing having started the description of content_access as "Yet another node access module." It might also be because node privacy by role went through an extended period without active feature development, and given the age of this feature request, seeing a variant module isn't a shock.

I believe that this is a misusage of GHOP; it's not supposed to be something that's

not a big deal to add

, it's supposed to be something interesting that would take 3-5 days to complete. This task would most certainly not take that long; maybe a maximum of 1 day, a better estimate being 1 hour.

At the very, very least, the content_access module should be listed as a resource on the GHOP project page.

I withdrew it from GHOP, though I don't think understanding node access is a 1 hour deal, or writing and debugging the PHP code, especially when you consider GHOP is a good tool for introducing people to Drupal and there's a lot to understand even before this.

Original proposal draft is at http://drupal.org/node/200980.

Moving back to my original position in #9.

#296070: Ad a permission to the owner asked for this again and someone by email, so at least it'll be a landmark for people who are willing to submit a patch

I shouldn't be assigned cause I'm not really actively working on closing this.