Grayside.Org

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.

If you are using Feeds to migrate site content, one of the stumbling blocks will be preserving content ownership.

This code is taken from a hypothetical feeds_usermapper module that provides the option to sync up node ownership on the basis of identical usernames. (Pulled from User Inheritance Issue on D.O)

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.

Replaced with a project on D.O: OG Privacy

Freelinking 1.x was previously announced as feature-frozen, and the next thing to unsupported. Looking at the long development cycle for Freelinking 3 reaching stability, the issue queue was dusted off.

Freelinking 1.9 will fix a number of bugs in 1.8, and smooth out the transition to FL3. Please go on over to the Freelinking homepage and download the dev version to try it out.

Freelinking 1.9 will be released this week.

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:

Previously, I discussed how you could move CCK fields into the node form sidebar by careful fieldgroup naming.

If you are of a programmer’s bent, you might instead try the more flexible programmer’s solution—preprocessor function. I dug this out of the atrium_blog feature.

Do you like the large gray “Add Blog entry” button when you first visit your blog space, and have yet to create anything? Creating views with similar buttons (or adding more) is really easy!

The key is to create Empty text in your view using the Full HTML Input Format. Then, drop some HTML in like this to make use of Atrium’s built-in theming.

The Prepopulate module works some great magic to preload forms from URL variables. But suppose you need some extra magic to modify the titles it puts in place?

You can always use hook_form_alter (and here is one of countless little tutorials on that).

If you already know about that, you might be someone that enjoys the use of hook_form_FORM_ID_alter(). If you do, you cannot use it to override Prepopulate-set fields. It turns out that regardless of module weight, hook_form_FORM_ID_alter is called before hook_form_alter for any given form, meaning that the more specific function will always set the value, then Prepopulate will come along and reset it to your URL value.

There is a nice issue (#300481) that details this problem, and hopefully will find itself fixed in Drupal 8.

You might wonder how cases are considered “closed” for purposes of case filtering in the Case Tracker. It’s an attempt to be helpful on the Case Tracker’s part– hide the stuff that is no longer relevant unless the user specifically asks for it. Unfortunately, I don’t like the defaults on what it considers irrelevant.