Hello --

This is a feature we are looking to implement, and release back as (ideally) a contrib/helper module for OG. We have started looking into executing this, but we wanted to post here as a means of getting feedback and centralizing dev efforts. If there are pitfalls we should avoid/current efforts underway to develop this functionality, we'd prefer to find out sooner rather than later.

The feature involves splitting the OG admin features to allow some features to be set sitewide, while allowing other defaults to be set on a group type by group type basis.

Use Case: You have two node types set up as groups: Courses and Clubs. For Courses, you want all posts to be set to be visible only within targeted groups, and all posts to require an audience. For Clubs, you still require an audience, but you want users to be able to choose whether their post is public or private.

This refers to the admin settings currently visible at admin/og/og

As can be seen in the attached screenshot (http://drupal.org/files/og_admin_page.gif), there are 6 sections to the og admin screen:

1. Access Control
2. Group Details
3. Node Authoring Form
4. (and 4a) Group Home Page
5. Email Settings
6. Member Pictures

I would like to be able to set defaults in the following way:

A. Set 1 and 4A sitewide -- screenshot: http://drupal.org/files/site_defaults.gif

B. For every group type specified in 4A, set 2, 3, 4 (the presentation style), 5, and 6 for each individual node type -- screenshot: http://drupal.org/files/og_by_group.gif

I envision a workflow as follows:

1. After enabling OG module, the user navigates to admin/og/og/defaults (or some other good url) -- at that screen they will be able to enable/disable OG access control, and specify group nodes.

2. Once a group node has been enabled, the user can navigate to admin/og/og/defaults/groups, where the user will have a tabbed series linking to the group-specific defaults (screenshot to come on followup to this issue).

Members fund testing for the Drupal project. Drupal Association Learn more


bonobo’s picture

A fallback option would be to allow all the features of the "Node Authoring Form" to be set on a group type by group type basis, with all of the other features getting set sitewide. For what we're working on, this is the most important feature.

moshe weitzman’s picture

this is a case of defaults and overrides which is pretty complicated from a UI perspective. If we can solve the UI, implementation is fairly easy. Not only do people want per group type, but some want per group. oy.

bonobo’s picture

We're looking to set defaults by group type (ie, in a site you have two different node types that can be groups, and you can set different defaults for each node type) and *not* on a node by node basis -- while I like the idea of that much flexibility, it translates into a usability nightmare.

Toward that end, the UI I'm proposing is laid out in my original post, and really just re-organizes/streamlines the existing admin UI to reflect the new functionality:

Site wide defaults as in this screenshot.

Each group node type has a separate tab with these options.

gustav’s picture

I like this proposal very much, especially because of its simplicity. For sites that use only a single group type there is no more complexity than before. For sites that use several group types there is no confusion because this proposal avoids defaults and overrides. The latter always confused me about the way the theme admin interface works where I never know what is determined by default and what is set for each theme.

scedwar’s picture

This would be particularly useful if it combined with the option to limit the type of content that a normal user could post, whereas a group admin could post all content.

marcp’s picture

The UI isn't too bad, but I think the implementation is going to end up being a big patch to the OG code.

The easiest way out of the mess looks to be for og to provide hookable og_variable_get and og_variable_set routines. They would need to take in the group node as a parameter so that any hooks could override based on the group node.

Moshe - could a patch like this even make it into OG any time soon? Don't worry -- it won't be me writing it, so the code might actually get written in a timely manner...

moshe weitzman’s picture

@marcp = the issue isn't code - it is UI.

moshe weitzman’s picture

yes, we will need a function like og_get_variable($node, $account) or somesuch which calculates the right value based on hierarchy rules and group permission. and i would commit then when a UI acompanies it.

gustav’s picture

I like the UI that marcp has proposed.

marcp’s picture

The UI that Bill originally proposed is here:


Pretend that the tabs say "Online Course," "Discussion Group" and "Club" -- each tab is for a node type.

Moshe - are you looking for something more [or less] flexible than this?

moshe weitzman’s picture

Yes, I think thats part of the UI puzzle. Other needs are

- "it is complicated enough already. global prefs are fine for me."
- "i need certain properties to vary by group. the ui should be on the group form"

i will think about this some more. i am hoping that some clever javascript can make this UI sensible, instead of multiplying the number of preference pages.

bonobo’s picture

Some thoughts on this:

RE: "'it is complicated enough already. global prefs are fine for me.'" -- what we're proposing won't eliminate global prefs -- if there is only one content type that is used to create groups, the admin will only need to set the global preferences once. What we're proposing doesn't really add complexity, but it does open the door for increased flexibility for those people who want more than one type of group.

RE: "'i need certain properties to vary by group. the ui should be on the group form'" -- for these folks, our proposed solution doesn't preclude this. What we're proposing could come close to meeting the needs of many of these people, as it will allow for multiple types of groups with different default settings. Also, when I have talked with people who said they need to have different setting for each group, when we explored their precise needs, they were actually looking for sets of default options for different groups -- and this is something that our solution would provide. And, if someone needed more flexibility on a group by group basis (ie, the ability to override default settings, or to add additional settings to the node creation form) it would probably be possible to create that via a helper module.

With that said, though, adding in more options at node/add/group is only moving towards more complexity for the end user. What we're proposing extends the flexibility exposed to the site admin (ie, the person who sees admin/og/og) while simplifying the process for the end user (the person who sees node/add/group).

RE the javascript: yeah, this will be helpful. I also think that once we have the basic UI in place, the opportunities for cleaning up the functionality with javascript will be easier to see.

moshe weitzman’s picture

anyway, do all og prefs now become settable by content type? if a subset, what subset?

this has potential.

bonobo’s picture

Most OG prefs become settable by content type -- for the first pass, we will separate out the pref for the group details, the node authoring form, the group home page (to allow different views to serve as the home pages for different group types), email settings, and member picures, as seen in this screenshot --

The sitewide defaults would be the node types that can be used to create groups, and, of course, turning on OG access control, as pictured in this screenshot.

We actually have the backend mostly written for this, and will be adding a UI shortly after the New Year --

neurojavi’s picture


This module would be very useful to me but I'm not sure it's possible to make it work without adding some restrictions.

If you allow to create content from the main "Create content" links (not the ones in the OG details block) you will be presented with a generic node add form and you won't have any information about which group (and group type) it would belong to. So what options would you present in the form alter?
For example, if you allow the user to select the visibility of posts in TYPE A and set it to private in TYPE B, would yo show the "public" checkbox?
Other options like "audience required" would cause problems too (this has no sense in a per group type basis).

And what about allowing different node types to be used in each group type? Well, this swould be easy... a validation error.

All those problems come form the ability to add content to groups via the generic links and form the possibility to post a node to more than one group (crossposting). I have said in other posts that the "crossposting" ability is very useful in some contexts but its very hard to deal with in many others.

I think that many sites would benefit from two options to restrict this two things in the global OG configuration page. Something like that:
[ ] Show audience check boxes in the main node add pages
[X] Allow nodes to be added to more than one group (crossposting)

This would make possible modules like yours and some I'm planning to be easily developed and give a lot of new functionality to OG.

In my sites I have the following restriction: A user can only create content from inside a group (obtained via OG user roles) and have disabled the audience checkboxes in the node edits (obtained via somebodysysop patch in http://drupal.org/node/130601). This have solved a lot of problems to me in the meantime. Now my users only can add content in a group via its groups details block.

I think this would be needed for your module to work... or perhaps I'm missing something?

What do you all think?

PD: I was thinking about adding this functionality via a helper module but when I read this issue I noticed that it would be useful to other modules and perhaps it will be best to discuss it here and don't reinvent the wheel...

moshe weitzman’s picture

@neurojavi - this issue is unrelated to your recommendation. please use http://drupal.org/node/130601. and i don't see those checkboxes helping, since i would still have to support the current behavior. we are *not* goind to drop support for cross posting.

tannerjfco’s picture

This sounds like what I've been looking into for my site. Basically I would like 3 types of groups:

1)A generic group type that allows standard posts for discussions

2)A group type that allows posts of generic discussions, images, and collaborative screenwriting

3)A group type that allows posts of generic discussions and other post types (yet to be determined) that facilitate the physical meeting of people for projects

Basically, I just need different node types to be allowed for different group types. From what I've gathered, the idea proposed sounds like the answer. If it's not, or if this is already possible, please by all means let me know, I've been trying to figure out how to accomplish this.

neurojavi’s picture


moshe, you said that this issue is unrelated to my recommendation. Well, I agree this is another issue but I don't agree it's unrelated to this one.
The problem I've explained in my previous post is still there: there are some global params in the "node authoring form" that can't be configured per group type if a node can be posted to more than one group.
Beeing the previous true (that's the question), then the module bonobo is tying to develop seems to be not viable... In that case, perhaps you may want to mark this issue as "By dessing" and close it?

I only tried to explain how I have solved similar problems in my sites... If we want this kind of functionality we would need to renounce to crossposting functionality (in my modest opinion). I think we can't have the two things working at the same time.
Since this issue is a RFC I only was commenting about it...

I'm planing a module that implements this and other modifications but it would be nice to see this basic functionality added to OG (perhaps a patch?). I'm not suggesting to drop the support for crossposting, I only said it would be very useful to make it optional so other modules can check the configuration and reject to run unless the crossposting setting is disabled (for example).

In any case I'll use http://drupal.org/node/130601 as you stated when I have the time to work on this. Or even better I'll open a RFC here or in groups.drupal...

But the key question here is... Is the functionality proposed by bonobo possible with OG alone and its hardcoded crossposting support?


PD: Sorry for my english... I suspect that sometimes I can't explain myself as I would like to do...

moshe weitzman’s picture

what bonobo suggests should be possible today in a separate module using hook_form_alter() but it would be a lot of work to get it to work right for all cases of preferences. this really should be done in og, and i intend to do something like it.

my current thought is that for every pref, you will first choose if it should be global (like today), vary by content type, or vary by group. if by content type, another selector instantly appears where you set the value for each type. this UI handles all the possible cases, and should be compact. I don't like much the sprawling tabs that bonobo starts with.

i welcome with in coding/designing this UI further.

bonobo’s picture

RE: "I don't like much the sprawling tabs that bonobo starts with." --

Yeah, we didn't like them much either -- we're using a different UI that lists out the group node types.

As always, the proof is in what shows onscreen -- we have something loosely set against OG 5.x-4.x, but we need to upgrade/test against the RC

@neurojavi -- what you suggest is interesting, but, unfortunately, is outside the scope of what we're trying to accomplish

We'll post back here when we have a solid version -- given the other priorities we are balancing it should be somewhere about 2 weeks from now.

moshe weitzman’s picture

Title: RFC -- Best method to reorganize OG Admin pages » User interface for preferences to vary by content type or by group

Here my current thinking - there are about 5 properties which an admin might want to set as 'per group', per content type, or global. so, i propose a table which lists a row for each of these properties. each row will consist of 3 columns: 'property title & description', 'scope', and 'value'. 'scope' contains 3 radio buttons: per group, per content type, global. 'value' depends on the property but it is basically the radios you see now for 'list in diectory' and so on. The form element in the value column can change if an admin changes the value of scope. When scope is 'content type. we'll need two form fields on the value column - one that selects a content type and a second that shows the values.

This sort of dynamic form is really hard to do in D5, but hopefully easier in D6 so I don't expect to code this until we move to 6. If folks want that to happen quickly, please lend a hand to the Views team. Thats what blocks progress for the OG port.

jgraham’s picture

Hi Moshe,

I'm working with bonobo and marcp on implementation for this.

You mention "there are 5 properties which an admin might want to set as 'per group', per content type, or global." I'm just curious why only 5? To me it seems there are only about two settings which are definitively "global only." Those 2 being og_node_types, and access control. It seems to me all other settings could potentially be useful in a group type specific or group specific (gid) setting.

I have a patch (against og-5.x-4.1) for og that implements the replacement of variable_get, with og_variable_get simliar to marcp's suggestion above. However, I have adjusted it as follows;
prototype: function og_variable_get($variable, $default, $type = '', $gid = 0)
where $type is optional and one of og_node_types
where $gid is optional and is a organic group id
- if $type and $gid are missing the function behaves exactly like variable_get (it fails gracefully to existing functionality)
- if $gid is present (most specific setting) it tries to recover settings for that particular gid, if gid specific settings are not available it falls back to $type specific (note if $type is omitted, but $gid is present we can recover type via $node->type where $node->nid == $gid) failing that fall back to global setting
- if $type is present return the group type specific setting failing to a generic global setting, or the supplied default if necessary.

Stopping here this patch would allow third party modules to implement a myriad of adjustments to the og settings. As is this patch allows our module to rewrite the og settings form to accomodate general, group type, and node specific (not implemented). All while retaining the existing functionality of og unchanged. This allows for third party modules to allow for all sorts of use cases that may not make sense generically.

Does this look like something you are interested in committing or are you looking for something else entirely? If you are interested I can rework the patch to point against a preferred (current) version of the module. If not is there anyway I can help to get this moving along quicker?

brst t’s picture

20131102 - removed by author

rconstantine’s picture

@scedwar, check out my Content Type Administration by Organic Group module to control content types available by group. Site admins choose site-wide, and default group settings and can override individual groups' settings. Group owners can also decide which types to allow their users to use and which to reserve for themselves.

edit: huh? I'm not sure how this got posted twice, and only partially.

rconstantine’s picture

@scedwar, check out my Content Type Administration by Organic Group module to control content types available by group. Site admins choose site-wide, and default group settings and can override individual groups' settings. Group owners can also decide which types to allow their users to use and which to reserve for themselves.

Naturally, as I have already implemented (fairly successfully as reported to me by users) content type by group functionality, I don't see any reason to include such in the general changes this thread talks about. I think there were only a couple of people that brought that up. I see them as two issues and I think that the direction things seem to be moving is a good one. None of the general OG settings now cover whether content types can be used in a group, but rather cover whether the audience targeting should be used. There is a subtle difference and I think that that portion of settings should remain in the global settings.

But of course, I'm biased, so take that with a grain of salt.

jgraham’s picture

34.04 KB

Adding patch for og-5.x-5.0

SomebodySysop’s picture

This sounds like what I've been looking into for my site. Basically I would like 3 types of groups:

1)A generic group type that allows standard posts for discussions

2)A group type that allows posts of generic discussions, images, and collaborative screenwriting

3)A group type that allows posts of generic discussions and other post types (yet to be determined) that facilitate the physical meeting of people for projects

Basically, I just need different node types to be allowed for different group types. From what I've gathered, the idea proposed sounds like the answer. If it's not, or if this is already possible, please by all means let me know, I've been trying to figure out how to accomplish this.

OG User Roles. You can use the same group type, but different roles for different users in different groups to accomplish same.

I think the current OG settings are fine, but I like the idea of being able to use them on a per group basis (different default home page, different audience checkbox preferences, etc...)

SomebodySysop’s picture

In OG User Roles, I wanted to create optional group settings that would appear in the settings page for the individual group. I used this method in hook_form_alter:

  // If this is a group node edit (use og_last to determine if this is a group node) 
  if (arg(0) == 'node' && ($_SESSION['og_last']->nid == arg(1)) && arg(2) == 'edit' ) {
    $gid = arg(1);

    // First, we need to get a list of all og-enabled node types
    $group_types = variable_get('og_node_types', array('og'));
    foreach ($group_types as $type) {
      // Get list of assignable group roles for this group type
      $role_ids = variable_get("og_user_roles_roles_{$type}", array());
      $all_roles = user_roles();
      foreach ($role_ids as $rid => $checked) {
        if ($checked != 0) {
          $roles[$rid] = $all_roles[$rid];
      // If the form loaded is this type then we can move on
      if ($type != '' && $form_id == $type . "_node_form")  {

        // Add the code to disallow public posts to the
        // group edit form.

          $form['og_user_roles_nopublic_gid'] = array(
            '#type' => 'fieldset',
            '#title' => t('Disallow public posts in this group.'),
            '#description' => t('Allows you to prevent any <strong>Public</strong> posts from this group.  That is, no post made in this group may have the <strong>Public</strong> box checked.  In addition, if OG Forums is installed and this is a group <strong>Forum topic</strong> post, then the forum group selected in the <strong>Forums</strong> pull-down menu on the edit form must match this group, or the post will be rejected.'),
            '#collapsible' => TRUE,
          $form['og_user_roles_nopublic_gid']['og_user_roles_assign_nopublic_' . $gid] = array(
            '#type' => 'checkbox',
            '#title' => t('Do not allow public posts in this group?'),
            '#default_value' => variable_get('og_user_roles_assign_nopublic_' . $gid, 0),
            '#description' => t('Do you wish to disallow public postings from this group?'),
          $form['#submit'] += array('og_user_roles_nopublic_form_submit' => array($form_id, &$form));          

So, instead of using variable_get('og_user_roles_assign_nopublic_' . $gid, 0), I could now use og_variable_get('og_user_roles_assign_nopublic', 0, '', $gid) in order to track variables that would appear on individual group settings pages? Sounds great.

But, what do I use to actually set the variable?

function og_user_roles_nopublic_form_submit($form_id, $form_values) {
  $gid = arg(1);
  variable_set('og_user_roles_assign_nopublic_' . $gid, $form_values['og_user_roles_assign_nopublic_' . $gid]);

I don't see an equivalent og_variable_set function. Or, am I missing the point here?

rconstantine’s picture

See also this: http://drupal.org/node/148462 for accomplishing this another way

jgraham’s picture

If I understand the linked issue (in #29) correctly it only accomplishes a subset of the behavior. We are targeting nearly every (existing) OG setting to have a different default at the group type level.

The two exceptions are;
"Organic groups access control" I don't think this makes sense to be configurable at the group type level
"Group home page node types" Defines the group types

We currently have a helper module that implements this UI, but it is entirely dependent upon the patch referenced here.

From my understanding the linked issue only targets "omitted content types" at the group type level. This is certainly inline with the functionality provided by the 'og_content_type_admin' module.

bonobo’s picture

Version: 5.x-4.0 » 5.x-5.0

Agree with Jeff in #30 --

The solution we are working toward does not touch the types of nodes allowed in different group types. IMO, that is best handled via a helper module, and not within the context of this small patch.

Also, re-setting status to reflect patch in #26.

rconstantine’s picture

The comment at #29 was specifically for #27. I agree that the other things should all be separate and that my module would be in addition to what you are trying here. Sorry to confuse the issue.

moshe weitzman’s picture

I reviewed #26 and it is on a good track. A few minor nits:

* does not apply cleanly
* og_node_types and og_enabled should not run through og_variable_get().
* $type = '' should be $type = NULL.

Also, we detect that a group specific override is not present by checking for a value of ''. that is a bad idea, because that is a legitimate value(). i would suggest checking for a non sense value like ||foo|| or somesuch.

moshe weitzman’s picture

Status: Active » Needs work
jgraham’s picture

Version: 5.x-5.0 » master
Status: Needs work » Needs review
30.81 KB

Hi Moshe,

Thanks for taking the time to review the patch.

I have reworked the patch as per your suggestions against HEAD this time. The conflicts seemed to all be resultant from moving to 'members' vs. 'subscribers'.

I believe I have addressed all of your outlined issues. Please bring it to my attention if that is not the case. Also, I hope I changed the ticket tags appropriately I was unsure if I should have assigned myself or unassigned bonobo so I left as is.


moshe weitzman’s picture

It seems that we are pretty inconsistent about passing the optional $type and $gid arguments to og_variable_get(). It sometimes takes further refactoring to make those available when you need them.

How about we remove those params from og_variable_get() and just determine them as follows:

if ($group_node = og_get_group_context()) {
  $type = $group_type;
  $gid = $group->nid;
  // do stuff

// No overrides found. Use global value 
$return = variable_get($prefix.$variable, $default);
return $return;

moshe weitzman’s picture

Status: Needs review » Needs work
jgraham’s picture

At first I was a bit concerned about how group context is determined. However, I think the only potential issue with this method is how this behaves when visiting a node that has its audience set to multiple different groups or group types. Can you comment on that situation?

Also the behavior on node add may need some consideration. I assume this is a similar case to that above.

I have also better documented the variable naming convention in og_variable_get().

jgraham’s picture

Status: Needs work » Needs review
moshe weitzman’s picture

Well, the code that chooses a group context when viewing a cross posted node has always been a bit of a controversy. The current logic is visible in og_set_theme()

1. pick the same context of the prior page view
2. if above makes no sense, pick a group that the user is a member of
3. pick the first group in the list of groups

I agree that crossposts could make my proposal wacky but I'm willing to explore it. Perhaps we keep the function signature as you've proposed but if no group/type are sent, we set them based on og_get_group_context().

jgraham’s picture

One big advantage of keeping the same signature is that 3rd party mods can use og_variable_get to get a value for a particular group type or group instance and not need to be concerned with the internals of how the values are stored and/or retrieved. Using strictly og_get_group_context() in og_variable_get() a 3rd party module would need to know (and duplicate) the logic of og_variable_get() unless of course I'm missing something.

I'm still thinking about any issues with a mixed mode using the function signature I initially proposed and falling back to og_get_group_context(). It seems that explaining the behavior to the user may be the only issue since if a 3rd party mod wanted an explicit value they would provide $type and/or $gid.

ajayg’s picture

I have a suggetion to simplify the node authering part of UI here http://drupal.org/node/234815

I am thinking may be it simplifies some of the UI issues raised here.

jgraham’s picture

Hi Moshe,

I'm looking to reroll another patch for this here is what I am thinking;

  1. revert og_variable_get() to my initial signature with group type and gid as optional parameters
  2. all calls to og_variable_get() within existing og code will *not* use the optional parameters (gtype, gid)
  3. rework og_variable_get() to fallback to og_get_group_context() when gtype and gid are not present

I think this will accomplish two things. It will keep behavior across the various existing og functionality consistent by relying on og_get_group_context(), and it will allow 3rd party mods to provide context if necessary as well as og when the settings UI is reworked as the various contexts will need to be loaded arbitrarily.

Patch coming soon.

anantagati’s picture


jgraham’s picture

Patched against DRUPAL-5 as per comment 43.

jgraham’s picture

Updated patch. Node add is unaccounted for. Perhaps this is an issue with og_get_group_context(), but I added in handling code to detect this context within og_variable_get().

CardAssassin’s picture


Im a Drupal newbie, and have the same concern of having groups with different default options.
I figured out a simple solution that only requires changing 1 line of code in the Organic Groups module:

function og_form_alter($form_id, &$form){

  if(isset($form['#node']) && $form_id == $form['#node']->type .'node_form'){
    $node = $form['#node'];
      // $form = array_merge($form, og_group_form($node));
      $form = array_merge(og_group_form($node), $form);

After making this change I created a new node module and set the new module as a "group home page node type" from the admin/og/og menu. I then used hook_form to alter the form elements created by og_group_form. Since the hook_form changes are added after the og_group_form changes, I was able to make a unique group type with different defaults.

moshe weitzman’s picture

Status: Needs review » Postponed

Not quite happenning for a while. Lets revisit after D6 ships.

Flying Drupalist’s picture

Subscribe, I need this too. I hope you guys will come back to this.

moshe weitzman’s picture

Status: Postponed » Needs work

Time to restart this work.

Crell’s picture

No time to dig in right now, but subscribing as I definitely see a need for this functionality.

dtarc’s picture

What's the current state of this issue? Would this be rolled out in a 1.2 version? I'd be willing to help with code and testing.

bonobo’s picture

We have a version of this running on 5.x-8.0 -- will post code shortly.

Flying Drupalist’s picture

Should this be moved to 6.x?

sethcohn’s picture

Version: master » 6.x-2.x-dev
Category: task » feature

While I'd be interested in seeing a 5.x (-8) patch, this really should looked at for a 6.x-2.x release (and then backport), as it's a pretty big change to do without having a D6 equivalent at this point.

bonobo’s picture

Assigned: bonobo » Unassigned
ajayg’s picture

could you please post the working code for 5.x branch so others can get ideas while working on 6.x?

sethcohn’s picture

@bonobo, seconded. Working code is _always_ welcome.

ajayg’s picture

Version: 6.x-2.x-dev » 5.x-8.x-dev

The whole thread is about 5.x so I am making it back to 5.x so bonobo can post his change. We can then port the change to 6.x.

bonobo’s picture

The patch in #46 works great -- jgraham and I work together.

We'll be picking up with some additional OG work in a couple weeks; we'll likely re-roll then, although this would be in a D6 version. Until that point, we're getting some other work out, and won't have the time to look at this in any meaningful way.

jgraham’s picture

Status: Needs work » Needs review
24.5 KB

Re-rolled patch against DRUPAL-5.

We use the following module og_gt_admin which extends the UI to allow for config per group type. This module is unreleased as we have not made a final pass, and don't have the bandwidth to properly support this module at this point.

Please note that the patch is untested as compared to our previous out of date patch referenced by bonobo.

Hopefully this helps move the discussion along. Like bonobo mentioned above we won't be able to commit any more time in the near future and when we do it will be directed at a D6 version of this.

rjleigh’s picture

anything happening on this for version 6 yet?

izmeez’s picture

subscribe, also interested in 6.x

b0b’s picture

subscribing also interested in 6.x

Flying Drupalist’s picture

Is anyone going to review and port this.

bonobo’s picture

Before anyone gets around to porting this, it would be good to see what the new options are with the D7 version of OG - the module has some very nice upgrades/improvements, and the approach in this thread is likely not appropriate/the most efficient way with the D7 version of OG.

chuckbar77’s picture

+1 subscribing for 6.x version, thank you

Crell’s picture

Status: Needs review » Closed (won't fix)