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,
first of all.. thank you for this module!
When I disallow a user to "edit or delete" a account based on the role I think it should be also impossible to block or unblock a user withe this role. For example:
When a user have a role "community manger" and has not the rights to edit or delete any user with this role "community manager" the user should also be unable to block or unblock this user with the role "community manager"
Is this a possible feature for this module?
Best regards
Frank
Comments
Comment #1
Anonymous (not verified) CreditAttribution: Anonymous commentedAgreed.
I think this is a bug in the security model, not a need for a new feature.
Regards, Tony
Comment #2
balleyne CreditAttribution: balleyne commentedI think the problem is with hook_user_update() (on line 160 of the latest beta). According to the Drupal API, this is called after a user account "was updated." http://api.drupal.org/api/drupal/modules%21user%21user.api.php/function/...
Shouldn't that be an implementation of hook_user_presave() instead? I think hook_user_update() is just too late -- the block/unblock has already taken place. Changing to hook_user_presave() seems to work for me (though, it does lead to an awkward situation where the core user drupal_get_message() says the account has been updated, even though the message from administerusersbyrole contradicts that).
Comment #3
fraweg CreditAttribution: fraweg commentedHello balleyne,
how exactly have you done this? I am not a developer an need more infos.
I this also this is a security issue and will change the priority.
Best regards
Frank
Comment #4
dmegatool CreditAttribution: dmegatool commentedto
#2 worked for me. Thanks balleyne
Comment #5
fraweg CreditAttribution: fraweg commentedHello dmegatool,
thanks a lot for your post!
Do you think there is also a way to do this with the dev version? I did not find this line there.
Best regards
Frank
Comment #6
fraweg CreditAttribution: fraweg commented...no idea in that? :-(
Comment #7
HaloFX CreditAttribution: HaloFX commentedThe change on #4 corrected the functionality issue, although the alerts still conflict. It shows "The update has been performed" and "You do not have permissions to block [user]".
Great module BTW! This finer grained functionality really should be in core.
Comment #8
fraweg CreditAttribution: fraweg commentedHello HaloFX,
sorry, my english is a little bit poor.... does this mean that #4 works for you? I did not find this lines.. :-(
Best regards
Frank
Comment #9
yuvaraju.an CreditAttribution: yuvaraju.an commentedThanks dmegatool it works fine :)
Comment #10
fraweg CreditAttribution: fraweg commentedHello yuvaraju.an,
what version of this module did you use?
Best regards
Frank
Comment #11
HaloFX CreditAttribution: HaloFX commentedIs it did work. The alerts are just messed up. See attachment.
I am using Beta1
Comment #12
fraweg CreditAttribution: fraweg commentedHello,
is this bug solved in the actual dev version ?
best regards
Frank
...ok I see this line is gone in the dev version. Do somone know where to fix it in the dev version ?
Comment #13
fraweg CreditAttribution: fraweg commentedComment #14
fraweg CreditAttribution: fraweg commented...Can someone attach a working patched beta1 version ... For me this patch did not work ... For example a user can deactivate his own account.... :-(
Best regards
Frank
Comment #15
ndrosev CreditAttribution: ndrosev commentedHello,
I found a solution for the this issue. Just set form error on form validate if you don't have a permission to block and unblock user with specifuc role ,
Here is the patch , please have a look and test it
Comment #16
boyan.borisov CreditAttribution: boyan.borisov commentedComment #17
HaloFX CreditAttribution: HaloFX commentedI can't speak to the code, but I have applied the patch from #15 and tested through Simplytest.me and to a local dev copy of the site from #4 in which I encountered the issue. In both cases the patch from #15 fixes the problem and behaves as expected.
Comment #18
AdamPS CreditAttribution: AdamPS commentedI intend to fix this as part of #2378869: Meta-issue for Beta 2 release. Please sign up as a follower of that issue and see the patch there that I would like feedback on.
I have taken a slightly different approach - the users which there isn't edit permission are removed from the user list entirely. Advantages are that is much clearer to the user what they can and can't do. Also the above patch only affects block/unblock, but typically every operation available on this page needs to be protected - other modules can add them and I think we have to assume they need protecting.
Please test/review the new patch and let me know.
Comment #19
AdamPS CreditAttribution: AdamPS commentedFix now available in latest release