Administer Users by Role
Allows site builders to set up fine-grained permissions for allowing sub-admin users to edit, cancel, and create other users based on their roles, providing more specific control than Drupal Core's all-or-nothing 'administer users' permission.
administerusersbyrole
Install
composer require 'drupal/administerusersbyrole:8.x-3.6'
composer require 'drupal/administerusersbyrole:8.x-3.4'
Overview
The Administer Users by Role module enables site administrators to delegate user management tasks to specific roles without granting full 'administer users' permission. This is particularly useful for sites with multiple tiers of administrators where certain users need to manage specific groups of users without having complete administrative access.
The module automatically generates role-specific permissions for editing and canceling users. For each role in your system, permissions are created to allow editing and canceling users with that role. To edit or cancel a user with multiple roles, a sub-admin must have permission to manage ALL of those roles. The module intentionally excludes the administrator role from being a target, as allowing someone to edit an admin would defeat the security purpose of the module.
This is a Drupal 7 module that depends on the Chain Menu Access API module for proper menu access chaining.
Features
- Fine-grained role-based permissions for editing users - permissions are dynamically generated for each role in the system
- Fine-grained role-based permissions for canceling (deleting) user accounts
- Separate permission to create new user accounts without full admin access
- Access control for the users overview page (admin/people) showing only users that can be edited
- Automatic exclusion of administrator role from permission targets for security
- Support for users with multiple roles - sub-admins must have permission for ALL roles the target user has
- Integration with Views module through custom field handlers for edit and cancel links
- Compatibility with admin_views module for filtered user administration views
- Compatibility with password_policy_password_tab module for password management access
- Entity API integration for proper access callback handling
- Query tagging system for filtering users based on edit permissions in custom views
Use Cases
Departmental User Administrators
In a large organization with multiple departments, you can create role-based sub-admins who can only manage users within their department. For example, create a 'Marketing' role and a 'Marketing Admin' role. Give 'Marketing Admin' the permissions to edit and cancel users with the 'Marketing' role. Marketing admins can then manage marketing users without access to users in other departments.
Membership Site Management
For a membership site with multiple tiers (Basic, Premium, VIP), you can allow customer service staff to manage Basic and Premium members but restrict VIP member management to senior staff only. Create appropriate roles and grant permissions accordingly.
User Registration Delegation
Allow content editors or moderators to create new user accounts without giving them full administrative access. Grant only the 'Create new users' permission to these roles.
Hierarchical Administration
Implement a tiered administration system where senior admins can manage all user types while junior admins can only manage specific user groups. This prevents junior admins from accidentally modifying accounts of users with higher privileges.
Self-Service Portal
Combined with proper role assignment, allow team leads to edit members of their team (users with their team's role) without exposing other users' information.
Tips
- Always test permission configurations with test accounts before deploying to production
- Remember that 'edit users with no custom roles' only applies to users who have NO custom roles - users with any role require the specific role permission
- Use the query tag 'administerusersbyrole_edit_access' in custom Views to automatically filter users based on edit permissions
- The module works well with Views to create role-specific user administration interfaces
- Consider creating a clear role hierarchy to simplify permission management
- Document your permission structure as it can become complex with many roles
Technical Details
Admin Pages 1
/admin/people
User administration overview page. When accessed by users with 'access users overview' permission (instead of 'administer users'), only displays users that the current user has edit permission for based on their role-specific permissions.
Permissions 6
Hooks 5
hook_permission
Dynamically generates permissions for editing and canceling users based on all available roles in the system.
hook_menu_alter
Chains access callbacks for user-related menu items to implement the module's access control logic.
hook_query_alter
Alters queries tagged with 'administerusersbyrole_edit_access' to filter out users that the current user cannot edit.
hook_entity_info_alter
Replaces the user entity access callback to integrate with Entity API module.
hook_views_data_alter
Replaces Views field handlers for user edit and cancel links to respect this module's permissions.
Troubleshooting 5
Ensure the sub-admin role does NOT have the core 'administer users' permission. This permission bypasses all permissions from Administer Users by Role.
Make sure the Chain Menu Access API module is installed and enabled. Run database updates (update.php or drush updatedb) to complete the migration to version 2.x.
This is by design. To edit a user with multiple roles, you must have permission to edit ALL of their roles. Grant additional role-specific edit permissions as needed.
This is intentional security behavior. Users with the site's administrator role are excluded from being edited/canceled by sub-admins to prevent privilege escalation.
The module provides custom Views field handlers. Make sure you're using the correct field handlers and that the module's Views integration is loaded (clear caches if needed).
Security Notes 5
- The administrator role is intentionally excluded from being targeted by this module's permissions - this prevents privilege escalation where a sub-admin could modify an admin's password and gain full access
- The 'administer users' core permission always overrides this module's permissions - never grant it to sub-admin roles
- Users cannot cancel their own account through the bulk operations form when they have cancel permission - the form bypasses normal self-cancellation restrictions
- When granting cancel permissions, remember that canceling a user may delete their content depending on site configuration
- The module prevents editing of user ID 1 (the root admin) regardless of permissions