Limit Node/Content by role
linuxpimp - January 23, 2007 - 15:34
Hi all
I've searched and found nadda :-(
I need to limit what nodes certain roles can view. In default access control, i see limitations for create and edit content, but not view content.
To put some perspective:
3 users/user groups or roles that each enter data via cck.
Neither should be able to view the resulting nodes except their own.
Many thanks
LP
http://drupal.org/project/og
http://drupal.org/project/og
I'm always loosing my car keys and my wife says I'm crap at searching too
Thanks for the response,
Thanks for the response, cocky, but informative :-)
Thanks
lp
Ok, i installed it on Drupal
Ok, i installed it on Drupal 5, wow, well done folks what an amazing system.
Now i need some guidelines on how to limit user within a group to their groups content only.
Any tips?
Thanks
lp
I'm interested too
I need the same functionality...the ability to limit content by Role, or with this module, by group. I'm setting up a test site for a school, and we want different students to have access to different content.
Everything's fine until you do a search, and all the stuff you don't have access to in a Block comes up in your search, which isn't good.
Excluding the search, how
Excluding the search, how did you get to a level where you can limit acess to nodes and menus by group?
Thanks
lp
this is how
Drupal 5.1 lets you hide entire Blocks by role...but in my case, I wanted to limit MENUS. And even when you hide blocks, the content is still there and reachable.
I ended up installing the Taxonomy Access Control module, but it doesn't hide menu items that you aren't allowed to access...meaning ALL the options appear for ALL logged in users, they just get an Access Denied message when they click on it. So then I tried the Menu Per Role build for Drupal 5 and it's completely useless (gives MySQL errors all over the place and seems like it doesn't add any tables to the db, which is the problem).
So I'm still looking for a solution.
Heads up
Just a "heads up" notice. In pre-5 days (ie 4.7 and lower) you could only install ONE node access control module at a time. In 4.7 and lower node access modules didn't play nice together.
However, in 5.x and beyond this has all changed. So, in theory, you can install OG and TAC (I'm not sure if this is what you have done). However, despite these modules being around for a long time, under the bonnet you're playing with brand new software which may need some maturity time. I know a lot of effort went into multi-node access module co-operation but it's still new. As such, if you get any unexpected behaviour then head off to the respective module project issue queue(s) and report it.
got it working
I ended up installing this:
http://drupal.org/project/menu_per_role
I had a bit of trouble installing it (had to make the patch and tables manually) but it works.
I'm just wondering where I could post all this as a feature request to be built into Drupal.
I found Drupal to be an amazing system, but it lacks the ability to be used in a school type setting where a few users are creating content, and the students can access only certain content that the admins have allowed them to access. This week I've installed numerous modules just to get things working the way I think drupal should work out of the box (I know, it's my opinion) and when I got it all done, I realized that the forums are tied directly to Taxonomy...using the TAC module (and assigning school class names as roles) makes a HUGE mess when a user goes to post to a forum...
anyway, I'm rambling now, but at least I got nearly ALL of what I wanted drupal to do working. I may have to resort to outside forums, but I'm pretty darn happy with what I got working this week (and I'm a brand new Drupal user).
access control for schools
Have you tried using taxonomy access and setting up a vocabulary that maps onto your user roles?
It took me a while, but eventually I settled into a fairly simple system: I define user roles (anonymous user, authenticated user, member, managers), and then set up a "Privacy" vocabulary with terms like "anyone can see this", "authenticated users can see this", "only members can see this", "only managers can see this".
Then on each node, set the "Privacy" category as appropriate. It works nicely -- although if you had a large school and needed to set access down to the class by class level, it'd take a lot of setup work. You could perhaps define two overlapping vocabularies, one for students/parents/teachers/etc and another for classes, and set permissions accordingly.
And if you've been down this path already, my apologies ...
Some great ideas, thanks! I
Some great ideas, thanks!
I have achieved this as follows and am still testing:
By using roles and correlating organic groups:
I have roles for (using your school example) student 1, student 2, teacher 1, teacher 2.
Then i have organic groups for class 1, class 2 etc.
I have then duplicated content types using import/export and named them appropriately correlating with groups.
In access control, only allowed "create_content_Type_$group" to relevant users/roles
I have then deselected the "audience" option so all new nodes of each content type default only to that group.
So now i have each role can only create content related to them and only see their on content.
Menus:
I completely removed all the menus and created a panel where i html coded the links to the relevant content type input pages. This is per group. using frontpage i will use these panel pages as the home page per group.
Complex, a bit, but seems to work so far ;-)
lp
I agree fully with you
I have TAC installed too and I am finding that I can not prevent students from posting in a teacher only forum. I managed to assign teacher roles and have those publish as private in a forum but I am finding that students will publish right into that container too. of course they don't see the teachers posts but the idea was to have a teacher only forum run next to student forums.
I would very much like to see a school type installation profile right out of the box which includes wysisyg, access control, image uploading, og etc.
TAC and OG Still Conflict
Don't get too happy.
I have submitted this as an issue here: http://drupal.org/node/122385
I struggled and struggled with OG and TAC in 4.7. Now, in 5.0, OG will at least work with TAC installed, but they still don't really work together.
If you create a vocabulary with terms, then assign a role access, the user in that role will be able to see any OG content (public or private) that matches those terms. I would think that if a user's role gives him access to nodes with a particular term, he should not be able to access said nodes if they are in private groups that he does not belong to.
Unless I'm looking at this all wrong....
???
Sorry, yes, I think you are. First up, if you read up you'll see I mentioned that in 4.7 you could only use one access control type module so it's no wonder you "struggled and struggled".
I'd be interested in seeing the contents of your node_access table but that's probably not possible. But think like this, TAC controls access to tax terms, not content. So you might see content in teaser lists for a vocab you have access to but if OG disallows access clicking it to load the node should give you access denied. TAC itself does not provide node access, just term access.
Now, onto OG. I would have expected OG to have surpressed teaser views of private nodes via it's hook_db_rewrite_sql() function but from what you suggest it's not doing it. So, maybe they still don't work together.
I would like to know how you are creating the teaser list views? By URL (eg taxonomy/term/2) or are you using something else to generate the list of nodes for teaser view?
--Andy
You are right. So, I just re-wrote the permissions...
You are right. Drupal contributed access control modules are written to co-exist, but not work togther. So, I rolled up my sleeves and re-wrote the permissions schema. Probably the dumbest thing I could do in the long run, but in the short term, it resolved all my issues. TAC and OG now work together -- that is, users can only see nodes if they BOTH belong to it's group (if any) AND have access to it's term restrictions (if any).
I did it by first installing the Extensible Node Access/Authorisation Capability patch: http://drupal.org/node/122173. Wrote my own nodeapi code to handle handle "access" for TAC and OG content. That handled balancing the create/view/update/delete permissions between the two modules.
For list permissions, I modified node_db_rewrite_sql() to respect TAC and OG. http://drupal.org/node/122712
Everything worked fine, except that my categories box failed to show up on node submission. Found out that if taxonomy_access is installed, then it is taxonomy_access_db_rewrite_sql() that determines permissions for display of categories box on node submission form. Appropriate changes there resolved that issue.
Now, the only thing I need to do is figure out how to put all these modifications into one seperate module, and I can enjoy a life outside Drupal hell.