| Project: | Role Delegation |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
I have some profile fields under their own tab in the user page. Role Delegation is now adding the "roles" section to the profile tab, and is not selecting any pre-existing assigned roles to the user. This means the user, from being very privileged goes to "authenticated user" if they save any profile changes from the profile tab. I can't see how I can easily fix this in the code, it looks like your code is mangling the user page whether or not it's the "base" user page, and for some reason (I can't see why) it's not picking up it's roles when it's not on the "base" user page.
To recreate, simply add a new profile field, with it's own category. try and edit that profile field on a user granted privileges, and you'll see that the assigned roles disappear.
Thanks
Comments
#1
OK. I spent some time, and figured out that using hook_form_alter is not going to respect profile tabs.
Attached is a diff for what I think is the way you're supposed to do it.
Hope this helps
Christian
#2
Any development on this? I have a production site where this issue is causing confusion. We'll apply the patch and test if it would help all.
#3
Applied the changes in this patch - disabled/re-enabled the module. Did not find the problem addressed / corrected;
Roles show up on each profile category page, entirely empty, as title of this issue describes. This occurs for any user granted delegation permissions. Changes over-ride actual existing values, as described above if saved.
#4
I see this as well. I will test the patch and report back soon.
#5
The patch from djsmeg fixed this issue for me (roles no longer show up in profile tabs other than account, and thus they don't get wiped out when the profile is saved), and I've simplified the patch a bit (the only change being that hook_form_alter() is completely removed).
I removed the hook_form_alter() implementation because it didn't appear to do anything (someone correct me if I'm wrong); the code after applying the original patch (and the code that I removed in the new version of the patch) is below:
/*** Implementation of hook_form_alter().
*/
function role_delegation_form_alter(&$form, $form_state, $form_id) {
// Only alter user form when user can't assign permissions without Role Delegation.
if ($form_id != 'user_register' && $form_id != 'user_profile_form') {
return;
}
if (user_access('administer permissions')) {
return;
}
}
#6
The patch in #5 solved this problem for me. Can we get this patch committed to the module?
Cheers,
Ben
#7
FYI for anyone having this problem and wanting a possibly upgrade friendly work around:
A new custom module dcpl_misc.module:
<?php
function dcpl_misc_form_alter(&$form, $form_state, $form_id) {
switch ($form_id) {
case 'user_profile_form':
// for this to work, wee need to run this SQL: update system set weight = 10 where name = 'dcpl_misc';
if (!array_key_exists('account', $form)) {
unset($form['roles_assign']);
}
break;
}
}
issue the following SQL:
update system set weight = 10 where name = 'dcpl_misc';#8
Patch in #5 worked like a charm for me too.
Please roll it into the next relase if possible.
Cheers! And thanks for all your hard work on a great module!
#9
I agree with shark's patch (comment #5). It works without error. Just remember to disable/re-enable the module after patching, of course. Thanks a ton shark.
#10
I confirm the patch #5 works correctly.
I hope it will be included soon! :-)
Thanks all!
#11
The patch had some issues:
I have corrected those issues and committed the changes.
This will need to be ported to the Drupal 7 version.
#12
Wow! Many thanks David :-)
#13
Here is a modified patch to avoid displaying the roles checkboxes twice on user edit page for roles with administer permissions access
#14
Last time I checked, the 6.x-1.x-dev version was not displaying the checkboxes twice for roles with 'administer permissions' access, so patch #13 should not be needed.
The commits mentioned in #11 still need to be ported to 7.x.
#15
Now, that's perfect timing. I just had a costumer complaining about his losing his roles, and the 1.3 version was released just some minutes ago! Thanks a lot, all of you.
Marcus
#16
I can't reproduce this problem in D7. When a logged in user with the "administer users" permission goes to edit a target user's profile, the checkboxes that appear there are correctly populated with the target user's roles (at least, the ones that the logged in user has permission to change). So editing and saving another field there doesn't affect the assignment of those roles.
If the logged in user has "view user profiles" but not "administer users", then when s/he goes to view the target user's profile and clicks on the "Delegate roles" widget, the checkboxes that appear there are again correctly populated. And there's no other way to edit the target user's account in that case anyway.
So I think this bug is fixed. Please feel free to reopen it if you think I'm wrong.
#17
Automatically closed -- issue fixed for 2 weeks with no activity.