Grayside.Org - openatrium

Adding a Content Type to the Open Atrium Calendar Views

Grayside — Wed, 08 Sep 2010 23:04:50 +0000

People often seem to wonder how they can get their new date-specified content types to show up on the Atrium Calendar. The following Views snippet makes it happen for a content type called “example_type” in module “custom”. Note that this code is specific to the Views as they were renamed for Kit-compatibility in Open Atrium 1.0-beta8.

Step 1

Build your “example_type” content type. You can build this out however you want, but for the purpose of this post you need to add the same field_date that the Event type uses.

Step 2

/**
 * Implementation of hook_views_default_views_alter().
 */
function custom_views_default_views_alter(&$views) {
  $views['calendar_listing']->display['default']->display_options['filters']['type']['value']['example_type'] = 'example_type';
  $views['calendar_upcoming']->display['default']->display_options['filters']['type']['value']['example_type'] = 'example_type';
}

Why Not Override the View with Views UI?

Once you have overridden the core Views in Atrium, you take a potentially stressful upgrade/maintenance path and make it vaguely nightmarish. Your changes will disappear into the ether when you upgrade. Restoring your changes would require building out a site based on a backup database to grab the key pieces of your override.

By keeping these changes in code, you can much more easily determine how to fix them… assuming any changes are even necessary!

Happy calendar hooking.

Terms:

openatrium

views

calendar

Adding Items to the Open Atrium Settings Menu

Grayside — Tue, 24 Aug 2010 16:55:07 +0000

Recently I dusted off OG Vocabularies with an eye toward integration with OpenAtrium. To my mild surprise, there was really not much that needed to be done. The menu path (node/%node/og/vocab) isn’t great, but that can be tackled later.

All I wanted was to avoid another hidden tab that can only be reached by clicking on Settings > Customize Features. I wanted the group vocabularies to be accessible directly in the Settings menu.

It turns out it’s really simple. There is a hook.

/**
 * Implementation of hook_atrium_admin_links_alter().
 */
function custom_atrium_admin_links_alter(&$links, $space) {
  if ($space->type == 'og') {
    $item = menu_get_item("node/{$space->id}/og/vocab");
    if ($item && $item['access']) {
      $links['og_vocab'] = array(
        'title' => t('Manage Taxonomy'),
        'href' => $item['href'],
      );
    }
  }
}

Terms:

openatrium

interface

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

Integrating the Features Server into OpenAtrium

Grayside — Thu, 03 Jun 2010 16:32:53 +0000

Working on integrating the Features Server feature into OpenAtrium. My intention is to set it up as another Casetracker Project type.

OpenAtrium provides a solid case tracker and documentation system, and is a natural fit for the infrastructure of a Drupal.Org-style project ecosphere. Integrating them will allow me to post Features I’ve created to a place where I might actually have a means to get feedback on my work, let alone provide support.

Project Status of OA Features Server feature

Features Project as a Casetracker Project ✓
Features Project automatically a Notebook ✓
Converting Projects View to a Site/Group feature. [in progress]
Trivial Modification of Features Server code to play nice with OpenAtrium and Atrium Casetracker .✓ [will ship with patch]

Conundrums

Features Server feature uses Context 2.0, OA uses Context 3.0
hook_views_default_views_alter() has limited to no best practices or examples I’ve been able to find, given it’s currently documented intention as a site-specific hook. Somehow I don’t think it’s role will remain in site-customization in the world of Features.

Terms:

drupal

openatrium

features-servers

OpenAtrium Group Manager as Content Administrator

Grayside — Thu, 06 May 2010 07:38:13 +0000

In Drupal, it only takes a couple hours (or perhaps a couple days) to build the concept of a site-wide content manager into your system. It gets mighty tricky to start parceling out administrative tasks for parts of the site.

With Organic Groups (the module behind OpenAtrium’s groups), the solution to this problem has always been messy. But with the advent of Spaces and Group Administrator configuration, it seems like OA and related sites are within shouting distance of giving Group Managers the power of Content Administration.

Between my OA Change Group and OA Book Manager modules, I’ve started experimenting with how to bring that kind of capability to light.

OA Change Group adds a new subtab to admin/content/node. That works fine, for site-wide administrators. It also allowed me to punt on the whole notion of double-checking that the logged in user has the right to post content to the destination group. But it doesn’t help group managers, except to the extent that the site admins are ready and willing to take content management tickets.

OA Book Manager takes a cue from the content-management-lite Archive feature in OA, and slaps a sub-tab into the feature it’s related to. In this case, adding a “Manage” tab to the Notebook feature.

But if OA content management is going to remain a cohesive experience for site administrators and group managers alike, a few more best practices need to be worked out, and OA needs to come packaged with more of a skeletal administration system in the groups themselves so feature-builders know what to be thinking about in working together.

Terms:

drupal

openatrium

content manager

Single Group Login Redirect

Grayside — Wed, 28 Apr 2010 21:39:37 +0000

Community.OA had a request for functionality that would redirect a user with a single group membership to that group’s homepage.

I packaged that functionality up as a Feature, so you can use it too. The oa_ prefix refers to the support for spaces_og/purl to generate a group URL.

Terms:

Changing Node Group Audience

Grayside — Mon, 12 Apr 2010 18:33:31 +0000

In OpenAtrium, it’s not easy to change the group affiliation of a node once it has been created. OA locks down the interface to set group audience specifically to make the interface easier to understand.

I have just posted a quick feature that demonstrates how to grant administrators the ability to shuffle nodes around between groups, it can be found in the issue queue at community.OA.

It introduces two things–a new Action that toggles the group audience of a given node, and a Views Bulk Operations View that allows you to apply that action to batches.

There is a special column in the View labeled “Member of Private Group”. This column lets the administrator know whether the current group is a private group, meaning the content is almost certainly private as well. Any quality of the group a node starts in will be lost once you move a node to a new group, and that includes whether it is private content. Remember that, and use with care!

Note: If you preface the URL of the View with a group namespace, it will limit the content to the nodes of that group.

Download feature from my Features Server here

Terms:

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: