Anyone else incredibly annoyed when they have to check through a list of 49 out of 50 checkboxes? Why not just select all and unclick one?

This feature needs to be standard. permission lists are too long to have to do manually all the way down, and it would be great to be able to have select all buttons for each module on those.

Comments

John Carbone’s picture

Version: 8.x-dev » 7.x-dev
Priority: Major » Normal

Seconded. There is a D6 module for this http://drupal.org/project/checkall but I agree, it'd be really cool if it was addressed in core.

Edit: Removed comments that are not directly related to the topic.

Leeteq’s picture

Version: 7.x-dev » 8.x-dev
Priority: Normal » Major
Everett Zufelt’s picture

Version: 7.x-dev » 8.x-dev

I'd be in support of expanding #type=checkboxes to allow this property, as we do with #type=tableselect.

Other than the permissions page (where I assume you would be suggesting a select all at the top of each role column, can you suggest anywhere else in Core that you think this would be appropriate?

I don't personally think that this is appropriate on the permissions page, how many times do you want to give a role all permissions, and how often do you do this (one per install)?

Leeteq’s picture

Use case #1:
As a workaround for one particular annoyance in Drupal:
When we change the Administration role from RID3 to another role in the administration config page, then Drupal _should_ tick all permissions automatically for the role that is taking over as "administration role". That does not happen, and if this is on a site with many modules, it is just plain annoying to have to go through and check them manually.

#2:
Many sites make use of both a secondary and a third admin role, for example one without permissions to do anything with the users and/or changes to the very permissions page, but permitted to administer "everything else": in that case we want to "check all" for one particular role so that only a few tickmarks needs to be uncheked afterwards.

Strictly speaking Drupal core should just fix the main annoyance related to changing the admin role, which should be enough for core, and then such a check all function could live in contrib instead.

Workarounds:

a) Firefox extension:
Now that we can get to list the permissions PER ROLE on a single page (hence with only one column at admin/user/permissions/roleid), then browser extensions such as
https://addons.mozilla.org/en-US/firefox/addon/checkfox
lets us do this easily, so this is not a big problem anymore.

b) Existing contributed modules:
http://drupal.org/project/checkall (Drupal 6 only per Aug/Sep 2011)
http://drupal.org/project/permission_select (Drupal 6 and 7 releases per Aug/Sep 2011, but the 7.x branch has never worked even if in "stable version number", so still no module solution for D7)

If a contributed module can keep up with core development also on early dev/alpha releases of new main versions, then that is where this really belongs, IMHO. I am in favor of the "Checkall" module that can be used to detect columns of checkboxes on _any_ page and offer a check all function anywhere such a column is identified automatically. Maybe those two modules should merge and a couple of core contributors can join as co-maintainers to help move it along at "core speed"?

shp’s picture

Subscribing for this feature in core.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Issue summary: View changes
Status: Active » Postponed (maintainer needs more info)

Not sure about using it on permissions but in general maybe.

Currently there is https://www.drupal.org/project/multiple_select so question is do we want to bring into core?

Chris Matthews’s picture

Personally +1 for bringing multiple_select type functionality generally into core. Basically standard UX on the web, but up to the UX team/maintainers to decide.

Helpful comments in #3 from 12 years ago

I'd be in support of expanding #type=checkboxes to allow this property, as we do with #type=tableselect.

Other than the permissions page (where I assume you would be suggesting a select all at the top of each role column, can you suggest anywhere else in Core that you think this would be appropriate?

I don't personally think that this is appropriate on the permissions page, how many times do you want to give a role all permissions, and how often do you do this (one per install)?

smustgrave’s picture

Status: Postponed (maintainer needs more info) » Active

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.