Problem/Motiviation
When using a combination of Views Bulk Operations and the Administration VIews modules, a bug occurs where users can circumvent the role delegation restrictions.
They can do this by selecting users from the admin/people
page and then choosing 'Change user roles' from the bulk operations drop down. The VBO form then allows them to add/remove all roles in the system.
Proposed Resolution
Apply a hook_views_bulk_operations_form_alter
to the VBO form provided by Administration VIews, removing any roles the user does not have access to.
See attached patch file.
Thanks to https://www.drupal.org/u/mhz for the consultation on this.
Comment | File | Size | Author |
---|---|---|---|
#8 | role_delegation-action_form_roles-2708317-8.patch | 1.56 KB | ron_s |
| |||
#2 | role_delegation-integration_with_administration_views-2708317-1.patch | 1.86 KB | danielmrichards |
|
Comments
Comment #2
danielmrichards CreditAttribution: danielmrichards commentedComment #3
danielmrichards CreditAttribution: danielmrichards commentedComment #4
benjy CreditAttribution: benjy at PreviousNext commentedThat action is exposed with a combination of those two modules, which bypasses the fact that core has a permission called
administer permissions
. It is for VBO to either access check the action or Admin Views to add stricter permissions to the view.Comment #5
danielmrichards CreditAttribution: danielmrichards commentedHi @benjy, yes I agree with your comment, those modules should provide stricter permissions on the view.
But what about the use case where we want a 'user manager', for example, to bulk assign roles they have permissions for? Then surely role_delegation should hook into the VBO form to remove any/all roles they do not have permission to assign?
Comment #6
benjy CreditAttribution: benjy at PreviousNext commentedIf those modules were doing what they were suppose to and your user manager role didn't have administer permissions, then the assignable roles via VBO would be empty. If that was the situation, we could consider, re-adding the roles for which they has the permission to assign or maybe we'd just provide our own VBO action.
Comment #7
danielmrichards CreditAttribution: danielmrichards commentedHmm, fair point. There have been open issues with VBO and Admin views regards this issue (https://www.drupal.org/node/2564855) in the past, but seem to have been ignored. Admittedly it is a bit of an edge case; so I'll defer to you on this one.
Feel free to close this issue if you prefer :)
Comment #8
ron_s CreditAttribution: ron_s commentedMaybe I'm missing something here, but it seems as though there is an issue. In the
role_delegation_delegate_roles_action_form
function, it uses_role_delegation_roles
to build the form fields._role_delegation_roles
always returns all existing roles, except anonymous and authenticated user. Therefore the action form shows all roles in every situation, regardless of permissions.I would think there needs to be a conditional in the action form as shown in the attached patch. Would appreciate feedback, thanks.
Comment #9
ron_s CreditAttribution: ron_s commentedMarking as needs review.
Comment #10
ugintl CreditAttribution: ugintl commentedPatch does not apply
Comment #11
ron_s CreditAttribution: ron_s commentedYes, it does apply. We've been using this patch for almost 3 years, I'm sure it works.
It needs to be applied to the -dev version, not the released version.
Comment #12
JeroenTComment #13
ron_s CreditAttribution: ron_s commentedYes, the patch in #2051669 is identical.