Compatibility with Organic Groups

Update:

This feature request is probably a false alarm. I actually found that content access works best in relation with organic groups if these defaults remain as they are. There was a false assumption made that content access roles and organic groups should be OR'd but in fact they are better if they are AND'd. See: http://groups.drupal.org/node/5392#comment-58684

Update 2:

Because content_access uses realm='all' to build the node_access table rather than realm="content_access_rid" the AND does not work out-of-the-box, and instead requires the following modification:

Instead of resetting the default values in content_access_get_setting_defaults(), this requires commenting out the following lines:

$grants = content_access_get_default_grant($node);
content_access_optimize_grants($grants, $node);

and adding the following:

$grants[] = array('grant_view' => 1, 'realm' => 'content_access_rid', 'gid' => 1);
$grants[] = array('grant_view' => 1, 'realm' => 'content_access_rid', 'gid' => 2);

in content_access_node_access_records() so that when the permissions table is built then all the nodes have an content_access_rid grant for anonymous and authenticated users and none are given realm='all' and full access to all users. Obviously the latter is necessary for content access working by itself, but when working in an AND relationship with organic groups using Multinode Access it always tests for a content_access_rid grant and not a realm=all.

The AND relationship between content access and organic groups means that a user can make a public group node private, or shared amongst a specific role or a user can make a private group node accessible to specific users (with acl).

So the feature request would be that if you wanted to go down this route of compatibility with organic groups then all you would need would be the ability to unset these two function calls through the admin UI.

Following is the modified script for content_access_node_access_records()

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;
}

Setting up multinode access is reasonably difficult and is only necessary in sites with complex permissions arrangements. The system that I got going works something like this:

organic groups AND content_access rid OR content_access acl

In other words organic groups and content access roles are AND'd.

This means that you can make a group private simply by making it private in the group setting. If you have organic groups OR content_access, then you have to make both the group private AND go and unset anonymous and whatever other users in the content type for content_access in order to make the group private. This seems unwieldy. With acl, on top of this, you can selectively invite users into individual nodes in a private group.

With public groups the AND also means that you can use content_access role permissions to limit viewability by role and then you can turn round and revert that for some individuals in that role by using acl.

The AND relationship offers huge flexibility in how you manage your nodes. There is no need to do anything to core and the modification to content_access.module is very simple. (I won't say the same for understanding multinode access and putting in all the patches required there!)

So if you
are using multiple node access modules, access will be granted to a node as soon as one of the
module grants access to it.

Yes, this is true if you set up the site as is recommended with OR relationships between groups, content_access roles and content_access acl. With an AND relationship between groups and content_access roles you can turn access off by turning off EITHER groups or content_access roles. (Note that these are settings made in the UI for multinode access. This is not a hack but an alternative setting arrangement. See instructions at: http://groups.drupal.org/node/5392#comment-58684)

With the OR relationship, in a public group you are stuck with the content ALWAYS being accessible because it is a public group. You have to set the group to subscriber only or to private in order to change anything. To me this seems less useful than the AND relationship. It comes down to choice and what the site requirements are.

In a site with the above configuration I am able to make a node in a public group private by using the content_access settings. The AND relationship means that I can control that node FULLY with content_access and I don't have to worry about what the group settings are. When a group is set to subscriber only or private then I can use content_access to mimic og_user_roles because now all the role access settings ONLY work within the group.