Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
Comment #1
John Carbone CreditAttribution: John Carbone commentedSeconded. 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.
Comment #2
Leeteq CreditAttribution: Leeteq commentedComment #3
Everett Zufelt CreditAttribution: Everett Zufelt commentedI'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)?
Comment #4
Leeteq CreditAttribution: Leeteq commentedUse 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"?
Comment #5
shp CreditAttribution: shp commentedSubscribing for this feature in core.
Comment #18
smustgrave CreditAttribution: smustgrave at Mobomo commentedNot 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?
Comment #19
Chris Matthews CreditAttribution: Chris Matthews as a volunteer commentedPersonally +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
Comment #20
smustgrave CreditAttribution: smustgrave at Mobomo commented