Dion Hulse

On a large multisite network, granting a group of people the same role across many sites usually means adding each user to each site by hand — and remembering to remove them everywhere when they leave. User Teams turns that into:
<ol>
<li>Create a team, pick a role.</li>
<li>Add the user to the team.</li>
<li>They have that role everywhere the team applies.</li>
<li>Remove them from the team → access is gone everywhere.</li>
</ol>
User Teams is multisite-only by design — on a single-site install, native WordPress roles and capabilities already cover the whole feature set, so WordPress won’t offer it for activation there.
<h4>Features</h4>
<ul>
<li>Teams with roles. Each team carries a WordPress role (editor, administrator, a custom role, or none).</li>
<li>Runtime capability grants. Team access is added via the <code>user_has_cap</code> filter, so removing a user from a team drops their access on the next request — no stale capabilities usermeta to clean up.</li>
<li>Multisite-native. Team definitions are real <code>wp_users</code> rows (“team accounts”), so <code>WP_Users_List_Table</code>, <code>is_user_member_of_blog()</code>, and every column-adding plugin “just work”.</li>
<li>Site scoping. A team can apply network-wide (including sites added later) or to a specific list of sites, each with its own role.</li>
<li>Admin UI. Network Admin → Users → Teams. Per-user checkboxes on the Edit User screen. Team rows with “— Team” markers on the Users list table.</li>
<li>Cleans up after itself. Deleting a team removes its memberships. Deleting a user drops their memberships. Deleting a site removes its grants from any team that targeted it.</li>
</ul>
<h4>How access is granted</h4>
Team-derived capabilities are merged in at runtime, never written into the member user’s own meta:
<ul>
<li><code>user_has_cap</code> — adds the team role’s capabilities to the user’s effective caps, plus <code>role-{slug}</code> for plugins that check by role.</li>
<li><code>get_blogs_of_user</code> — adds team-linked sites to the user’s “My Sites” navigation.</li>
<li><code>get_user_metadata</code> — returns an empty-array <code>{prefix}{blog_id}_capabilities</code> for team members so <code>is_user_member_of_blog()</code> returns true without stamping real capabilities on the user. Workaround for <a href="https://core.trac.wordpress.org/ticket/65096" rel="nofollow ugc">Core #65096</a>.</li>
</ul>
The user’s actual <code>{prefix}capabilities</code> usermeta is never modified. That’s what makes team-based access instantly revocable.
<h4>Capability requirements</h4>
<ul>
<li>Managing teams (create / edit / delete) requires <code>manage_network_users</code> — super admin only.</li>
<li>Attaching an existing team to the current site uses <code>promote_users</code>, the same cap as inviting an individual user there.</li>
</ul>
Team management is restricted to super admins so a compromised single-site admin can’t grant themselves access across the network.
<h4>Extension filters</h4>
<ul>
<li><code>user_teams_team_caps_for_user( $caps, $user_id, $blog_id )</code> — modify the capability map computed from a user’s teams.</li>
<li><code>user_teams_team_applies_to_site( $applies, $team_id, $blog_id, $team )</code> — gate coverage (e.g. pause a team during a freeze).</li>
<li><code>user_teams_team_save_data( $data, $team_id_or_null, $op )</code> — filter sanitised input on create/update.</li>
</ul>

User Teams

Unix-style user groups for WordPress multisite. Create a team, give it a role, drop users in — access lights up across the network.

room34

NEW IN VERSION 2.0.0: Users with a custom role will now only see the posts or pages they are assigned to. We’ve also streamlined the admin interface for easier configuration, and included additional instructions to help you get the proper capabilities assigned to your custom roles.
Custom Access Roles allows you to create, edit and delete custom roles for editing content. It was created to fill a need for a role editor plugin that is focused on providing easy-to-use admin tools for restricting content editing access. It is not concerned with restricting viewing access on the front end.
It is specifically intended for large sites with multiple content editors, where editors (by role, not individually) need to be restricted to only being able to edit specific areas of the site.
With this plugin, administrators of large sites have relatively fine-grained control over which user roles can edit which content, making it possible to manage a team of editors without concern that they will (accidentally or deliberately) edit content they should not have access to.
You can define a fully customized set of capabilities for each role, along with defining a specific set of post categories, pages, and custom post types to which those capabilities apply. For all other content, the role will have read-only access.
Custom Access Roles provides an easy interface for managing these roles and capabilities, with checkboxes for each capability grouped by the standard roles they’re associated with, plus checkboxes for each post category, page, and custom post type, presented in an organized hierarchy.

Custom Access Roles

Create custom roles with editing capability for only specific pages, categories and post types.

User Teams vs Custom Access Roles