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.
hello
in D7 core, we still don't have this sort of permissions.
please port it :)
Comment | File | Size | Author |
---|---|---|---|
#47 | administerusersbyrole-908424-47.patch | 8.39 KB | univate |
#45 | administerusersbyrole-908424-45.patch | 8.39 KB | univate |
#40 | 2012-03-29_001944.png | 6.67 KB | Heorhi Lazarevich |
#29 | administerusersbyrole.zip | 1.69 KB | vikfroberg |
#23 | administerusersbyrole.zip | 2.01 KB | zilverdistel |
Comments
Comment #1
lpalgarvio CreditAttribution: lpalgarvio commentednote: role delegation is porting (the permissions aren't in D7 either)
http://drupal.org/project/role_delegation
Comment #2
ddyrr CreditAttribution: ddyrr commentedHere's the D7 version. I also fixed a small bug (if a user has multiple roles, it wouldn't let an admin edit someone with the role for which they have access to edit if the role came second in the list). I also added another small change that I thought worked better (it checks for administer users access before checking the additional role access so the user doesn't get additional access denied messages including the name of the user they can't edit)
Comment #3
bigdave CreditAttribution: bigdave commentedsubscribing
Comment #4
lpalgarvio CreditAttribution: lpalgarvio commentednice;)
Comment #5
jyee CreditAttribution: jyee commentedddyrr, thanks for the port work. The module is working as expected, however there were a few minor issues that should be resolved before the maintainer could add the port to CVS.
I've mad a few changes to remove the automatic CVS tagging and CVS lines in the info and module files. Also ddyrr had added a check for "administrate users" on line 34 of the module file, which seemed unnecessary (at least i didn't encounter any issues with removing it and it's not in the latest d6 version of the module).
Comment #6
jyee CreditAttribution: jyee commentedhrm... just found an error.
Line 29: if (arg(0)==='admin' && arg(1)==='user' && arg(2)==='user' && arg(3)==='create') {
checks for a url like /admin/user/user/create
In D7, the user create form is at /admin/people/create
Comment #7
Docc CreditAttribution: Docc commentedsub
Comment #8
bradjones1Subscribe
Comment #9
eric.chenchao CreditAttribution: eric.chenchao commentedSubscribe
Comment #10
chrisgross CreditAttribution: chrisgross commentedWhat is the status of this port? Has the error in #8 been fixed? Is the port in #5 safe to use?
Comment #11
chrisgross CreditAttribution: chrisgross commentedI ran into two errors using this module and have fixed them:
- arg(2) now checks for "people", instead of "user", following the proper D7 path.
- user_load syntax has been corrected from user_load( array('uid' => $uid) ) to simply user_load($uid)
This was producing the following message when editing a user: "Warning: array_flip() [function.array-flip]: Can only flip STRING and INTEGER values!"
Comment #12
chrisgross CreditAttribution: chrisgross commentedCan someone explain to my why "authenticated user" has been excluded from this module? If I remove a role from a user, he becomes invincible and cannot be edited or deleted. I can see that the role > 2 condition exists, which is simple enough to change to >1, but the use of DRUPAL_AUTHENTICATED_RID to bypass the ability to edit authenticate users without a roles baffle me. I am ready to take the if ($rid === DRUPAL_AUTHENTICATED_RID) {continue;} lines out of this module, unless someone can explain to me why they exist in the first place. I don't like the idea of giving a user superpowers by removing all his roles.
Comment #13
MathRo CreditAttribution: MathRo commentedSubscribe
Comment #14
elgandoz CreditAttribution: elgandoz commentedsubs
Comment #15
elgandoz CreditAttribution: elgandoz commentedsubs
Comment #16
lpalgarvio CreditAttribution: lpalgarvio commentedany new developments?
Comment #17
DamienMcKennaClarifying the title so it's more obvious when listed in the dashboard.
Comment #18
joryhogeveen CreditAttribution: joryhogeveen commentedIs the latest D7 port post stable? I'd like to use it on a live website :)
Comment #19
Taxoman CreditAttribution: Taxoman commentedSubscribing
Comment #20
amanire CreditAttribution: amanire commentedSubscribing
Comment #21
jenna.tollersonSubscribing. Is there a task I can do to get this moving?
Comment #22
Frederic wbase CreditAttribution: Frederic wbase commentedHello
Ive tested #11 and it works fine but maybe for useability it would be better to hide the edit links on the people overview page if the currently logged in user doesn't have the permissions to edit that user.
grts
frederic
Comment #23
zilverdistel CreditAttribution: zilverdistel commentedI fixed:
I also added edit and delete permissions for 'Authenticated users'. Checking all roles made this possible.
Comment #24
zilverdistel CreditAttribution: zilverdistel commentedAlso, I think it would be more convenient to hava a development branch for the drupal 7 version. We could move along much quicker, since we could handle separate issues.
Comment #25
Taxoman CreditAttribution: Taxoman commentedyes, time for a d7 branch?
Comment #26
Winn CreditAttribution: Winn commentedAgreed. Let's get this module legit.
Comment #27
RKS CreditAttribution: RKS commentedI just tested this on my site.
It works in title in that you can use the permissions correctly and the functions they assign work. There are a few things to note, however.
1) You must grant the administer users permission. The other permissions take care of *some* of the trouble with this. If a user can edit only a certain role, they can only edit that role.
2) This does not block them from doing other nasty things like blocking ALL users. If you give them administer users and none of the module provided options, they cannot edit, they cannot create, they cannot delete, but they can still block.
I'm wondering if this module would work better outside of the administer users. If you allow them to create, they can create. If you allow them to edit, they can edit. Do this without involving administer users and you block them from doing all of the other things you haven't designed the module to block.
if you cannot/don't want to take the module outside of administer users, I think you need to add some more permissions for things like block user of role a, b, c, etc and permissions for EVERYTHING administer users provides normally. You've done a good job taking care of some of these default issues but you should really take it one step further and take care of everything.
That's my thoughts on it.
Comment #28
geek-merlinopened a sandbox: Administer Users by Role D7 and fixed a critical issue: #1350930: administerusersbyrole let us edit no user at all when not english language
have fun!
Comment #29
vikfroberg CreditAttribution: vikfroberg commentedMade some changes, feel free to try it out.
Comment #30
geek-merlinad #29: what did you do from which starting point?
to collaborate on this efficiently patches are needed...
Comment #31
vikfroberg CreditAttribution: vikfroberg commented#30
I just went all crazy with the latest in this thread. (#23)
EDIT: Removed hook_init function since I remove links to the page instead of redirect.
Comment #32
geek-merlinsounds reasonable. seems you don't use git, do you?
Comment #33
vikfroberg CreditAttribution: vikfroberg commentedWell I do use it but I tried to clone your sandbox project and it was empty so I just downloaded the latest. If you have a projekt that I can work agains I love to help out.
Comment #34
columbus 1492 CreditAttribution: columbus 1492 commentedHello,
unfortunately the "D7 port of Administer Users by Role" described and posted above doesn't work under D7.12. Only the admin role can create/delete users. Every other role gets the access-denied-message. Can anybody help. Would be very nice...
Thanks a lot.
Comment #35
zilla CreditAttribution: zilla commentedsubscribe
Comment #36
rosell.dk CreditAttribution: rosell.dk commentedI don't understand - why did axel.rutz create a new sandbox project? Why not create a 7.x dev branch on this module?
Subscribing, btw...
Comment #37
alesr CreditAttribution: alesr commented@columbus1492
Did you enabled administer users permission?
It is in #27.
Comment #38
j4 CreditAttribution: j4 commentedAny chances of a D& release please?
Thanks
Jaya
Comment #39
aronne CreditAttribution: aronne commented@columbus1492 change _administerusersbyrole_can_edit_user($account) from this:
to this:
It works for me.
Comment #40
Heorhi Lazarevich CreditAttribution: Heorhi Lazarevich commented#29 + #39 work for me under D7.12 with one bag (see attachement)
Comment #41
bachbach CreditAttribution: bachbach commentedwhat a mess here ;)
however thanks for the work
#29 + #39 works for me
Comment #42
j4 CreditAttribution: j4 commentedWorks for me too..A proper release would be highly appreciated.
Thanks
Jaya
Comment #43
ñull CreditAttribution: ñull commentedSubscribing
Great that you guys tested this, but isn't it time for at least a 7.x-1.x-dev release?
Comment #44
MD3 CreditAttribution: MD3 commentedGuys, thank you so much! This was life saving. Just a suggestion, can we add some hooks so other modules can create more conditions to limit when a user can be edited?
Totally agree with ñull here, how do we get this thing in dev at least?
Comment #45
univate CreditAttribution: univate commentedHere is a patch against 6.x-1.x-dev with #29 + #39
Comment #47
univate CreditAttribution: univate commentedupdated patch
Comment #48
hoZt CreditAttribution: hoZt commentedThis issue request was started back in 2010. Can we get a 7.x dev branch up for this and then track any remaining remaining bugs as new issues?
Comment #49
_ Mazzhe CreditAttribution: _ Mazzhe commentedSubscribing
Comment #50
NobuT CreditAttribution: NobuT commentedI don't know if this is a common issue to D6 and D7, but a user who doesn't have the permission to delete still can delete by bulk operation (update). I don't know if there's any hook api to check if a user can be deleted. So, the only thing I could do is to implement hook_user_delete and throws an exception there.
Does anyone think of a better way? Ideally, the user who doesn't have the permission to delete the selected user should get a gentle error before proceeding.
Comment #51
geek-merlinhuh, what a mess...
maybe i did not state it clear enough in #28 that i already have a port and use it in production.
axel.rutz's sandbox: Administer Users by Role D7 | drupal.org
i really think we should merge efforts and will grant comaintainership to anyone who likes to help.
edit: this would also give us a separate issue tracker for the d7 branch so not to clutter up this one.
Comment #52
NobuT CreditAttribution: NobuT commentedThank you, axel.rutz! #28 works way better than #29+#39 for my situation. I'll be using it. I wish someone (like you?) could be a co maintainer for D7.
That said, #28 allows a user who doesn't have the permission to edit to block any user. I'll post an issue to your sandbox.
Comment #53
mrfelton CreditAttribution: mrfelton commentedUsing the sandbox project (thanks @axel.rutz). However, if you give a role only the ability to 'Create users', they can not actually access /admin/people/create. Why? Because Drupal core does this:
If a user is logged in, and they try to access the user create page, and they do not have the 'administer users' role, they get redirected back to the user page.
Comment #54
mrfelton CreditAttribution: mrfelton commentedI have filed a bug report against Drupal Core at #1671182: Ability to better control wether user_register_form is built in admin mode.
Oh, and @smokris, could we get a D7 branch of the codebase please?! ;)
Comment #55
MD3 CreditAttribution: MD3 commentedmrfelton,
You have opened a can of worms! Honestly it would be nice if Drupal Core just included this module by default as it's crazy not to have that kind of granularity on user administration!
Since I have personally emailed smokris with no response now, I keep meaning to do this for this project, but currently don't have time:
http://drupal.org/node/251466
Maybe someone else can do this get the ball rolling on getting an official D7 branch?
Comment #56
mrfelton CreditAttribution: mrfelton commentedStarted the ball rolling here #1673662: Offering to maintain administerusersbyrole module. Also contacted Steve by email.
Comment #57
mrfelton CreditAttribution: mrfelton commentedI'm on the maintainers list now (thanks Steve). I have fixed up Axel Rutz's initial port, and all 1400 odd tests are now passing. Code is in a 7.x-1.x branch, and I have cut a beta release. There is no D6->D7 upgrade path yet.
Comment #58
DamienMcKennaSo it isn't forgotten about: #1674716: D6 -> D7 upgrade script
Comment #59
MD3 CreditAttribution: MD3 commentedNice work mrfelton! Way to go and keep it up!
Comment #60
lpalgarvio CreditAttribution: lpalgarvio commentedindeed, nice job =) in times like this, could use a +1/Like button in the issue tracker!