Note: The solution described in this blog post has severe performance implications on sites with more than a few hundered nodes. Use at own risk.
Still, I’ve been using it from time to time. Why? Because I want the group functionality. I want a “master node” with sub-nodes attached to it, and manage access to all the nodes as one. Do you belong to the master node? Fine, you’re granted access to the sub-nodes. If not – sorry, you’re not welcome.
A few weeks ago I tried another way of doing this that works much more the Drupal way, and provides the flexibility I repeatedly have been missing in OG. The secret? Node Access User Reference and Node Access Node Reference. (Thanx danielb/Daniel Braksator for the modules!)
Here’s what they do:
- Node Access User Reference gives you a few more settings in all the user reference fields, namely Grant “view/edit/delete” node access to user (in three separate settings).
- Node Access Node Reference gives you a few more settings in all the node reference fields, namely Pass on “view/edit/delete” node access (also in three separate settings).
Why is this magic? Because you can create a master node type (say “Project”), place a number of user reference fields in it (say “Project owner”, “Developer” and “Customer”), and associate them with appropriate access. Then you can create a number of sub-nodes (say “Project description”, “Report”, “User story” and “Issue ticket”) and use the node reference field to just pass on the access.
You’re the project owner? Fine, you can edit and delete just about anything you want in this project. You’re a developer? Fine, you’re allowed to edit stuff, because I trust you. You’re a customer? Welcome to view anything you like in this project.
Manage the access just by adding users to the relevant fields in the master node. All done!(*)
Combine this with Node Reference URL Widget for easy refering and a neat Views restriction in the advanced section of the node reference field and you’ve got all the stuff you want from OG – or more. No more headaches caused by special conditions with Views or Panels, or some other modules you happen to use. No lock-in to the OG universe. Just the access control.
Once I get my head going I can come up with a number of things to try. Why not extend the accessibility in a group? You can add a user reference field on a Report node and have other users access only this piece of content (or, if you haven’t had enough, nodes refering to it). Or try clustering the master nodes into domains, where super managers can add new projects. It just keeps on going.
So, will this really be the last time I use Organic groups? Hardly. I use it more or less every day on g.d.o. Tons of people download, install and use it. But for those who are just looking for a flexible solution for access control, there is an alternative.
For people like me.
//Johan Falk
Drupal Trainer at NodeOne and manager for the Swedish Drupal group
PS: I intend no offence to the great people working hard on OG. I am glad that the module exists and works well. It’s just that I’m also glad that there is an alternative when I don’t need the full functionality of Organic groups.
( * ) “All done” might be a slight exaggeration. There can be issues where you want to pass on edit privileges (or add them) for some user roles but not for others. I’ll get back to that.
Comments
Robert Redl
June 6, 2010Thanks for this Drupal Module "recipe". I am glad that you are high up in the search results for "drupal organic groups" ;-) Will try this out on a project where I need it.
Greetings from Vienna, Austria, Robert
MXT
June 18, 2010THANK YOU VERY MUCH FOR YOUR SUGGESTION!!! It resolve months of headaches working with OG - OGUR - WORKFLOW and so on.
I have only a small issue: can you help me?
I made 2 content types:
<ol>
<li>Department (= group) with 2 user reference fields (moderators, authors)</li>
<li>Article with a node reference field to Department</li>
</ol>
My site configurations:
<ul>
<li>A user can belong only and only one Department</li>
<li>A department moderator can manage only his department authors/contents</li>
<li>An article can belong to only and only one department.</li>
</ul>
The issue:
I want that when an author write an article, the "department" field is already set with the default value coming from user himself referred department (that can be only and only one value).
I don't want use the URl widget: I noticed that there is the possibility to setting a default value with custom php in the "department" field CCK admin page, so I need a script similar to:
<code>
$nid = db_query("SELECT <referred department NID> FROM ... WHERE <acting user ID> LIMIT 1")
return array(
0 => array('nid' => $nid)
);
</code>
I'm not a programmer, so I cannot write the script above!
Or there is another solution?
Than you very much
MXT
(sorry for my bad english)
Gäst
December 7, 2010Doesn't this require manual addition of each user to the master node? If not, how would you automate that for users to assign themselves to nodes?
Gäst
January 22, 2011one possible solution is http://drupal.org/project/nodeaccess_password
Gäst
January 17, 2011will there be a video tutorial for this excellent approacg ??
Barrett
March 4, 2011I'm not seeing the advanced section you refer to when talking about "neat Views restriction in the advanced section of the node reference field." Can you tell me where that should be?
Zy
July 20, 2011How do you emulate join group links?
Rasmus
January 17, 2012Guess this is for Drupal 6?
Johan Falk
January 17, 2012 Yep it is Drupal 6. And more importantly, I have now reason to believe that the solution described here has severe performance implications on sites with more than a few nodes. (I'm gonna update the post right now, to include this information.)hans
January 20, 2012can you elaborate on the performance implications
Johan Falk
January 20, 2012 Sorry, I don't know the details of the problem enough. The module causes really heavy joins, that's kind of all I know. :-/Eric Sol
February 3, 2012I can confirm the huge performance penalty these modules inflict. I am not a programmer but from some inspection of the code it seems to first load all of the nodes and then filters out nodes you don't have access to. I don't think the joins are the main cause; especially with PostgresQL joins are not that expensive.
The performance hit was hard enough for me to revert back to OG...