The Organic groups module has been a long time and has served Drupal developers with a nice alternative to the classic Forum feature, where the concept of forums are replaced by a completely flexible, community managed, collection of user groups. It's sometimes even used as a more generic toolkit for controlling access to different parts of a web site.

The access control in OG basically has two parts: policies for group membership and access to group content. The first part means you can have groups that anyone can become a member of, groups where membership is strictly controlled by an admin, or groups that do something in between. The second part is about the actual content: you can decide on a group basis if just members or everyone should be able to see it, and you can make the same choice for each post within a group.

The problem

Although you can choose whether or not some group or some post should be private (members only) or public – sometimes what you want is something in between. Imagine an organization that wants an intranet kind of solution based on OG. Obviously, it's important that all internal content is hidden from the open public. This could be achieved by only having private groups with private content, but that means that members of the organization can only see groups that they belong to. This makes it impossible to take advantage of the organic nature of OG, simply because users can't tell what groups are available, and they can't see any of their content, until they've been assigned to the groups by an administrator.

As been pointed out in a comment to this post, a way of dealing with this is to block the "access content" permission for anonymous users, but that doesn't work if you want to have some other content that is readable by everyone on the same site. What we wanted was a solution where OGs public groups and posts were public only to members of the organization – not to the general public – while keeping other content open. This particular use case is not possible to achieve out of the box.

Making things public – to some

Two things make it possible for us to work around this problem without actually changing any code in OG. One is the relative flexibility of Drupal's node access system, which makes it possible for us to create a module which defines access grants side by side with OG's. The other is the undocumented hook_og_access_grants_alter() (invoked at the bottom of og_access_node_access_records()), which makes it possible to hook into OG's access grants and alter them.

Since we finished our own implementation of this, a module has been released which uses this approach: OG Access Roles. What it does is that it adds a new setting for individual group posts which allows you to not just make them private or public, but also to specify specific user groups that should be allowed to view the post.

Our approach is a little simpler: it doesn't add any extra settings, but rather makes it so that "public" in fact means "public to authenticated users", which actually suits us better since it saves our client from having to do any extra clicks. It also provides a simple example of how to use the node access system, so let's have a look at how it's done.

The solution

What's required for this implementation is a module containing four functions, each implementing a separate hook. They are all listed here, including some explanation of each. The code assumes you're creating a module called mymodule.

First, the hook_node_access_explain() implementation simply defines and explains our grant realm, which is what will grant access to public nodes for authenticated users.

Then, we implement hook_node_access_records(), which takes a node that the node access system sends to it, and decides if this grant should be used for the particular node. If the node is a public OG post, the grant is added. If not, this function doesn't do anything.

Then, we implement hook_node_grants() to define if a specific user account is granted view access.

There is still one missing piece. We've now added our own custom node access grant for public OG nodes. But OG is still doing the same thing on its end, which means there is a potential problem that it will override what we're trying to do. There is a weighting principle in the node access system which would allow us to override OGs public grants, but we've found that doing this may also override OG's private grants, effectively making private nodes public.

In order to avoid any confusion, we use hook_og_access_grants_alter() to strip out OG's public grants before they are returned to the node access system. The nodes that would've received this grant will get our custom grant instead, in mymodule_node_access_records().

Conclusion

Node access is a rather complicated area, so it's probably wise to avoid doing custom development with it as much as possible. But as we know, sometimes standard solutions just don't cover our needs. In this post we've shown that creating a simple node access module doesn't have to be that difficult, and that whenever there's a problem, there is (almost) always a hook to help fix it.