spaces

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.

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.

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:

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.

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.