From http://commons.acquia.com/discussion/disable-options-group

One of the first requirement we get from our users is the ability to enable/disable tabs on groups pages: in other words some group needs blogs, some other doesn't.

After digging in the views documentation we found a solution using a validation plugin (based on og_views "Group nodes" validator plugin).

Basically it extends the plugin allowing to select on which group you want to disable a given view (tabs are managed with views: "Blogs" corresponds to "og_tab_blogs" view and so on).

To enable this feature apply the patch, select "Disabled groups" in the Validator options and pick the groups you want to disable.

The patch is working, but the code needs to be cleaned up.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mstef’s picture

Nice. That's a big patch. Could you give me a little info on how it works?

EmanueleQuinto’s picture

Well, not such a big patch, after all, it adds 8 lines in the main commons_core module and 2 files.

The 8 lines and the first file are the standard code needed to expose a new plugin to the views API.
Something, by the way, that at some point some other feature request would have addressed and hence made implemented by somebody, I suppose.

The last file (commons_core_plugin_argument_validate_disabled_group.inc), on the other hand, extends the default plugin used by default in drupal commons: "Group nodes" (og_views_plugin_argument_validate_og_group_types.inc).

Extending in the sense the new plugin keeps his functionality as fixed by the default settings of drupal commons: i.e. "Group" as "Group node types" and "Node ID" as "Argument type". In terms of code this means that the logic of "Group nodes" is preserved (same code with simplification for node argument handling).

The core of the patch is on the form element for the selection of "Disabled groups":

    // get active group nodes
    $options = array();
    $options = $this->get_groups();
    $default_groups = $this->argument->options['validate_argument_disabled_groups'];
    if (empty($default_groups)) {
      $default_groups = array();
    }

    $form['validate_argument_disabled_groups'] = array(
      '#type' => 'select',
      '#title' => t('Disabled groups'),
      '#options' => $options,
      '#default_value' => $default_groups,
      '#multiple' => TRUE,
      '#description' => t('If you wish to disable for specific groups, check them.'), // . print_r($options, TRUE),
      '#process' => array('views_process_dependency'),
      '#dependency' => array('edit-options-validate-type' => array($this->id)),
    );

Then in the validate_argument:

    // validate for enabled group (i.e. if group is set then is disabled)
    if(is_numeric($argument) && 
       isset($this->argument->options['validate_argument_disabled_groups'][$argument]) &&
       $this->argument->options['validate_argument_disabled_groups'][$argument]>0 ) {
      return FALSE;
    }

It was the less intrusive way I found to implement this feature (requested by our new community site).

By design it allows the selection of "disabled" instead of "enabled" groups so to avoid admins have to remember to edit settings after the creation of a new group to keep the default behavior of drupal commons.
Adding a simple checkbox to select between the effect ("disabled"/"enabled"), as in rules module, could be a nice extension. As the number of groups grows some jquery multiselect magic would worth.

Although this patch is functional, it needs some cleanup: first, there are comments (old code, various debugs) in the code to be removed; second, the name of the select form element ("validate_argument_is_member") should be changed because hijacks the correspondant form element of "Group nodes"; it does not show up anymore when you select "Group nodes" as validator plugin (blame on me).

Crom’s picture

Works perfectly here, thank you!

mstef’s picture

Sorry, but after reading your description, that's no good. We can't have group admins (not site admins) having to enter the views UI to edit a custom validator, etc..

This will have to be a clean UI, accessible to group admins, which lets them toggle 'features' - not just views. Hiding the view doesn't take the node type away from the group.

JBI’s picture

For the next release of DC Why not spliting the feature of per group customization of content type "API" and the UI to be worked with the Jquery as in #3 http://drupal.org/node/921550#comment-3617160

It would let the community experiment as they have done for "homebox" in the former DC releases

mstef’s picture

Status: Active » Postponed

This is a big archtectural issue that we are still facing and evaluating. There will (almost certainly) not be such functionality in the 1.2 release. Currently, it seems, the only technology to implement per-group options would be Spaces - and introducing that would involve some significant overhaul.

EmanueleQuinto’s picture

I'm wondering if could be an option to include views settings in the main node group edit form using form_alter.

This should allow users with "lower" permission level to manage "options" without using directly the views UI.

mstef’s picture

Status: Postponed » Active

This issue goes way beyond just enabling a given view per group. There are other things that have to be considered, like node type, for example.

EmanueleQuinto’s picture

Hi Mike we managed to solve the node type permissions by role (group role) using "Content Type Administration by Organic Group" module with a small patch to increase granularity: http://drupal.org/node/247902#comment-3498998.

I agree that an overhaul of DC would address better the issue...

growltiger’s picture

So group admins can't edit the menu items available in their group?

mstef’s picture

Status: Active » Closed (fixed)

Fixed in upcoming 1.6 using og_features module.