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:
- 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 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".
Configuration:
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.
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.
Comments
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
A healthy disregard for the impossible.
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
A healthy disregard for the impossible.
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
A healthy disregard for the impossible.
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
A healthy disregard for the impossible.
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_node_access_records() 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);
$grants[] = array('grant_view' => 1, 'realm' => 'content_access_rid', 'gid' => 2);
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);
$grants[] = array('grant_view' => 1, 'realm' => 'content_access_rid', 'gid' => 2);
}
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.
Note. I found that with Taxonomy Access Control enabled my permission system did not work as required. Since I have no use for TAC in this instance I simply disabled it and the system works. It also means I do not have thousands of term_access entries in the node_access table that I do not need. It does say in the multinode access screen that you need TAC enabled for multinode access to work but that doesn't seem to be the case. The multinode form saves to the multinode access database table and the mulitnode patch operates regardless of whether or not TAC is enabled. An improvement to multinode access would be to make it entirely independent of any particular access system, so that it can be used anywhere.
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
Kent Parker
Web development
I can't make nodes visible to certain roles
I think I've followed all the steps. Now my groups work fine, I can make public and private group documents.
The problem is that I want to publish stories (normal stories, not group posts) accesible only to certain roles. For example, I want to publish stories visible only for authenticated users, but another stories visible only for an specific role.
I have created a story, and in the Content Acces tab I have chosen the authenticated users role. That's OK, because anonymous users can't see the story. Perfect!
I have created another story, and in the Content Access tab I have chosen the "exclusive users" role. Unfortunately any authenticated user can see the story, not only the "exclusive" users.
Do you know where's the problem?
This is exactly what I need,
This is exactly what I need, although I'm having trouble with it. Anyone know of a version of the multinode patch that applies to Drupal 6.19 ?
--
Tom
www.systemseed.com - drupal development. drupal training. drupal support.
No difference
I have followed your instructions, but I don't get this working. I have unchecked view access for anonymous users, but it seems that content_access is being ignored. What weight are you using for it?
How can this affect organic group access when you don't put any rules on its realm, only acl, content_access_author and content_access_rid have rules?
Maybe you should mention that modules acl and og_user_roles need to be installed, as your instructions are pretty detailed otherwise.
UPDATE: It works now, I didn't realize that I have to check the box above the default options in content access. I'm using weight -1, does it make any difference?
Maybe you should mention
See: Configuring TAC/OG/CA/ACL Integration
What box? What is the name of the field?
In my implementations, both ACL and Content Access are weighted at zero. TAC is weighted at 9. OGUR is weighted just about higher than everything else.
Hi somebodysysop, I've been
Hi somebodysysop,
I've been trying to implement your multinode access for a particular configuration and haven't succeeded quite in getting it to work. Looking at the sql statement generated by a typical multinode configuration we have something like this:
SELECT COUNT(*) FROM {node_access} WHERE (nid = 0 OR nid = %d) AND (
((realm = 'all' AND gid = 0) OR (realm = 'job_view' AND gid = 1) OR (realm = 'og_subscriber' AND gid = 1765) OR (realm = 'og_subscriber' AND gid = 2254) OR (realm = 'og_admin' AND gid = 1917) OR (realm = 'og_admin' AND gid = 2162) OR (realm = 'og_admin' AND gid = 2168))
OR nid IN (SELECT nid FROM {node_access} WHERE ((realm = 'og_public' AND gid = 0)))
OR nid IN (SELECT nid FROM {node_access} WHERE ((realm = 'content_access_author' AND gid = 23)))
AND nid IN (SELECT nid FROM {node_access} WHERE ((realm = 'content_access_rid' AND gid = 2) OR (realm = 'content_access_rid' AND gid = 6) OR (realm = 'content_access_rid' AND gid = 7) OR (realm = 'content_access_rid' AND gid = 11)))
OR nid IN (SELECT nid FROM {node_access} WHERE ((realm = 'acl' AND gid = 653) OR (realm = 'acl' AND gid = 872) OR (realm = 'acl' AND gid = 873) OR (realm = 'acl' AND gid = 874) OR (realm = 'acl' AND gid = 875) OR (realm = 'acl' AND gid = 876))) ) AND grant_$op >= 1"
To me this seems an expensive use of resources when you could just look for, say realm = 'content_access_author' AND gid = 23 for the current node instead of selecting bulk nodes. It seems to me that a much simpler solution would achieve better results. Something like
SELECT COUNT(*) FROM {node_access} WHERE (nid = 0 OR nid = %d) AND (
((realm = 'all' AND gid = 0) OR (realm = 'job_view' AND gid = 1) OR (realm = 'og_subscriber' AND gid = 1765) OR (realm = 'og_subscriber' AND gid = 2254) OR (realm = 'og_admin' AND gid = 1917) OR (realm = 'og_admin' AND gid = 2162) OR (realm = 'og_admin' AND gid = 2168))
OR (realm = 'og_public' AND gid = 0)
OR (realm = 'content_access_author' AND gid = 23)
OR ((realm = 'acl' AND gid = 653) OR (realm = 'acl' AND gid = 872) OR (realm = 'acl' AND gid = 873) OR (realm = 'acl' AND gid = 874) OR (realm = 'acl' AND gid = 875) OR (realm = 'acl' AND gid = 876)) AND grant_$op >= 1"
)
Any AND arguments would require a separate sql (2-3 small ones seems less expensive than several large ones) for each AND argument and node_access would return TRUE only on success with ALL.
I'm not an expert on node_access but it seems to me that if the access rule is not stored against the nid then it doesn't apply to that node and no record will be found. I can't see why you run all those nested SELECTS.
I also found that the multinode access ignores acl view/update/delete operations. I mistakenly thought it was acl: http://drupal.org/node/347027.
I think the intention of this patch is great but there is a lot of work to do to get it to be of use to people in different situations. Ideally it should be independent of TAC or og_roles or any other module. I am able to disabled TAC after I install and it doesn't matter since once the table is built then node.module accesses it and the multinode access form continues to work.
Later:
Rather than attempt to provide more than one sql statement (which I realise now wouldn't work with _node_access_where_sql())I have changed the relevant section in node_access_grants_sql() from:
if ($logic == 'OR') {
$this_query = "OR ". $alias ."nid IN (SELECT ". $alias ."nid FROM {node_access} ". $node_access_alias ." WHERE ";
} else {
$this_query = "AND ". $alias ."nid IN (SELECT ". $alias ."nid FROM {node_access} ". $node_access_alias ." WHERE ";
}
$this_query = $this_query .'('. implode(' OR ', $clauses) .')) ';
$subquery[$this_query] = $weight;
to this:
if ($logic == 'OR') {$this_query = "OR ";
$this_query = $this_query .'('. implode(' OR ', $clauses) .') ';
} else {
$this_query = "AND (SELECT COUNT(*) FROM {node_access} ". $node_access_alias ." WHERE nid=$nid AND ";
$this_query = $this_query .'('. implode(' OR ', $clauses) .'))>0 ';
}
$subquery[$this_query] = $weight;
which meant adding an extra argument to the function as follows:
node_access_grants_sql($op = 'view', $node_access_alias = NULL, $uid = NULL, $status = TRUE, $nid=0)
($nid=0)
and adding that to all the relevant places in node.module.
In order to work correctly AND'd modules need to have lower weighting because as soon as the script reaches an 'OR' it abandons ship straight away with a TRUE result.
Kent Parker
Web development
Kent Parker
Web development
The Drupal Node Access / Grants System is Not Simple
You're absolutely correct. You should know that my original effort here was to find a way for TAC and OG to cooperate to allow enterprise level access rules instead of the simple one or the other access mechanism which is the default core behaviour.
Also, the original intent of the Multinode Access UI was to create an easier way for end-users to coordinate the access rules between TAC and OG. The original multinode access mechanism (created by agentrickard) required users to modify existing code and/or create their own access modules.
All of this always assumed that the end-user was familiar with how the Drupal node access system works and what they wanted to accomplish.
This stuff is simply too complicated to create a simple user interface to control it. I made an attempt here, but there wasn't enough support for this particular solution: http://drupal.org/node/196922
I've created documentation on how to get TAC/OG ACL and Content Access working. It does work. And, for the time being, that's it as far as OGUR is concerned.
There is work being done here: http://groups.drupal.org/node/14419 with hook_nodeapi('access') and drupal_alter after hook_node_access_records() and hook_node_grants(). The original OGUR TAC/OG integration utilized hook_nodeapi('access') way back in the early days. However, it had to rely on a very complicated and customized hook_db_rewrite_sql(). This new drupal_alter hook may resolve that problem.
Thanks for your work and for sharing it with us all.
I think you miss my point,
I think you miss my point, which is regarding the script that you have written, and how it could do with some improvement especially those monstor SQLs mentioned in my previous comment and how it ignores ACL view/update/delete
Also, have you actually tried it with an AND argument? Basically it doesn't work. In order to work it has to be grouped like this:
OR (conditionA AND conditionB)
but if you group two modules with your script the lower weighted one takes the external logic but the higher weighted one has its logic ignored and replaced with an OR, so you get this
OR (conditionA OR conditionB) which achieves nothing.
Maybe the particular version of the mulitinode patch I got was an earlier one, I don't know, but you need to do a lot more testing before you submit this as a reasonable solution.
I don't think that node_access is necessarily all that complicated but you have a tendency to make it more complicated than it is.
Kent Parker
Web development
Kent Parker
Web development
I get your point.
The intention of this patch is NOT to be of use to people in different situations. It is to be of use to people who wish to use it in the situation described at the very top of this story.
I don't doubt that it could use some improvement. However, since I use it myself with ACL, I can't say I agree that it ignores it altogether.
Yes. Getting TAC and OG to work together, something OGUR with this patch has done successfully for quite some time, REQUIRES an AND argument. See the very top of this story.
(all OR og) AND (tac) OR (ogr) OR (ca) OR (acl)All that said, if there is a way to simplify it and make it work for others in other situations, I am open to that.
Honestly? Because that's what the original code I built upon did. It worked, so I used it. You've come along and re-thunk the issue. That's how modules are improved.
I do like your suggestions on simplifying the sql statements. Believe it or not, I realized early on the need for the addtional argument $nid. While I dared to modify the core node.module, I still wanted to avoid something like this (adding an argument to functions that may be called by other modules) as much as possible -- unless the goal is to eventually submit this as an improvement to the node.module itself (not just to make my patch work more efficiently). That becomes a harder nut to crack.
So, my questions to you, as I look at this again are:
What do you think would be the overall positive effect (and possible negative effects) of adding that additional argument?:
node_access_grants_sql($op = 'view', $node_access_alias = NULL, $uid = NULL, $status = TRUE, $nid=0)How does making this change help those who may not be using OGUR or TAC at all?
Any thoughts on how do we make this easy for the end user?
Thanks for your reply. I
Thanks for your reply.
The node_access_grants_sql is not part of Drupal Core but part of the patch so there is no problem with changing its arguments.
I think the best implementation of this functionality in core would be as a hook, such as:
if(function_exists(hook_node_access)) do custom node_accesselse do default drupal node_access
Not everyone uses any form of node_access.
I think your functionality is a brilliant idea but I think in its current form it is too complicated. I've rewritten the multinode access part of it as a separate module and am currently testing it. I haven't looked at the acl functionality yet.
I would attach the module to this comment but it won't accept .zip files so I'll find another way.
Kent Parker
Web development
Kent Parker
Web development
I think it's worth looking at.
Could you attach the .module and .info files as .txt files? i.e., your.module.txt and your.info.txt.
Also attach the modified patch.
Is this for 5.x or 6.x? I think at this point we should be working in 6.x.
Thanks.
This is for 5.x. Attached.
This is for 5.x. Attached. The modification is not the whole patch just the node_access_grants_sql, so you need to add the extra parameter (in bold) in the node_access function where it calls the new grants_sql function.
$grants_sql = node_access_grants_sql($op, NULL, $user->uid, $node->status, $node->nid);
This module is written using syntax such as:
(acl) OR (og_public AND content_access_rid) OR (tac)
OR logic (which is Drupal default) can be treated quite differently from AND logic, which requires comparison between more than one node_access record (in order to ascertain that both are present). OR logic only requires one particular record to be present.
In the above example, og_public and content_access_rid are grouped, og_public would have the lower weight, be associated with an OR and content_access_rid would be associated with an AND. Weighting for OR relations has no meaning. It doesn't matter where in the relationship the modules appear, as soon as an OR is found to be true, then access is granted.
The weighting system could be replaced by something simpler such as asking the user to indicate which modules they want to create AND relationships between. Then the script automatically groups them and puts them in a relationship as in the example above.
The comment will only allow one attachment. Contact me via my form and I'll send the module.
Kent Parker
Web development
Kent Parker
Web development
How to: restrictions for creating content
I have been searching and reading lot's of documentation about this topic. Considering the configuration i want i'm still left with certain questions.
In Drupal 6:
Lets say i want 3 grouptypes(groupnodes) sitewide. A, B, and C.
And sitewide i have 3 different types of content that act as groupposts. pages, story, blog.
Restrictions (the ones that are causing me some shorter nights lately)are the following:
1.All groupposts should be able to be posted by all groupmembers except for blogs, they only should be able to be created/published by groupadmins.
2.All three content types should be able to be posted in a group, except for blogs. In group C, members (except for groupadmin) shouldn't be able to create/publish blogs.
If someone here has ran into or heard from a simular configuration i would appreciate it very much to hear some recommendations (modules or combinations of modules) or pointers in directions which i can search into.
Thanks,
Byron