Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
In several setups, one wants to grant the 'administer users' permission to certain roles (for example to forum admins), however without allowing those users to change permissions on the 'access control' page, and without allowing them to change the users' roles (so that they can't, for example, promote themselves to admin).
Therefore, I propose to introduce a new permission (I called it 'administer access control', patch attached), to split up the existing 'administer users' permission into 2 permissions.
Comment | File | Size | Author |
---|---|---|---|
#15 | admin_users_4.patch | 2.6 KB | DriesK |
#13 | admin_users_3.patch | 2.63 KB | DriesK |
#11 | admin_users_2.patch | 2 KB | DriesK |
#7 | admin_users.patch | 1.91 KB | DriesK |
administer_access_control.patch | 5.85 KB | DriesK | |
Comments
Comment #1
Dries CreditAttribution: Dries commentedCommitted to HEAD. Thanks.
Comment #2
kloomis CreditAttribution: kloomis commentedI tried to apply the patch to Drupal 4.6 using the following command
patch user.module < administer_access_control.patch
and I received the following error messages
hunk#4 failsed at 669
hunk#5 succeeded at 1074 wuth fuzz 1 (offset -67 lines)
hunk #6 failed at 1119
2 out of 6 hunks failed.
saving rejects to file user.module.rej
Comment #3
tamarian CreditAttribution: tamarian commentedKloomis, this patch is for cvs, not 4.6 :)
Comment #4
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedThis patch was not intended for 4.6
Comment #5
kloomis CreditAttribution: kloomis commentedOh. Can it be gotten for 4.6? Will it be made available in the future?
Comment #6
(not verified) CreditAttribution: commentedComment #7
DriesK CreditAttribution: DriesK commentedThe previous patch allowed only users with the 'administer access control' patch to block users, which doesn't make sense. The attached patch is to be applied after the previous patch, and allows users with the 'administer users' permission to block users.
Comment #8
DriesK CreditAttribution: DriesK commentedComment #9
chx CreditAttribution: chx commentedBlocking is one thing -- and roles are quite another. roles need administer access control.
Comment #10
DriesK CreditAttribution: DriesK commentedBoy oh boy. I clearly wasn't thinking. I'll make a new patch.
Comment #11
DriesK CreditAttribution: DriesK commentedHere it is.
Comment #12
chx CreditAttribution: chx commentedI am not 100% sure as I do not have the time to test, but I think we just discovered a problem in the original patch... are you sure I can't just insert the roles form element into HTML and have fun from there? I saw no user_edit_execute -- if there would be one, it'd be great...
Comment #13
DriesK CreditAttribution: DriesK commentedWhat should be handled by user_edit_execute() is currently handled by user_edit(), as it was in the pre-forms api era. As almost all user.module functions, this function hasn't been updated yet to the execute model. I don't have time to do this update, but the attached patch should cover the problem you mentioned I think. It can be transferred to user_edit_execute later.
Comment #14
chx CreditAttribution: chx commentedLooks good, but can be simplified -- I am not sure it's necessary to play array_intersect(array_keys) when a mere isset would do.
Comment #15
DriesK CreditAttribution: DriesK commentedI had also thought about that, and the array_intersect approach looked more extensible to me (to potentially add more keys later), but if you like isset better: here it is :-)
Comment #16
chx CreditAttribution: chx commentedThere is no later. Next time someone touches this it'll be execute model conversion and then you need no checking for rogue elements.
Comment #17
Dries CreditAttribution: Dries commentedCommitted to HEAD. Thanks.
Comment #18
(not verified) CreditAttribution: commented