Implementing user-specific, role-based access control per node type, per group. (Part 3)

Practical node access system with Organic Groups

OG approached the node access system in a way which only requires the user to be a member of a community in order to see all of it’s nodes, whatever types they are.

Therefore, og_access module defines an og_subscriber realm and sets the grant id to always be the group id. So for example, in the node_access table we have a record for node id 10 (some story/page node content type) and it’s gid (grant_id, remember?) set to group id 50 (this is showing up in the right side of the illustration).

The node access resolution scales

Next, what happens when the user actually attempts to view this node id 10?
OG also implements a hook_user() upon which when the user object is loaded it adds to it an array of all of the user’s group memberships. So when the node access process happens (i.e: in node_load()) OG’s hook_node_grants() looks at the user object for it’s list of groups and builds an array of grants from it (this is illustrated in the left side)

Drupal then builds those returned grants from OG’s og_access module and turn it into a WHERE clause query. In the example above, the user will be denied access since the returned grant ids are 5 and 10. Meaning the user is a member of group ids 5 and 10, while node id 10 (or even node id 11, added just for example purposes) is associated with group id 50, which the user is not a member of.