The following documentation was originally written for OGUR releases prior to 5.x-3.0. As of OGUR 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 OGUR 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:
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 OGUR 5.x-3.0 or higher release download
- turned on TAC/OG Integration in OGUR 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".
Go to OGUR 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 OGUR 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.
Note: Your Admin role(s) should be given List/Create permisisons here for "NONE" term.
Give your Admin users permission to grant content access.
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).
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.