Add role assignment widget on user/edit and admin/user/user/create

Not sure what you are talking about here. The altered title is the only concrete feature request I am seeing here. Anything else should go into a new issue.

Ah, I guess the rest of your post was referring to this issue: #180180: Add Role Assign fields to admin/user/user/create

Yes, #180180: Add Role Assign fields to admin/user/user/create is a duplicate of this issue.

With RA there's the usual Roles widget on admin/user/user/create (the one that you see when you go in as user 1), just with a limited selection of roles. RD removes (or does not re-add) that widget and instead creates a separate tab for assigning roles.

When you create a user on admin/user/user/create it's more convenient to assign her roles on that very page rather than having to go to a separate roles tab.

(mass-assigning roles would be a separate feature request)

If we implement the regular (but cut-down) user roles widget, we want to properly implement it on all pages, i.e. on user/#/edit as well as admin/user/user/create.

Yes, I agree!

subscribe

Subscribing. Any kind of larger volume user management requires integration with views bulk operations. I'm potentially willing to offer a bounty for this feature, since the site I'm creating will simply not work without it.

I'm grappling with similar issues in Userplus. It would probably benefit all of our users if we coordinate. I'd be happy to split out the role assignment portion of Userplus if we can get some good VBO integration along with it.

- Marc

Here are patches for both branches (the 6.x patch should say 1.1 as opposed to 1.2). I've tested them myself, but of course it wouldn't hurt to have someone else code review and/or test them.

A couple of notes.
1. With the implementation of this patch, users with the 'administer users' permission can assign roles through the 'Edit' tab. Thus, I've eliminated the 'Roles' tab for users with the 'administer users' permission since it's now redundant. If you feel like you still want to keep this tab intact for said users, feel free to undo that change (it's only a few lines) after applying the patch.
2. I also made a slight correction under the 'Roles' tab. It previously said users will receive all assignable roles checked off plus the authenticated user role. However, sometimes there are other non-assignable roles a user has besides authenticated user, so it now says that the user will receive all assignable roles checked off plus all non-assignable roles the user already has (the list of which is generated dynamically).

Attachment	Size
role_delegation-5.x-1.2-287914.patch	4.19 KB
role_delegation-6.x-1.2-287914.patch	3.9 KB

I like the idea of keeping it all on the Edit tab when the user has 'administer users' permissions.

I haven't yet tried this out, but there will probably be times where you wouldn't want the [non-administer users-type] user who is assigning roles to see all the role names of roles that they can't assign.

Also, please create patches with -p so we can quickly see the affected function without having to apply the patch.

Thanks for creating the first patch. However, there are coding-style issues, especially regarding control structures - see http://drupal.org/coding-standards

OK, I've installed this and had a poke around. As you say, it puts role editing on the user edit page. I'm also getting role update options for the user admin menu at /admin/user/user

However, I can't create any role update Actions, or expose role updates to VBO. How do I use this to allow site users to perform mass updates?

Also: thanks for your work so far on this!

Good call, I'm so used to using '} else {' as opposed to putting the 'else {' on a new line. I corrected that as well as the comments and created a proper patch this time. Anything else? The Coder module doesn't seem to have any major objections to these patches.

Attachment	Size
role_delegation-DRUPAL-5-287914.patch	4.58 KB
role_delegation-HEAD-287914.patch	4.27 KB

Yes, function summaries should form a proper sentence, so a trailing dot is missing here:

However, I'm pretty sure that there are "real" issues with this patch, so we can defer that for later.

Periods have been added, so future patches should be good.

I could use some clarification about the issues DanielJohnston is talking about. The title and description of this issue seem to imply that this is mainly about the user forms at admin/user/user/create and user/%uid/edit. I read the thing about admin/user/user, but I'm not sure if that belongs here or as a seperate issue. What I can say, though, is that the ability to mass-assign roles under /admin/user/user is something that can only be done for all user roles if you have the 'administer access control(5.x)/permissions(6.x)' permission; Role Delegation doesn't implement that specifically as far as I can tell. As for the role update Actions, is this in reference to the actions which have been added to the core in 6.x?

Yes, DanielJohnson has a completely different issue. User mass operations and/or VOB operations do not belong into this patch.

In that case, besides the periods, what are the "real" issues we're talking about?

These two patched have the periods included that were needed in the comments. Has anyone found any bugs with my patches so far, or is this patch good to go?

Attachment	Size
role_delegation-DRUPAL-5-287914.patch	4.58 KB
role_delegation-HEAD-287914.patch	4.27 KB

Working well so far for me.

I took the time to test both the HEAD and D5 patch. They are working great and indeed make Role Delegation a lot easier to use. Thanks Mike Wacker !

Tested :

• An user with a role which can "assign all roles" -> The user could assign and strip every role for users.
• An user with a role which can add one or more role -> The user could assign and strip only the definied roles for users.
• An user with a role which can "administer users" but cannot assign any role -> The user could not assign or strip off roles but users were still modifiable (as intended).
• An user with a role which can assign/strip its own role -> The user could strip this role off his account and was presented the "Access denied" page after the operation was completed successfully (that is also how it is supposed to be done, so it is ok)
• Users with the "administer permissions" (for D5 it is "administer access control") could in every case assign/strip roles as it is supposed to be.
• User-1 could in every case assign roles as it is supposed to be.

(This list might be a good base to write test cases some day :))

Drupal 6 as just a slight change, the "access administration pages" has to be set to gain access to the user management, this might have to be documented, even if it is surely a limitation due to core or core module... in Drupal 5 (where the menu module was less crucial when it comes to access rights, the sub menu "Users" was just displayed without its parent, as a top level link of the "Navigation" menu).

I feel this could really be set as RTBC, but I am not sure there are enough reviews do to it, so if any one else could review the patches it would be great.

Very nice patch, thanks Mike Wacker!
I have tested it too, and committed it.

However, just after committing I have noticed that it was possible for the widget to have no options and still appear (with just its title and description). In my test case, the user was editing his own account and did not have the permission to assign any role nor to administer permissions. So I have added the following patch on top of Mike's.

Attachment	Size
role_delegation-287914-22-D6.patch	638 bytes

Automatically closed -- issue fixed for 2 weeks with no activity.