Confusing names for permissions and config

If you are using 8.x-3.x then you don't need Role Delegation because the newer version of this module allows assigning of roles.

If you still see the problem after removing Role Delegation then please post a screenshot or send me a personal message with the login details of an account I can use to test it.

I am having a similar problem that I think may be the underlying cause of this, or perhaps at least related (happy to create a new ticket if it's not). It seems that if a user does not have the applicable general "___ users with safe roles" permission (e.g. view users by role), the custom (by-role) permissions (e.g. view users by role {role} do not work. This is not what I was expecting, based on the documentation on the module settings page and module help page.

To reproduce:

• Create two new roles, e.g. Safe Role and Custom Role
• Configure them as Safe and Custom (respectively) in the Administer Users by Role settings at admin/config/people/administerusersbyrole
• Configure permissions at /admin/people/permissions:
  • Give both Safe Role and Custom Role the permissions: "Access the users overview page", "Edit users with role Custom Role", "View users with role Custom Role"
  • Give Safe Role the additional permissions: "Edit users with safe roles", "View users with safe roles"
• Create four new users, two with Safe Role and two with Custom Role
• Log in with one of the Safe Role users:
  • Observe that they can cannot see any of the four users on the People admin page at /admin/people, including their own user (not exactly expected)
  • Observe that the view and edit pages for all four users can be accessed directly (/user/{id} and user/{id}/edit) (expected)
• Log in with one of the Custom Role users:
  • Observe that they cannot see the Safe Role users on the People admin page at /admin/people (expected)
  • Observe that the view and edit pages for the Safe Role users cannot be accessed directly (expected)
  • Observe that they cannot see the Custom Role users on the People admin page at /admin/people (not exactly expected)
  • Observe that the view and edit pages for the other Custom Role user cannot be accessed directly (not expected)

  FWIW, I think I have tracked this down to the pre-access check in AccessManager->access(), which calls AccessManager->preAccess(), and in the last block is checking for the "base" permission. When that returns as FALSE, a neutral access result is returned in the access function before it has checked for the individual (custom) permissions. It seems like this check for the base permission is not quite in the right spot to allow the custom role permissions to work without having the general safe roles permission.

  I am still trying to fully wrap my mind around all the implications of moving the "base permission" logic. But, perhaps it simply needs to be moved after the individual role access checks within the access function?

@bgustafson Thank you for a detailed report, that's very helpful. I now understand the problem.

The way it behaves now is Working as Designed. The intention for 3.x is that the custom role permissions don't work unless you also have the general permissions. However I can see why you found this unexpected based on the documentation. I propose to fix this problem by changing the documentation to describe correctly the way it currently works.

The reason it's this way is to avoid some other unexpected/undesirable behaviour that was present in 2.x. The general principle is that the more roles a target user has, the more risk there is to be able to edit that user so the more difficult it should be to manage that user; the fewer roles, the easier it should be. If the site has two roles A and B and I give a sub-admin permission to manage both of them then it is likely to be a surprise that the sub-admin cannot manage users that have no roles. Even worse, if the sub-admin has permission to assign both roles and they remove the roles from a user, then suddenly they can't view or edit that user.

However in the recent release I made a change that I now see was a mistake. I renamed the permission "View users by role" to be "View users with safe roles". The reason I made the change was that people couldn't easily understand the old name. However the new name is causing even more confusion!

Here is my idea: we name the general permission "View users" - short and simple. Then I can add a sentence to the help to make it clear that the sub-admin must have the custom permissions in addition to the general one. Possibly I could even write code to generate a warning if some role has a custom permission without the general one.

What do you think?