feat: Role Delegation permissions

[callinmullaney]

Purpose:

• Break up the Administer roles and permissions permission for specific role-to-role assigning. Allowing non-admins to create new users without and assign them to sub-roles without exposing the administrator role.

Notes:

• PR is base off of Improved UX for paragraph fields #29 as the superuser role is needed

Testing:

Code changes:

• Install Sous and verify the config changes in this PR import without errors.
• Go to /admin/modules and verify the "Role Delegation" module is enabled by default
• Go to /admin/people/permissions and verify the superuser role is present and assigned all the permissions related to "Role Delegation"

module features:

• Create a new user role /admin/people/roles/add
• Create another user role /admin/people/roles/add that is intended to have restricted access
• Go to /admin/people/permissions and grant "Role Delegation" permission for the first role to assign the second role. As well as:
  • View the administration theme
  • Administer users
  • [ ]
• Create a user account for the two roles above to test the following permissions
  • Log in with the user you assigned with the delegation permissions
  • Go to /admin/people/create and verify the only role available to assign is the second role you created from above

[ccjjmartin]

@callinmullaney I made it through all of your steps in testing. From a code and functional perspective it does everything you said it does. My only hesitation here is that I am not sure that ALL of our sites we build will need this ... using TLSC as an example, what would their use case be for using this module?

Also, for actual use the permission to see the admin toolbar would be helpful for the role who gets to delegate.

[callinmullaney]

@ccjjmartin The main use case for most projects is to prevent users that have the administer role and permissions from assigning themselves the superuser/administrator role or creating new administrator accounts.

In the example of TLSC. Content Managers need to be able to have the ability to add new Content Editors or Contractors to the site. However, because the administer role and permissions is a catch-all permission any Content Manager could assign themselves as Administer role or create new Administer user accounts themselves. Essentially bypassing the Organization Admin role. With this module we could prevent this scenario altogether by having specific assign role permissions instead of giving everyone the keys to the kingdom.

Even on simple/smaller projects we generally create a new role for the client that they use for day-to-day updates that isn't the administrator role. This scenario also applies as we wouldn't want them assigning there day-to-day role as the superuser/administrator.

In the context of the PR that blocks user 1 this becomes especially important as we don't want anyone to unblock that user.

[callinmullaney]

Updated PR purpose to reflect this.

[ccjjmartin]

@callinmullaney Ok, looks good to me

[fkbender]

🎉 This PR is included in version 4.1.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀