Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hi,
This module is great! I think a helpful addition would be the ability for users to restrict node access to individual users.
Comments
Comment #1
cel4145 CreditAttribution: cel4145 commented+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.
Comment #2
systematic CreditAttribution: systematic commentedI'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?
Comment #3
wslntheline CreditAttribution: wslntheline commentedAdd 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.
Comment #4
dblado CreditAttribution: dblado commentedHrmm, 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! :)
Comment #5
Dave Cohen CreditAttribution: Dave Cohen commentedUsing 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.
Comment #6
Dave Cohen CreditAttribution: Dave Cohen commentedJust 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.
Comment #7
kohlerj CreditAttribution: kohlerj commented+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.
Comment #8
jondoesdrupal CreditAttribution: jondoesdrupal commentedMight still implement this in 5.x, so will keep this open.
Comment #9
deekayen CreditAttribution: deekayen commentedI know Jon kept this open, but I think this is one of the few modules where the name clearly defines what it does.
Comment #10
deekayen CreditAttribution: deekayen commentedEven 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.
Comment #11
deekayen CreditAttribution: deekayen commentedhttp://code.google.com/p/google-highly-open-participation-drupal/issues/...
Comment #12
cwgordon7 CreditAttribution: cwgordon7 commentedIsn't the kind of functionality you described by this task covered by the content access module (http://drupal.org/project/content_access)?
Comment #13
deekayen CreditAttribution: deekayen commented#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.
Comment #14
cwgordon7 CreditAttribution: cwgordon7 commentedI believe that this is a misusage of GHOP; it's not supposed to be something that's
, 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.
Comment #15
deekayen CreditAttribution: deekayen commentedI 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.
Comment #16
deekayen CreditAttribution: deekayen commentedMoving back to my original position in #9.
Comment #17
deekayen CreditAttribution: deekayen commented#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
Comment #18
deekayen CreditAttribution: deekayen commentedI shouldn't be assigned cause I'm not really actively working on closing this.