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.This patch does not let you grant a permission you do not have access to. It simply removes the checkbox from the permission administer screen and takes care that otherwise checked checkboxes remain so.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | tiered_user_perm_0.patch | 2.37 KB | chx |
| tiered_user_perm.patch | 2.08 KB | chx | |
Comments
Comment #1
chx CreditAttribution: chx commentedLots o' cleanup, removed empty modules and stuff. We do not checkboxes but invidual checkbox elements so it's actually cleaner than the original.
Comment #2
markus_petrux CreditAttribution: markus_petrux commentedIf your patch that adds the ability to sort module_list() was committed you could avail this oportunity to sort this list alphabetically.
Both are great things :-)
Comment #3
drummI would like to see this disable checkboxes instead of remove.
Comment #4
Steven CreditAttribution: Steven commentedComment #5
Paul Natsuo Kishimoto CreditAttribution: Paul Natsuo Kishimoto commentedSeconding drumm's suggestion.
Comment #6
Crell CreditAttribution: Crell commentedWhether disabling or removing such checkboxes, it should be documented at the top of the page lest people get seriously confused.
Note that this could cause other workflow issues. For instance, you don't need uid 1 permission to enable a module. However, if that module offers new permissions, you will need to switch to uid 1 in order to enable that permission for anyone (since only uid 1 has a permission automagically). That's even more of an issue then with modules that have dynamic permissions, like CCK. CCK creates a new set of permissions for every node type you create. If you create a new node type, you then again need to switch back to uid 1 before you can create a node of that type because you need to give yourself that permission.
In effect, this would render a lot of administrative permissions effectively useless except for uid 1, because of the extra permission step involved. The only way around that I see is to have the dreaded "wheel" or "auto-admin" group concept so that some accounts can have uid 1-ish permissions, or to have both "can assign permissions" and "can assign any permission" permissions.
Comment #7
chx CreditAttribution: chx commentedWell, then modules being aware that they are adding new permission (on enable, on node type creation or whatever) shall grant it to the current user.
Comment #8
webchickHm. That gets tricky too though... if I'm user 34 and a member of the roles "authenticated," "editor," and "site administrator," I obviously don't want all permissions for that module to go to the editor or authenticated roles. And checking for if (user_access('blah permissions') || $user->uid == $module->uid) sounds kind of clunky... hm...
Comment #9
Crell CreditAttribution: Crell commentedAll I can think of here would be to make access to the permission edit page based on its own permission, in which case you can only change permissions you have, or on the enable-modules permission, in which case you get access to change everything. That feels a bit sloppy, but less so than "if it's the user that enabled it" logic.
Comment #10
BioALIEN CreditAttribution: BioALIEN commentedVery interesting discussion. Subscribing.
Comment #11
Jomel CreditAttribution: Jomel commentedWell we already have the permission, this bug should just be about adding a permission.
That way the people who have access to the server and might be uploading modules can be given the "can assign any permission", so can sort out the permissions for new modules etc.
Meanwhile, slightly less trusted "moderator-type" people can be allowed to assign permissions they already have to people, hence helping to manage the userbase (similarly it would be useful if they could assign roles to users on condition that those roles contain only a subset of their permissions, but I guess that's a new bug).
Comment #12
chx CreditAttribution: chx commentedComment #13
RobLoach....Interesting.
Comment #14
mlncn CreditAttribution: mlncn commentedFound this thread looking for a module to do exactly what Jomel suggested. This comes up all the time when building sites for others. (There is no solution in contrib yet?) As a developer you want to give client "site administrators" as much power as you think you can without their a) being confused or b) destroying their own site.
"If I am in a role with a certain permission I can give that permission to other roles" seems like a very sensible approach to safely delegating a lot of power... and, of course, making that a permission itself!
Maybe the whole thing does belong in contrib. Note that if we do try something like chx's original patch, having an administrator role in core would help greatly by enabling modules to automatically give most (but not all) permissions to this role, it could take care of the trickiness webchick brings up in #8...
Comment #15
sun.core CreditAttribution: sun.core commentedComment #16
ceardach CreditAttribution: ceardach commentedI just committed additions to the pwn module to additionally restrict granting of roles based, again, on which permissions the user has. However, I agree that functionality like this belongs in core. The PWN module separates "administer permissions" from the ability to share permissions, either through the permissions matrix or by granting roles that contain permissions the editor has themselves.
Comment #17
chx CreditAttribution: chx commented