16
Aug
2010
Grayside

Kicking Off OG Privacy

I’ve just published the Organic Groups Privacy module to Drupal.Org. It’s an API module intended to help give developers an easy and flexible way to define public access to Organic Groups posts. It exists specifically so I can convince Spaces that I really mean it when I say an arbitrary 90% of an Organic Group should be private.

It is bundled with a Feature that demonstrates how you might integrate it with an Open Atrium site, but the core of OG Privacy can be useful even without Spaces being in the mix at all.

With it, you can do such neat things as declare all Blog posts private to group members with a simple hook implementation:

/**
 * Implementation of hook_og_privacy_policy_info().
 */
function custom_og_privacy_policy_info($node) {
  $policies = array();
  $policies['private_blog_type'] = array(
    'access callback' => 'custom_private_blog_policy',
    'reason' => t('Blog posts are only viewable by group members.'),
  );
  return $policies;
}
 
/**
 * Blog type privacy policy callback.
 */
function og_privacy_blog_type_policy($node) {
  return $node->type != 'blog';
}

If you read through the API documentation, you will see that the above policy is implicitly non-exclusive meaning any old module could come along with it’s own policy to make a blog post visible.

For an example of an exclusive policy, which exercises supreme executive veto power to guarantee the privacy of, say, all the content from your Atrium Casetracker feature, it might look like this:

/**
 * Implementation of hook_og_privacy_policy_info().
 */
function custom_og_privacy_policy_info($node) {
  $policies = array();
  $policies['private_atrium_casetracker'] = array(
    'access callback' => 'custom_private_atrium_casetracker_policy',
    'reason' => t('Content types created by the casetracker feature are viewable only by group members.'),
    'exclusive' => TRUE,
  );
  return $policies;
}
 
/**
 * Atrium Case Tracker privacy policy callback.
 */
function og_privacy_atrium_casetracker_policy($node) {
  $map = features_get_component_map('node');
  if (!empty($map[$node->type])) {
    $feature = reset($map[$node->type]);
    return $feature != 'atrium_casetracker';
  }
  return TRUE;
}

By building your own selection of exportables and hook_form_alter() implementations around such policy definitions you can control public access very easily.

For a somewhat more detailed explanation of the guts of how this works, README.txt?view=markup">check out the README.

Terms: 
modules
spaces
og
access

9 comments

Mysterious Stranger, Wed, 08/18/2010 - 18:45

OA has a vexing problem of not being able to keep certain parts of a group private like Basecamp does with its private messaging feature. Because all users of a group (vendor and the client) start with the authenticated role, I have had to try things such as adding new roles (client, team etc.) and then muck around with permissions to try and keep things private between team members.

I suppose this code could be adapted to make this possible? Or would this first require a custom content type that can then be protected like the casetracker example you showed above?

Grayside, Fri, 08/20/2010 - 22:16

This module is intended to let you drop a hook implementation into a custom module or a Feature and create arbitrary policies. The examples above are broad sort of policies, targeting entire content types and features.

OG Privacy for Open Atrium provides an example of a finer-grained policy, putting a checkbox on every post in a group. (For groups that opt-in to advanced permissions.)

The limitations are twofold:

  1. You can base your permissions only on qualities of the node object, not on the user.
  2. The smallest group of users you can limit content to is everyone subscribed to the group.

If you want personal messaging between users, you need to look for a module other than Organic Groups. For example, you might adapt Private Message as a site-wide Atrium feature.

Share, Thu, 08/26/2010 - 23:51

hi,

I like to give my thanks to you as you share your views and ideas through your blogs which i really find very helpful to me , i am thankful to you

Thanks
Sameul John

Grayside, Thu, 09/02/2010 - 14:19

Thank you Samuel. It’s good to know they are helpful to someone else.

quiron, Wed, 09/01/2010 - 10:59

Hi, this is a realy great work, thanks!

I have been testing it and I have some problems. I tried to create a simple module wich implements this two hooks to control the access to the blog content (your first example) but I couldn’t get it working.

Have you any documentation or simple module example to start working with?

thanks a lot in advance.

Grayside, Thu, 09/02/2010 - 14:18

I’ll try to add some documentation later today. The og_privacy.api.php file has some good documentation, but reviewing it I see there might be some confusion. There is only one hook that og_privacy uses. That hook defines some explicitly named callback functions.

quiron, Tue, 09/07/2010 - 01:43

hi grayside!

Thanks a lot for the documentation improvement.

I’m using og_provacy_atrium and I have the following problem. The table content_type_group does not exist in a clear OA instalation. It is created when a new field is added to group content type. If I force the table creation in this wai I have an other error: the field doesn’t exist.

I have seen in the file og_privacy_atrium.features.content.inc that a field is defined but when I install the module it doesn’t not appear in the group form. I should do something else?

If you want we can meet up in IRC

Thanks a lot for your help.

Nico, Wed, 11/10/2010 - 06:29

Hi Grayside!

Thank you very much for this nice Module.
Unfortunally I exactly got the same Issue like quiron.

I installed alle neccessary Modules an applied the Patch for Mark. At the Content Types the
the Mark is displayed but if I want to add a Mark in the Group itself the Widget isnt present.

Is there a Solution for this? Or do I need to change some global Settings in OpenAtrium?

Thank you very much for you help, Grayside.

Marc Bria, Tue, 10/26/2010 - 02:48

Hi grayside,

First at all, thanks a lot for this module. A new door is open to a more grained access control in features+spaces developments as OpenAtrium.

We reviewed the module and we posted some feedback here: http://drupal.org/node/952282

Summarizing the post and from our perspective: Great module, but seams difficult to deal with private groups and private features.

Cheers, m.