I’ve been trying to figure out a workable solution for a couple of months, and have come up with nothing more than some hacks and approximations of what is needed.
Here’s a use case:
User “A” (let’s call her “Amy”) writes a blog post. She wants it to be readable by her professor (let’s call her “Betty”) and one other student (let’s call her “Carmen”).
But, she doesn’t want the post to be readable by the rest of the class, by students in other classes, nor by the unwashed masses stumbling across a post via Google.
So, Amy wants to grant these privileges to her blog post:
Amy: Read/Write/Delete
Betty: Read
Carmen: Read
Currently, she can create an Organic Group, add the three users to the group (let’s call it “Amy+Betty+Carmen”), and mark it as “not public” and having an audience of “Amy+Betty+Carmen”.
That Organic Groups model works, but for her next blog post, Amy wants it to be available by another student (let’s call him “Dmitry”). So, she has to create a new Organic Group called “Amy+Betty+Dmitry” and add the three users to the group. She then writes a new blog post, sets it to not be public, and have the audience of “Amy+Betty+Dmitry”.
That pattern just doesn’t scale. Each user may have to belong to hundreds of Organic Groups to cover all permutations of sharing and privacy involved with a class or project.
It would be easier if there was just an “Access” section of the blog authoring page, where Amy could just select the users that she wants to add to each of the two non-owner roles (read and edit). This could pose some issues wrt scalability – if there are 100 users in a copy of Drupal, she won’t want to have to scan a list. Ideally, some ajax-powered user search would let her just start typing a person’s name (she may not know their username or email address) and have the system provide a list of matches.
So, the Organic Groups trick works, but doesn’t scale. If Amy wants to allow co-authoring on a post (a book page or something), she needs to start fiddling around with Simple Access (or make sure everyone has “Administer Nodes” privs, which won’t fly in a community based on assumed privacy for some content). Simple Access is tied to Drupal’s concept of Roles, so there may need to be 13 bajillion Roles in the system to cover all permutations (or a Role per user). Doesn’t scale. And, there’s the strange interaction between Simple Access and Organic Groups, where if you want OG to work, you can’t use Simple Access (you have to create a dummy Role called “nobody” with nobody in it for OG to kick in, as Simple Access will override it otherwise).
There are some others who appear to have a similar need. First, there’s the “na-arbitrator” module, which adds access control lists to forum posts (so far) – but it appears to be tied to the concept of Roles, with Users being added as Moderators. Close.
“Node Privacy by Role” module sounds close, but again is tied to the concept of Roles, not Users.
There’s the Taxonomy Access module, which would require enforcing a taxonomy and making sure only the appropriate people use a given term in the vocabulary. Don’t think this would scale either.
Then, there’s a rather detailed design spec but it appears to have been orphaned for a year or so… There are some other attempts dating back to 2004, but nothing appears to have been completed.
Perhaps the most promising sounding project is the “Groups” module – but even that hasn’t been touched in 13 months, and doesn’t work with Drupal 4.7
The official Drupal handbook includes a section that touches on this topic, but the solutions provided there don’t offer the level of user-defined granularity. They rely on administrators to set up roles and taxonomies and to manage the interaction between them. What is needed is a way for users to define the exact audience of any node they wish to restrict access to.
Long story short, I have no good idea on how to currently enable per-node per-user access controls in Drupal. I’ve got some projects that will either rely on this, or will benefit greatly from it.
I’ve been trying to figure out a workable solution for a couple of months, and have come up with nothing more than some hacks and approximations of what is needed.
Here’s a use case:
User “A” (let’s call her “Amy”) writes a blog post. She wants it to be readable by her professor (let’s call her “Betty”) and one other student (let’s call her “Carmen”).
But, she doesn’t want the post to be readable by the rest of the class, by students in other classes, nor by the unwashed masses stumbling across a post via Google.
So, Amy wants to grant these privileges to her blog post:
Amy: Read/Write/Delete
Betty: Read
Carmen: Read
Currently, she can create an Organic Group, add the three users to the group (let’s call it “Amy+Betty+Carmen”), and mark it as “not public” and having an audience of “Amy+Betty+Carmen”.
That Organic Groups model works, but for her next blog post, Amy wants it to be available by another student (let’s call him “Dmitry”). So, she has to create a new Organic Group called “Amy+Betty+Dmitry” and add the three users to the group. She then writes a new blog post, sets it to not be public, and have the audience of “Amy+Betty+Dmitry”.
That pattern just doesn’t scale. Each user may have to belong to hundreds of Organic Groups to cover all permutations of sharing and privacy involved with a class or project.
It would be easier if there was just an “Access” section of the blog authoring page, where Amy could just select the users that she wants to add to each of the two non-owner roles (read and edit). This could pose some issues wrt scalability – if there are 100 users in a copy of Drupal, she won’t want to have to scan a list. Ideally, some ajax-powered user search would let her just start typing a person’s name (she may not know their username or email address) and have the system provide a list of matches.
So, the Organic Groups trick works, but doesn’t scale. If Amy wants to allow co-authoring on a post (a book page or something), she needs to start fiddling around with Simple Access (or make sure everyone has “Administer Nodes” privs, which won’t fly in a community based on assumed privacy for some content). Simple Access is tied to Drupal’s concept of Roles, so there may need to be 13 bajillion Roles in the system to cover all permutations (or a Role per user). Doesn’t scale. And, there’s the strange interaction between Simple Access and Organic Groups, where if you want OG to work, you can’t use Simple Access (you have to create a dummy Role called “nobody” with nobody in it for OG to kick in, as Simple Access will override it otherwise).
There are some others who appear to have a similar need. First, there’s the “na-arbitrator” module, which adds access control lists to forum posts (so far) – but it appears to be tied to the concept of Roles, with Users being added as Moderators. Close.
“Node Privacy by Role” module sounds close, but again is tied to the concept of Roles, not Users.
There’s the Taxonomy Access module, which would require enforcing a taxonomy and making sure only the appropriate people use a given term in the vocabulary. Don’t think this would scale either.
Then, there’s a rather detailed design spec but it appears to have been orphaned for a year or so… There are some other attempts dating back to 2004, but nothing appears to have been completed.
Perhaps the most promising sounding project is the “Groups” module – but even that hasn’t been touched in 13 months, and doesn’t work with Drupal 4.7
The official Drupal handbook includes a section that touches on this topic, but the solutions provided there don’t offer the level of user-defined granularity. They rely on administrators to set up roles and taxonomies and to manage the interaction between them. What is needed is a way for users to define the exact audience of any node they wish to restrict access to.
Long story short, I have no good idea on how to currently enable per-node per-user access controls in Drupal. I’ve got some projects that will either rely on this, or will benefit greatly from it.
Related
You also might want to look at the simple access module — you will still run into some similar issues wrt scaling, as simple access groups are determined by roles. But, on the bright side, the UI is pretty straightforward.
This is something I’ve actually been thinking about tackling for a while, but with other projects looming it’s been pushed to the back burner —
One solution, which mirrors what Boris suggested: create multi-author nodes — the original author could specify additional authors (or readers, as they desired) when they created the node. If autocomplete (like in freetagging) was enabled for the additional author fields, this would scale just fine — type in the first few letters of a user, and you’re good to go — no drop down list necessary. The more robust (but, for the end user, potentially more confusing option) involves letting the original node creator select users or roles. The potential access levels could be: add editors/edit content/read content.
Thanks for confirming what I have been banging my head on lately. I have a partial solution.
http://www.hiveminds.co.uk/node/899
This is partial because though I have worked out the database schema there is still a question of usability. Trying to get an all encompassing list of rights per role that does not turn into a GUI that confuses the user. The second problem is trying to make sense of the rights per module, finding a common ground that developers can use in any situation. Access control on a module package like e-commerce is very hard to simplify to a CRUD model. While a contact.module has very simple needs and CRUD may be too much.
Per-node per-user is HARD. I remember we were actually looking at buddylist for this, where it would still (sort of) be role based, but you would create the roles/groups on the fly by user tagging (well, relationship tagging).
Think about how to do it in Flickr: JUST as hard — make a private group and invite the N people you want to have access.
Merlinofchaos’ na-arbitrator is likely the basis on which you would build something like this. You would want a 4.7-based type ahead widget for selecting users, and then choose a read/write/etc. access level.
If you’ve got a coding question, I am your man… Though I am not all that comfortable yet with access API, I can still help you with the rest of Drupal’s innerworkings. If you write up a proposal for what you’re describing along with outcomes, it could become a good Google SoC project.
Boris – I’ll try to do some R&D here on it. Seems like something that could benefit a lot of the Drupal community. There are some specs already partially published, and some (old) mentions of possibly doing it in Drupal core, but nothing’s moved forward. From the sound of it, what I’m describing in the use case isn’t possible now (at least not in a manageable and scaleable way) so I’ll put some effort into it.
Carl – agreed. This is going to take some effort on the UI, not just in code. There are some examples to be learned from though.
Bill – I’m using Simple Access, and it rocks for small-ish groups that are known in advance and managed by an admin. Since it’s tied to Roles, it just can’t scale, and users can’t create their own. I actually talked about Simple Access about half-way through this post 😉
D’Arcy — re talking about simple access in your post — Yes, you certainly did — time for me to stop sleepblogging 🙂
I’ve been thinking about this over the last few days, and it could make a good Summer of Code project. Is this something you want to develop in house, or do you think it would be useful to write up a spec as a proposed project?
If it doesn’t conflict with any development you are doing/planning, I’d be glad to write up the spec.
Bill – I can certainly pitch in. I’m not sure exactly what’s involved – never written a Drupal module, and am still getting familiar with the innards/hooks/APIs etc… but can contribute as I’m able. I think if someone took it on as a GSoC project, that we’d need a mentor involved who is extremely familiar with the guts of Drupal. Authentication, authorization, access control, etc…
Whether it winds up being done in house (or in several houses) I think a solid spec would help. If nothing else, than to serve as a design doc.
I just set up a wiki page for the doc. If there’s a better or more appropriate home for it, I’ll take that page down.
Sami, that’s great! I’m just digging in to get familiar with the guts of Drupal – until now I’ve been content just playing with the various modules, but now I get to dig deeper.
When I’ve got a better idea of what’s involved, I’ll flesh out the proposal – it could be that I’m not understanding the problem enough yet, so I’ll work on that first 🙂
Hey, I just ran across exactly what you are looking for! Check out the nodeaccess module – it lets you set permission to access any/every node by USER, not by Group!
http://drupal.org/project/nodeaccess