Opened 9 years ago
Last modified 5 years ago
#35806 new enhancement
Add filter to capability check when checking if user row is editable
Reported by: | nathanshubert | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Users | Keywords: | |
Focuses: | administration | Cc: |
Description
Suggestion
Currently in class-wp-users-list-table.php
the check for wether or not a displayed user is editable is done using current_user_can( 'list_users' )
on line 398. This is inflexible and doesn't allow finer control over which users are editable by which other users. I suggest filtering this check or filtering the specific capability.
Scenario
I create WordPress sites for clients in an agency setting. Our sites are highly bespoke, and changing themes or disabling plugins will cause harm to their site. Must-use plugins have their limitations and removing other themes from wp-content/themes only goes so far. On these sites, I want the client to administrate all aspects of the site, except for changing the theme or disabling plugins.
To this end, I've created a plugin defining a custom 'manager' role with. This role is highly permissive, save administrating themes or plugins. On the user side I want managers to be able to create users with manager or lower roles, but not create/edit/delete administrators. I can exclude administrators from the list using a users_list_table_query_args
filter, but for transparency I want administrators to be listed, just not editable.
If either the check or the capability in if ( current_user_can( 'list_users' ) ) {
went through apply_filters
, I could define a custom capability and filter this check, producing the desired result, or create some other logic.
I feel as though this enhancement would be of great benefit, allowing finer grain user control.
Change History (3)
#2
in reply to:
↑ 1
@
9 years ago
Replying to boonebgorges:
A more integrated solution would be to introduce a mapped capability
'list_user'
, and use it instead of'list_users'
when deciding whether to display a given row. Then your plugin could customize the capability by using the 'map_meta_cap' filter.
That's a great idea, I like that even better ????
A more integrated solution would be to introduce a mapped capability
'list_user'
, and use it instead of'list_users'
when deciding whether to display a given row. Then your plugin could customize the capability by using the 'map_meta_cap' filter.