Support for Organic Group

Yeah, that'd be great. That's what the original idea behind http://drupal.org/project/og_project was (long before comment_driven existed) but that module has taken on life in a different direction (with each Project as an OG), so there's currently nothing handling this use-case. I'd love to just be able to point people to comment_driven if they need that.

Thanks,
-Derek

lets start drafting it

this would be driven_og module, with support for og_access
(haven't tried it, this is a long shot)

// $Id$

/**
 * Implements hook_driven_properties().
 */
function driven_og_driven_properties($node_type) {
  $available_props = array();
  
  if (module_exists('og_access')) {
    $available_props['og:og_private'] = array(
      'target_title' => t('Private group'),
      'meta' => array(
        'theme' => 'driven_diff_yes_no',
      ),
    );
  }
  
  foreach ($available_props as $property_id => &$prop) {
    $prop['realm_title'] = t('OG');
  }
  return $available_props;
}

/**
 * Implements hook_diff_values().
 */
function driven_og_diff_values($element, $form_values, $meta) {
  extract($meta); // $node_type, $realm, $target, $provider, [$theme]
  
  return driven_diff_values_non_array($element, $form_values);
}

/**
 * Implements hook_diff_render().
 */
function driven_og_diff_render($old, $new, $meta) {
  extract($meta); // $node_type, $realm, $target, $provider, [$theme]
  
  return driven_diff_output_non_array($old, $new, $theme);
}

OG Comments can do this...

@#3 can do both things?

change audience and public/private settings

@tallsimon Re #3: At least based on the project description, I don't think that's the case. The D6 version just claims to support some features to hide comments (links and forms) for non-group members. The D5 version claims to allow you to specify an audience for each comment itself.

What we're talking about in this issue is the ability to use a comment on a node to alter the public/private and audience fields of the parent node itself, just like using comments on this issue can change things like the node title (like I'm doing with this comment in an attempt to make it more clear).

Unless the project description is totally out of date and doesn't reflect the functionality of the comment_og anymore, I think you misunderstood the request here and comment_og doesn't actually solve this problem at all.

yes sorry I misunderstood. I have just tested comment_og and it does not allow this functionality.

haven't heard comments regarding draft @#2
does it work? (if not, how badly?)

retitling to more generic purpose

marked #977314: When using to change post in OG audience is set to NULL as a duplicate of this
it worries me that I'm not having feedback, and now there is also a complain stating some incompatibility

guys: help me to help you

sorry don't have time to test this for you :-)

Only problem with organic groups and comment driven is that if you edit any CCK field in group post audience is set to null. I made 3 different instalations (trying to make project management) and it's always the same (I was trying all kind of permissions setting).

Can someone solve this?

@#12 this module doesn't state being compatible with OG, and this issue is actually the request to bring support for it, therefore, this is not a bug until we state we support OG

now, regarding the problem you're presenting, I just reviewed and it seems to be a bug in OG,
this module sets #access=FALSE for every form element NOT being touched,
(which is the proper way to do it according to FAPI)

so, you should address OG's issue queue asking them to properly support for #access=FALSE
if you need a better way to present your case before OG, then I would recommend you to base it on Driven NEP,
as it was done over here #976254: Incompatible with Driven NEP (via FAPI #access=FALSE) for a very similar issue of the date module

if you wan't to test it in a simpler way (without comment_driven, not even Driven NEP, just OG)
then edit your og.module, after line 1870 insert (as part of the initialization of $form['og_nodeapi']['visible']['og_groups'])
'#access' => FALSE,
if it misbehave the same ("audience is set to null") then that can be the statement for the OG bug report

PS: I would recommend entitling such issue with something like "honor FAPI: #access=FALSE"

re: #12, #13
As far as I can tell OG respects the #access property correctly, but the issue is that the form values are loaded incorrectly for OG and then mangled when the node is again saved.
I have opened a new issue for this bug with more info: #1030506: Organic Groups lost on change

duplicate #1030506: Organic Groups lost on change (has a hack proposal)

@#12, #13, #15: solved on #1030506-12: Organic Groups lost on change
separated issue at OG queue #1114402: Support for FAPI #access=FALSE