Using Content Access and ACL with OG User Roles
The following documentation was originally written for OGR releases prior to 5.x-3.0. As of OGR Release 5.x-3.0, the "Multiple Node Access logic patch" http://drupal.org/node/196922 is used for TAC/OG/CA/ACL Integration.
As of this writing, I know that CA (Content Access) and ACL (Access Control List) now work with TAC/OG Integration http://groups.drupal.org/node/3700. But, because of the new way this integration is achieved (using the multinode_access table), there are now a variety of ways you can now configure access.
This is complicated stuff, but I'm going to try.
Multiple Node Access Logic
As of OGR Release 5.x-3.0, TAC/OG Integration is achieved by configuring the new "multinode_access" table for the logic you desire between the access control systems. This is the logic recommended for TAC/OG Integration:
(all OR og) AND (tac) OR (ogr)This says that I always want og and tac rules integrated to respect each other, but they can be overriden by ogr rules. I explain here http://groups.drupal.org/node/3700 what I mean when I say "integrated to respect each other".
OG User Roles now supports these two modules:
- Content Access: http://www.drupal.org/project/content_access
- ACL: http://www.drupal.org/project/acl
These modules allow you to custom define roles and/or users who can access particular nodes.
In order to add them to our TAC/OG Integration, I recommend this:
(all OR og) AND (tac) OR (ogr) OR (ca) OR (acl)This says I want tac and og rules always integrated to respect each other, except when overriden by ogr, ca and/or acl rules. If node has a taxonomy term, belongs to a group, and has some content_access permission, a user must have either the group AND taxonomy permissions OR the content_access permissions OR the ogr permissions to access the node.
Now, it's possible to look at this another way:
(all OR og OR ca) AND (tac) OR (ogr) OR (acl)This says I want tac and og AND ca rules always integrated to respect each other. So, if node has a taxonomy term, belongs to a group, and has some content_access permission, a user must have ALL of these permissions to access the node, not just one or the other, OR the acl permissions OR the ogr permissions.
Configuring TAC/OG/CA/ACL Integration
The following discussion assumes you have, in addition to OG User Roles:
- installed both Content Access and ACL modules as well as Taxonomy Access Control (TAC)
- you have installed the "node.module.multinode.patch" http://groups.drupal.org/node/4026 provided in the OGR 5.x-3.0 or higher release download
- turned on TAC/OG Integration in OGR Settings http://drupal.org/node/163567
- created a content type called "Document". You can use any content type you wish, but for this discussion and testing, we've created a content type called "Document".
Configuration:
Go to OGR Settings Admin->Organic groups->Organic groups user roles and click on the "Multinode access UI" tab. You should configure this screen exactly as you see below:
Configure your screen exactly as you see above, and click on "Save changes" button. The above creates the following logic:
(all OR og) AND (tac) OR (ogr) OR (ca) OR (acl)If you desire another logic possibility but aren't sure how to configure it, please post a support request to OGR Issues: http://drupal.org/project/issues/149373
Next, configure "Document" content type (assumes you have already created it):
Click on "Access Control" tab for this content type:
From this screen:
- Enable per node access control settings
- Uncheck all roles
"Document" content type is now set up to use Content Access.
You should repeat this process for every content type used on your site that should respect this multinode access logic configuration.
Note: The following original documentation steps are recommended, but required
To be honest, I am no longer sure that the following is required as it once was. The new integration architecture appears to allow you to support CA and ACL with or without TAC.
I'm leaving this documentation just to be on the safe side. But, I suggest you play around and see what works best on your site.
I create a "Document" vocabulary and add the "Document" content type to it.
Home > Administer > Content management
I then use the "add terms" link to add a "NONE" term to the "Document" vocabulary.
Using Taxonomy Access Permissions (TAC), I grant NO role access to this term (except for privileged "Admin" users). This means that any node you assign this term to will not be viewable by anyone. This is the recommended category to use for content for which you intend to use Content Access (i.e., assign customized permissions).
You must do this because you cannot use Content Access to revoke permisisons granted by TAC. However, you can use Content Access to grant permissions to content that TAC does not grant permissions to.
Home › Administer › User management > Taxonomy Access: Permissions
Note: Your Admin role(s) should be given List/Create permisisons here for "NONE" term.
In: Home › Administer › User management > Roles:
Give your Admin users permission to grant content access.
http://www.yoursite.com/admin/user/roles
Gave "Admin" and "GroupAdmin" roles these permissions:
grant content access grant own content access
These are my Admin roles which can create Content Access nodes. These roles need to be able to List/Create "NONE" term (use Taxonomy Access: Permissions).
Usage:
It is first important to remember that if you want to create custom access to a node you create, that node must NOT have access granted by a vocabulary term. From a technical standpoint, Content Access and Taxonomy Access (TAC) do not work together. So, you can't, for example, assign a node a vocabulary in which TAC allows Role A to view it, then try to use Content Access to restrict Role A from viewing it.
In order to use Content Access, you must assign the node for which access is to be customized to the "NONE" category (you have used TAC to grant NO users access to "NONE" content, except for Admin users). Then from the node's "Access Control" tab (which will appear once the node is submitted) you assign what roles and/or users can view/edit/delete the node.
To create a node with customized content access (using the "Document" content type):
- Click on "Create document" link from Group menu.
- Create node as usual, except for "Category" select "NONE". Click on "Submit".
- At this point, no one can see the node but you.
- When the node is saved, you will see an "Access Control" tab next to the "View" and "Edit" tabs. Click on "Access Control" tab.
- You will see the "Role access control settings":
- Below that you will see the "User access control lists" (ACL) section which has the individual Grant view/update/delete lists. Here is where you enter invidual user IDs to grant a particular permission for this node:
- On this screen, you can select the roles to give view/update/delete permissions for this node. Or, you can enter the users to grant view/update/delete permissions for this node.
If you make any changes to this screen, don't forget to click on "Submit".
Don't forget that if you add users to the ACL using the "Add User" button, you must still click on the "Submit" button at the bottom of the screen for your entries to be valid.
Content Access Weight?
By weighting content access by node type, can't you allow taxonomy access to take precedent or not? If I weight the content access heavier than taxonomy access, then the content access overrides taxonomy. If I weigh the content access lighter, the taxonomy access takes precedent? I am currently testing this and it seems to work this way.
Access Controls should work together, not in spite of each other
The whole point of the TAC/OG Integration was to get the two modules to work together, respect each others controls. Weighting one or the other higher so that it takes precedence over the other isn't, in my opinion, working together.
What I want are the permission restrictions of TAC, OG and Content Access to ALL apply (not one or the other).
The problem with Content Access (CA) and TAC is that it is possible to override TAC permissions with CA. I think your idea works for the example I give about TAC granting permissions to Role A that are removed by CA. Weighting CA higher in this case would solve this problem.
But, when you throw OG User Roles into the mix, Im not sure how predictable the results are. Are you testing this with OG User Roles?
Content Access Weight?
By weighting content access by node type, can't you allow taxonomy access to take precedent or not? If I weight the content access heavier than taxonomy access, then the content access overrides taxonomy. If I weigh the content access lighter, the taxonomy access takes precedent? I am currently testing this and it seems to work this way.
Oops
Didn't think it was posting... unlimited preview effect.
Is it possible to use OG
Is it possible to use OG User roles with ACL/Content Access, but not TAC, or with TAC but not ACL/Content Access?
OG User Roles and TAC for sure...
I know you can use OG User Roles and TAC without CA. Don't know if you can use OG User Roles and CA without TAC. You'll just have to test that one out.
I can confirm that
I can confirm that og_user_roles works flawlessly with Contect Access without TAC. I threw ACL in the mix too and these three (og_user_roles, ca, acl) cooperate perfectly. Ron is a genious, how could they not work!
OpenMusic, a network of Drupal based music social communities
TemplateMonster templates 20% off
TaggSHOP - digtag shopping for the best deals online
content_access and og_user_roles
Can you tell me how you achieved it? I use og_user_roles and content_access (and planning on acl).
Here is my situation:
There are 5 groups (og).
All users are assigned to a group.
No site wide roles assigned, only og_user_roles.
Table 'og_users_roles' show that roles are assigned
Table 'users_roles' is empty.
'og_user_test' (testPerm) shows correct roles when accessing 'My Tracker' (testGroup is not 0).
Site wide content access (/admin/user/access) assigns only one permission "node module - access content" to authenticated users (or else nothing is accessible).
Content type access (for example /admin/content/types/book/access) is used to give permission to roles to view the content type.
I use weight -1 as 'node grants priority'.
However, content types stay visible at the user's "my tracker" even if they don't have the roles that I have given permission to see the content type.
How to debug this for og_user_roles?
Can your users fully view
Can your users fully view the nodes that are listed under my tracker? If so it probably is a matter of og_user_roles taking precedence over content_access.
OpenMusic, a network of Drupal based music social communities
TemplateMonster templates 20% off
Yes they can fully view the
Yes they can fully view the nodes.
I'm wondering how to investigate access permission of a node or content types.
Since I use weight -1
Since I use weight -1 content_access should take precedence.
Maybe it doesn't obey og_user_roles.
I suppose content_access should override the site wide permission (node: access content) to authenticated users.
Have you tried to set the
Have you tried to set the weight to the maximum positive value?
OpenMusic, a network of Drupal based music social communities
TemplateMonster templates 20% off
weight 1 or 10
Thx. Sorry it took a while to reply.
Does a positive value mean that content_access is more dominant?
Setting the weight of all content types to 1 or 10 gives me "There are no new posts in your subscribed groups" (while viewing "My Unread" and "My Recent").
When I assign this user a site wide role it works as expected, but not with og_user_roles (adding the same role in a group).
So it seems this could be a bug. If so, in og_user_roles or content_access?
Do you have a similar setup and does it work without TAC? Because I want to avoid TAC as a major access control mechanism.
I am not using an extra
I am not using an extra access control module right now apart from og_user_roles. I did test content_access and acl in the past though and it worked fine without TAC. I was trying to avoid TAC too, but I've figured I can't. Sorry I can't help anymore, maybe you could request for help at the og_user_roles issue queue.
OpenMusic, a network of Drupal based music social communities
TemplateMonster templates 20% off
Elimate anonymous access to OG content
Hi, I'm new to Drupal and have been reviewing many posts regarding OG, TAC, Content Access, ACL and etc. My issue is that I want to have a "private" OG that only members in that OG can view the content. Currently, I have created this group, but all users (even anonymous) can view the content and I'm a bit confused as to the direction I should take since there is much information on these topics and I'm getting somewhat overloaded on the glut of information. What is the easiest method to lock down an OG so only members of the groups have access to it (including view). Should I create a separate role to do this and tie it to the OG or should I create a category for the group, but I thought that this was inherit to the OG module. Thanks for any help!
Don't Use Taxonomy Access Control
The OG module has settings specifically for this issue:
Visibility of posts:
Visible only within the targeted groups
Visible within the targeted groups and on other pages
Visibility chosen by author/editor using a checkbox on the posting form. Checkbox defaults to Public.
Visibility chosen by author/editor using a checkbox on the posting form. Checkbox defaults to Private.
So, if you must first restrict the visibility of your posts. Do not make your posts public.
Secondly, do not use another access control for nodes, such as Taxonomy Access. Why? Because, if your group node is private, but has a taxonomy that is public, guess what? Yes, everyone can see the node.
Hope this helps.
How to make group posts visible to all authenticated users then?
I would like to do what the poster above said.
What is the best way to do this?
So far, I have tried by posting to "public" on the group. Unfortunately, then the anonymous users can view the posts as well. If I turn off content access for anonymous users, then I believe i won't be able to make static pages available to the anonymous user.
I've tried a couple access modules but they don't seem to work as I want them to (maybe I haven't configured them right). I saw the post on making TAC work with OG, and was wondering if that was the way to go (I figured I would make a TAC control for private/public and then still allow the "public" post from OG for open groups, but have it controlled by some taxonomy accses so anon could not see it. I hoped doing that i could somehow create the above permission scheme).
Does anyone have any suggestions on the best way to go about this?
Thanks.
This is a case where you need to use TAC
Install Taxonomy Access Control. Create a vocabulary with a term: Let's say, for arguments sake, "Authenticated".
Assign the vocabulary to the content types you need.
Go to Admin->User Management->Taxonomy Access Control. Select anonymous role and in the vocabulary give the anonymous role NO access to "Authenticated" term. Next, select the authenticated role and in the vocabulary give the authenticated role list and view access to the "Authenticated" term.
When you create a group post, if you want only authenticated users to see it, then give it the "Authenticated" vocabulary term.
If you want all users to see it, then simply check the "Public" box as before but do not select a vocabulary term (select "None").
For pages that you do NOT want the authenticated users to see (unless they belong to the group), simply do NOT check the public box and do NOT select a vocabulary term (i.e., select "None").
There's probably an easier way, but this is what comes to mind for me.
TAC/OG integration is NOT required for something like this to easily work.
Thanks
Thanks somebodysysop.
I tried doing it the way you suggested, but we decided that we did not want to label every piece of content. We preferred that the default be that all content was not visible to anonymous users, in case we forgot to label something. Since the number of pages we needed to be visible to anonymous users was small (probably just a few static pages), we created another content type for those pages and just circumvented the access for that particular page type. We hope that making those changes won't come back to bite us...but it seemed the safer route for now.
Thank you very much for your input. It helped a lot in figuring out what the possible solutions were and in making a (better) informed decision.
Thanks again.
Will this work for doing this?
Ok, I am still a little confused. Not sure if all this will help me in my project but here is what I am looking to do...
... For each group I want to set specific users permissions for different content types. For example:
.
User #1: Bill
User #2: Dave
User #3: Steve
GROUP #1:
Content(Blog) = Bill can view only. Dave can create and edit. Steve Cannot access at all
Content(Story) = Dave can View Only, Bill can create and edit, Steve can view only.
GROUP #2:
Content(Blog) = Steve can view only. Bill can create and edit. Dave Cannot access at all
Content(Story) = Bill can View Only, Steve can create and edit, Dave cannot access at all.
I have been round and round trying to figure out how to give users permissions on a per content and per group basis. Easy making overall permissions for content types but I need it done on a per user->content->group basis. Can anyone tell me exactly what type of settings I need to perform to make this happen?
Thanks!
I'm having the same issue
From reading the documentation and many posts you should be able to do this, but I'm having the same issue whereas when I try to Configure Member Roles for members within the group the permissions do not seem to work as I only still have the overall role permissions. I thought I had this working previously and perhaps I did, but I must have messed something up when installing another module.
I have tried to debugging and when reviewing the og_user_test table I see where the correct og roles are being returned (testPerm) which match the roles selected in the Configure Member Roles configuration, but those roles are not displaying the correct menu items in the group menu block as I have a role checked in the Configure Member Roles that should have capability to create pages, stories, events, etc, but those create content links are not displaying in the group menu block.
If anyone has run across this issue your assistance would be greatly appreciated.
I think you need Taconomy Access Control
If I understand what you are after, it is similar to what I attempted to do using OG Access Control. I learned that it cannot be done. If each member of a group requires permissions to read, create, edit own, or edit all of a specific content type and you want to limit that between groups, then you have to use TAC. Drupal permissions will apply across groups. In my case, I wanted the book content type to be fully editable within one group but only readable by another. The book content type had to be set to allow all to edit book posts. OG will limit access to the group so content within a group is not accessible by non group members, but the second one selects a non group member person or other group as an 'audience' to that specific piece of content within the group, the content type permissions apply to all who can access the content type (group member or not) and those permissions trump any node level access control. The only way to do this I found was to scrap OG access control, enable Taxonomy Access Control, create an access controlled term and apply that term to each post you wanted to restrict access to. The other method I could have used was to to "simply" create multiple content types, but the main content type I wanted was like the book module, and duplicating the book module turned out not to be a very simple task... for me at any rate.
Now my issue is to seek out a module that will allow for the mass tagging of a book's hierarchy as I have to tag each page of a book with the book title, which is the term I added in TAC to restrict editing access to this book. The drupal site is down for updating now so have not been able to search to see if such a module exists... heres hoping...
Multiple node access patch compatibility?
Has anyone checked if this works with the multiple node access patch that comes with Domain Access? This patch allows using AND logic to combine the node access grants from multiple node access control modules.
Multiple Node Access logic patch
As of OGR Release 5.x-3.0, TAC/OG Integration is implemented using an updated version of the "Multiple Node Access logic patch" introduced here: http://drupal.org/node/196922
OGR documentation has already been changed to reflect this: http://groups.drupal.org/node/3700. I expect to make the new release available in the next few days.
It would be nice to get this functionailty into Drupal core. You can read the arguments for and against this here: http://drupal.org/node/196922
For my part, I've tested my implementation of the patch and found it far more efficient than the previous method I employed for TAC/OG Integration. It's also revolutionizes the process of adding additional access control logic to the node grants table, if you are not amongst the faint-hearted.
If you use this implementation, and find it useful, please support our effort to get it into Drupal core.
Thanks!
I can't see ACL in the Multinode UI
HI,
I've installed ACL,CA,OG,Og content access, TAC and obiously og_user_roles.
But i can see all the fields less than ACL in the multinode UI, i've checked the node_access table in the realms field, but nothing.
It's a normal behaviour ?
Paolo
ACL and Organic group plugin
I've released a preliminary version of a simple bridge between ACL and OG:
http://drupal.org/node/290993#comment-951339
Give me your feedback :)
Paolo
Configuring content_access to work with organic groups: success
I've managed to get content_access to work with organic groups. My requirement is as follows:
I have groups with varying levels of access, some private, some public. I want some individual control of some nodes such as making some nodes in private groups accessible to users without letting them into the group. I may use group user roles at some stage but they are not essential yet. I have no use for taxonomy access at this stage. All I want is to get content_access and organic groups working together.
Here is what I did:
(note that I have edited this a bit as I get it right)
Setting up content access to work with organic groups:
Install node.module.multinode patch as per instructions at http://groups.drupal.org/node/5392 to enable content access and organic groups permissions to work alongside each other.
Enable at least one content type for content access and enable at
least one node for an individual user. This will activate the acl
grant in multinode view settings page
Set multinode page as follows:
acl, acl, OR, 4
content_access_author, caa, OR, 2
content_access_rid, car, AND, 3
Go into content_access module and in the function content_access_get_setting_defaults() comment out the following lines:
$grants = content_access_get_default_grant($node);
content_access_optimize_grants($grants, $node);
and replace the last function call with $grants[] = array('grant_view' => 1, 'realm' => 'content_access_rid', 'gid' => 1);
so you end up with this:
function content_access_node_access_records($node, $optimize = TRUE) {
if (content_access_disabling()) {
return;
}
// Apply per node settings if necessary.
if (content_access_get_settings('per_node', $node->type)) {
$grants = array();
foreach (array('view', 'update', 'delete') as $op) {
foreach (content_access_per_node_setting($op, $node) as $rid) {
$grants[$rid]['grant_'. $op] = 1;
}
}
foreach ($grants as $rid => $grant) {
$grants[$rid] = content_access_proccess_grant($grant, $rid, $node);
}
}
else {
// Apply the content type defaults.
// $grants = content_access_get_default_grant($node);
$grants[] = array('grant_view' => 1, 'realm' => 'content_access_rid', 'gid' => 1);
}
if (empty($grants)) {
// This means we grant no access.
$grants[] = array('grant_view' => 0, 'realm' => 'content_access_rid', 'gid' => 0);
}
else if ($optimize) {
// content_access_optimize_grants($grants, $node);
}
return $grants;
}
Now rebuild the permission table. This will create a content_access_rid grant against each node which the multinode access function needs to make the AND operation work.
That covers most things. The main things different from other instructions are the use of AND for content_access_rid (and the hack that goes with it) and the need to enable a node for acl to get the acl grant to show.
Initially I tried configuring content access with OR for content_access_rid but that doesn't work because the default settings for content_access is view access, so if a group is set to private then with the OR operator, content access will over-ride unless you go in to each content type and set default to no access. I solved this by hacking content_access.module to remove the problem (http://drupal.org/node/273624#comment-1135014). This enabled me to give access using acl to non members of a private group, but then I later realised that it did not enable me to make a post in a public group private, because the og setting would always over-ride because it is set to OR. So the best solution is to make the content_access_rid AND and the acl OR. This means that you can make public group nodes private, by unchecking anonymous and authenticated roles and you can make private group nodes public to selected users by using acl.
Best of luck in doing it yourself.
Kent Parker
Web development