Grayside.Org - spaces

Kicking Off OG Privacy

Grayside — Mon, 16 Aug 2010 20:38:15 +0000

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

access

Spaces Integrating a CCK Field

Grayside — Mon, 26 Jul 2010 20:25:09 +0000

I wanted to make a CCK Field available only when a given feature was enabled. It turns out it’s really easy.

CCK comes with a hook_field_access() hook (see content_access()). Any implementation of this function that returns FALSE for a given field results in that field being denied to the user.

By implementing this function with a Spaces API call instead of the content_permissions module approach of a new, field-specific permission, all kinds of magic becomes possible.

Read on for demonstration code.

/**
 * Implementation of hook_field_access().
 * Allow View/Edit access to 'field_my_cck_field' only when 'feature_name' is enabled.
 */
function custom_field_access($op, $field, $account, $node = NULL) {
  // Be sure not to affect other fields.
  if ($field['field_name'] != 'field_my_cck_field') {
    return TRUE;
  }
  
  switch ($op) {
    case 'edit':
    case 'view':
      // Make access contingent on whether a given feature is enabled in the current space, such as atrium_book.
      return spaces_access_feature('view', 'feature_name');
  }
}

EDIT: Issue posted to the Spaces queue with patch to add this functionality generically for all fields.

Terms:

Integrating Some Other Feature with Spaces

Grayside — Fri, 23 Jul 2010 16:10:17 +0000

I have found more than once a situation in which I had a basic feature that could be used on any site which I would like to see integrated with Spaces (for OpenAtrium magic). It usually runs like this:

I have the FeatureServer feature.
I want it in OpenAtrium.
Here’s a new Feature that provides some Contexts and some Groups variables.
Here’s a patch that you must apply to FeatureServer to make Spaces aware of it. (And other stuff).

#4 is a pain, but I’ve recently discovered how to shrink it down a little more: hook_system_info_alter().

/**
 * Implementation of hook_system_info_alter().
 */
function my_atrium_savvy_feature_system_info_alter(&$info, $row) {
  if ($row->name == 'some_other_feature') {
    $info['spaces']['types'][] = 'og';
  }
}

This hook is called from features_get_info() in features.module. The hook allows you to changes all the info files settings of a feature. Note: Row is apparently a huge variable to dump to the screen.

Terms:

openatrium

spaces

features

Optional Spaces Integration for a View

Grayside — Tue, 15 Jun 2010 21:05:02 +0000

If you want to make an exported [node-based] View smoothly integrate with Spaces, you can use the following code to modify the View structure with the “Content in current space” filter. This filter does nothing if the View is not itself in a Space, otherwise it restricts all results to content in the same space. Add any conditions you want to control whether the Spaces integration is applied.

/**
 * Implementation of hook_views_default_views_alter().
 */ 
function custom_views_default_views_alter(&$views) {
  if (module_exists('spaces')) {
    $views['view_name_here']->display['default']->display_options['filters']['current'] = array(
      'operator' => 'all',
      'value' => '',
      'group' => '0',
      'exposed' => FALSE,
      'expose' => array(
        'operator' => FALSE,
        'label' => '',
      ),
      'id' => 'current',
      'table' => 'spaces',
      'field' => 'current',
      'relationship' => 'none',
    );
  }
}

If you would like to take it a step further, and create OpenAtrium features integration, insert the following:

$views['view_name_here']->display['default']->display_options['access'] = array(
  'type' => 'atrium_feature',
  'spaces_feature' => 'feature_name',
  'perm' => 'access content', // or any other permission
);

hook_views_default_views_alter() fires off before the View is cached, so be sure to clear your cache after adding this code to see the results.

This code snippet is a finding from my work on OpenAtrium-FeatureServer integration.

Terms:

drupal

views

spaces

Spaces Private Content

Grayside — Wed, 31 Mar 2010 16:35:05 +0000

> Replaced with a project on D.O: OG Privacy

Terms:

permissions

openatrium

spaces

Simple Spaces Recipe for a Static Welcome Widget

Grayside — Sun, 07 Mar 2010 08:33:50 +0000

One of the little conundrums in OpenAtrium (and I imagine in Spaces) is building static content for the space. (Or in OpenAtrium terms, getting a nice dashboard box to stay put, yet be customizable by group.)

There are countless ways of doing this, but I opted to create a CCK Textarea field in my group content type (named field_group_welcome_message) and turn on the PHP filter.

Then I created a Box (which is what OpenAtrium uses, could just as well have been a block) using the following snippet:

$space = spaces_get_space();
$text = $space->group->field_group_welcome_message[0]['value'];
 
if ($text != NULL) {
  $format = $space->group->field_group_welcome_message[0]['format'];
  $text = check_markup($text, $format, '', TRUE);
}
else {
  $text = $space->group->og_description;
}
print $text;

The bit about $format and check_markup is only relevant if you turn on input filtering for your textarea. Can’t figure why you would not do that. UPDATE: Added a check for a null welcome message. If there is none, the group description will be inserted.

Now, whenever anyone goes to edit the group node/group settings, they are also offered the chance to play with the welcome message. You could just as well use this technique to pull out the Body of the group node, if that’s available. In OpenAtrium it’s removed, since it doesn’t fit into the dashboard concept without this kind of magic.

You could just as easily build some kind of zany view to achieve the same result, but you’d still need to do something to mark your target content uniquely. This method seems the most straightforward for the end-user.

I will update this another time with information about enabling such a block by default.

Terms: