It would be extraordinarily helpful if there were a "select all" option when editing the permissions to use in a feature. As it stands now, if you are running a large site with many modules, this requires a huge number of clicks, which can be difficult on slow browsers.

Thanks for considering my suggestion

Comments

yhahn’s picture

Agreed, but unfortunately it will not be an easy fix to just use theme_table_select_header_cell() as it does integrate in quite the right way with ahah.js

Will look into this post 1.0.

bibo’s picture

This would be really handy indeed. I'm having a site with somewhere a few hundred separate permissions(!). Don't like to click each of them.

orjantorang’s picture

It would really be appreciated with a select all option, mostly for permissions but even for CCK-fields, but I guess it will be able for all kinds if it's developed.

podarok’s picture

subscribe

really need it, especcialy for strongarm tab and permissions tab

dsnoeck’s picture

Just found a workaround for selecting all checkbox :
- Use firefox and the Web Developer Toolbar addon
- In the WDT addon there is Forms features, the penultimate item is "Populate form field", which will automatically select all checkbox :-)

Enjoy
UPDATE: Forget this workaround, this will check all checkbox of all components !

kristen pol’s picture

Subscribing... I just clicked a hundred checkboxes and then the browser died... argh!!!!!! My hand hurts.

Maybe a possible alternative to this would to have a non-ajax version of the form and use the check all module or some similar code. The ajax is super slow in FF and freezes it up regularly.

Back to clicking... again... :(

[note to @podarok] Beware of checking *all* checkboxes on strongarm... I've been burned by this. You should only check ones that are *configurable* through the UI, not ones that are set by a module directly. I think this needs to be more cleverly handled in features because it's too easy to shoot yourself in the foot as I have found.

Kristen

Grayside’s picture

It is worth considering that while Features can do great work with exporting all your configuration to Code, it was intended to be more surgical with exports--only exporting those components directly related to a rather narrow use case, such as a Blog feature.

It might be a good idea to step back and think about how the UI should be structured to be used for both purposes, or whether the UI should be separated--one for Features-building, one for mass configuration export.

I kind of lean toward the latter, as placing a select all on the features UI will lead newcomers down the mass export path, instead of the preferred "lean" exports. http://drupal.org/project/kit.

kristen pol’s picture

I looked at the strongarm module to see how they automatically include some of the comment_* variables that correspond to content types you have selected. It was pretty straightforward so now I have some code in my custom module that adds in content-type-specific variables and permissions like:

function mymodule_features_pipe_node_alter(&$pipe, $data, $export, $module_name) {
  if (! empty($data)) {
    // all variables related to content types
    $variables = array(
      'amt_[type]',
      'ant_[type]',
      'ant_pattern_[type]',
      'ant_php_[type]',
      'comment_anonymous_[type]',
      'comment_controls_[type]',
      'comment_default_mode_[type]',
      'comment_default_order_[type]',
      'comment_default_per_page_[type]',
      'comment_[type]',
      'comment_form_location_[type]',
      'comment_preview_[type]',
      'comment_subject_field_[type]',
      'content_extra_weights_[type]',
      'content_profile_use_[type]',
      'ffp_[type]_field_[type]',
      'nmp_[type]',
      'node_options_[type]',
      'page_title_type_[type]',
      'page_title_type_[type]_showfield',
      'pathauto_node_[type]_pattern',
      'print_display_comment_[type]',
      'print_display_[type]',
      'print_display_urllist_[type]',
      'signup_date_field_[type]',
      'signup_node_default_state_[type]',
      'unique_field_comp_[type]',
      'unique_field_fields_[type]',
      'unique_field_scope_[type]',
      'unique_field_show_matches_[type]',
      'upload_[type]',
      'xmlsitemap_settings_node_[type]',
    );
    // permissions related to content types
    $perms = array(
      'create [type] content',
      'delete any [type] content',
      'delete own [type] content',
      'edit any [type] content',
      'edit own [type] content',
      );
    foreach ($data as $node_type) {
      foreach ($variables as $variable_name) {
        $variable = str_replace('[type]', $node_type, $variable_name);
        if (! in_array($variable, $pipe['variable'])) {
          $pipe['variable'][] = $variable;
        }
      }
      foreach ($perms as $perm_name) {
        $perm = str_replace('[type]', $node_type, $perm_name);
        if (! in_array($perm, $pipe['user_permission'])) {
          $pipe['user_permission'][] = $perm;
        }
      }
    }
  }
}

I'm working on finding a way to select all perms without conflicting with other features. I will post something if I figure that out.

Kristen

alberto56’s picture

Subscribing

westbywest’s picture

Subscribing. Would also be nice to see this for D7 too.

Grayside’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev

As a feature request, this kind of thing needs to start in D7 and get backported.

ohthehugemanatee’s picture

This bulk export interface would be a powerful addition to something like profile_builder . One of the most time consuming parts of creating an installation profile is bundling settings like permissions, block positioning, views... all things that Rules does very well. All it would need is a more bulk-oriented UI.

Come to think of it, Features is already pretty close to a perfect install profile builder, minus the bulk-friendly UI. Anyone here interested in a submodule for creating install profiles?

btopro’s picture

I assume you mean http://drupal.org/project/profiler_builder and yes that would be a very powerful submodule (disclaimer: original creator of profiler_builder) ;)

wildermuthn’s picture

Well, this is quite the hack, but it works for me. It requires Chrome, or a similar setup with another browser.

First, inspect the checkbox container. The height is set at 20em. Make it really really really big. Big enough to show the entire list.

Second, use the Google Chrome extension, "Checkboxer". It allows you to click, hold the click, and drag over all the checkboxes as you scroll down.

Third, check and uncheck one of the boxes to get the ajax rolling so that it realizes you just checked all those boxes.

Like I said, a terrible hack, but it saved me a boat-load of time.

jtwalters’s picture

Quick hack without requiring a browser extension:

Open the developer javascript console and run:
jQuery('.features-select-user_permission input[type=checkbox]').attr('checked', 'checked');

Then uncheck and check a checkbox to trigger the AJAX update.

btopro’s picture

Couldn't this approach then be tied to a checkbox on the interface for "check all" to trigger this way without having to do funky things in the console?

jtwalters’s picture

I would say "select all" functionality via javascript is easy to implement, however, I'm just not sure how to trigger the AJAX event properly (i.e. elegantly). I could take a stab at implementing it if there's enough desire from the community. I suppose the number of replies in this thread provide evidence that it is desired.

mpotter’s picture

Status: Active » Fixed

This functionality has been committed to the latest version of the featuresUI-1.1 branch.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

aron.beal’s picture

I think one can also do this through the firebug console via:

jQuery('input[name^="user_permission"]').attr('checked', 'checked')

This appears to be moot, at this point; I see the 'select all' tickbox in my build. Still might be useful if something similar comes up.