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.