[wp-trac] [WordPress Trac] #39174: Introduce network roles

WordPress Trac noreply at wordpress.org
Thu Dec 8 04:46:18 UTC 2016


#39174: Introduce network roles
-----------------------------+------------------------------
 Reporter:  flixos90         |       Owner:
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Role/Capability  |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:  multisite
-----------------------------+------------------------------

Old description:

> We have been discussing introducing network roles during multisite
> office-hours several times. The original concept for roles on
> multisite/multinetwork was the following:
>
> ''Site Administrator < Network Administrator (currently also called
> "Super Admin" < Global Administrator < Super Admin (special access via
> `$super_admins` global, has all capabilities automatically)''
>
> This ticket is about network roles in particular, but we need to figure
> out the entire concept we'll be going with beforehand.
>
> After the initial discussions which happened several weeks ago, I started
> playing around with that idea and created a plugin with network roles
> which is available at https://github.com/felixarntz/wp-network-roles. The
> details on that plugin are described in this Google doc (and are probably
> worth reading to understand the following discussion better):
> https://docs.google.com/document/d/1MWwwKmhBJookr5dEcYga4sBtCwvx-
> K8uSucBFx6SP9U/edit#
>
> I just had a long conversation with @johnbillion around this topic where
> we agreed on some ideas, disagreed on others, were entirely unsure about
> others. The following bullet points sum up what we talked about / which
> questions we raised.
> * The original idea of network roles was that these roles behave similar
> to regular site roles: They all have a set of capabilities they can
> perform. These capabilities can apply to either the site or network
> level. This allows for roles like the current "Super Admin" / "Network
> Administrator" that has access to everything a site administrator has,
> but also to any network admin functionality - however it also allows for
> roles like a possible "Network Editor" which would be the same as if a
> user had the "Editor" role on every site of the network.
>     * Should we support both of these concepts? Or should network roles
> only affect the actual network admin area? If the latter, which roles
> would we even need in Core itself (in addition to the "Super Admin" /
> "Network Administrator")? This decision would also affect whether we
> should support inheritance of network capabilities to site capabilities
> or whether network roles would just be additional kind of roles for a
> user. An example to clarify:
>         * First approach: The "Super Admin" / "Network Administrator" has
> all the capabilities a regular site administrator has, plus the network
> admin area capabilities (like `manage_network` or
> `manage_network_options`), so they automatically behave as if they were a
> site administrator on every site in the network.
>         * Second approach: The "Super Admin" / "Network Administrator"
> role only has network admin area capabilities (like `manage_network` or
> `manage_network_options`), so the user also needs to have the site
> administrator role for each site they want to access. (probably not?)
>     * If we support inheritance, can we handle the two kinds of roles
> together? A "Network Administrator" that has access to the network admin
> area is conceptually a bit different from a "Network Editor" who can only
> access all site admin areas on that network. If we find solid descriptive
> names, we're probably good here. For example, instead of having a
> "Network Administrator" being the role where one can access the network
> admin and at the same point be an administrator on all the network's
> sites, maybe that role should rather be called "Network Manager", while
> "Network Administrator" is a different role which basically means that
> user is an administrator on all the network's sites, but cannot access
> the network admin area.
>     * We would certainly need to handle that in a slow migration path: If
> we introduce a network role system with a predefined set of capabilities
> in let's say 4.8, we write a dev-note at the same time that tells plugin
> authors that they now need to add their custom capabilities to the new
> network role because that role no longer automatically can do anything.
> At this point however we still keep the current super admin functionality
> in sync so that the role actually still can do anything. We wait until
> 2-3 releases later to actually remove the sync thing, which means we get
> rid of the `site_admin` network option and from that point on use
> `is_super_admin()` and `get_super_admins()` only to retrieve users
> specified in the `$super_admins` global.
>     * Is this the right approach at all? Currently the "Super Admin" /
> "Network Administrator" can do "anything but..." rather than having a
> predefined set of capabilities. While we can address that with a
> migration like described above, we still need to think about whether it
> _is_ the right way to do it. Maybe we need a concept like "Role X can do
> anything under certain circumstances unless specifically denied".
> * How should we handle Multisite / Multinetwork? Multisite is the "easy"
> thing here - for all of the changes here we need to consider Multinetwork
> especially, even though it is not really supported by Core at this point.
> * What do we think a "Super Admin" is? Is that a network administrator
> with specific capabilities, is it kind of a global administrator or is it
> a special thing that can do anything, thus not having a predefined set of
> capabilities? Core itself doesn't really know what a super admin is at
> this point. In most setups it is a network administrator / network
> manager as it's stored in a network option. But if you use the
> `$super_admins` global, it suddenly turns into some kind of a global
> administrator. Which of the two are we going to stick with for that
> terminology?
> * Can we rename the term "Super Admin" at all (in terms of BC)? It would
> probably become either "Network Administrator" or "Network Manager"
> depending on the approach. If we can't rename it and keep the name for
> the "network administrator" role, how are we going to handle the higher
> role level?
>
> This will likely become a feature project, but this ticket is for more
> discussion beforehand.

New description:

 We have been discussing introducing network roles during multisite office-
 hours several times. The original concept for roles on
 multisite/multinetwork was the following:

 ''Site Administrator < Network Administrator (currently also called "Super
 Admin") < Global Administrator < Super Admin (special access via
 `$super_admins` global, has all capabilities automatically)''

 This ticket is about network roles in particular, but we need to figure
 out the entire concept we'll be going with beforehand.

 After the initial discussions which happened several weeks ago, I started
 playing around with that idea and created a plugin with network roles
 which is available at https://github.com/felixarntz/wp-network-roles. The
 details on that plugin are described in this Google doc (and are probably
 worth reading to understand the following discussion better):
 https://docs.google.com/document/d/1MWwwKmhBJookr5dEcYga4sBtCwvx-
 K8uSucBFx6SP9U/edit#

 I just had a long conversation with @johnbillion around this topic where
 we agreed on some ideas, disagreed on others, were entirely unsure about
 others. The following bullet points sum up what we talked about / which
 questions we raised.
 * The original idea of network roles was that these roles behave similar
 to regular site roles: They all have a set of capabilities they can
 perform. These capabilities can apply to either the site or network level.
 This allows for roles like the current "Super Admin" / "Network
 Administrator" that has access to everything a site administrator has, but
 also to any network admin functionality - however it also allows for roles
 like a possible "Network Editor" which would be the same as if a user had
 the "Editor" role on every site of the network.
     * Should we support both of these concepts? Or should network roles
 only affect the actual network admin area? If the latter, which roles
 would we even need in Core itself (in addition to the "Super Admin" /
 "Network Administrator")? This decision would also affect whether we
 should support inheritance of network capabilities to site capabilities or
 whether network roles would just be additional kind of roles for a user.
 An example to clarify:
         * First approach: The "Super Admin" / "Network Administrator" has
 all the capabilities a regular site administrator has, plus the network
 admin area capabilities (like `manage_network` or
 `manage_network_options`), so they automatically behave as if they were a
 site administrator on every site in the network.
         * Second approach: The "Super Admin" / "Network Administrator"
 role only has network admin area capabilities (like `manage_network` or
 `manage_network_options`), so the user also needs to have the site
 administrator role for each site they want to access. (probably not?)
     * If we support inheritance, can we handle the two kinds of roles
 together? A "Network Administrator" that has access to the network admin
 area is conceptually a bit different from a "Network Editor" who can only
 access all site admin areas on that network. If we find solid descriptive
 names, we're probably good here. For example, instead of having a "Network
 Administrator" being the role where one can access the network admin and
 at the same point be an administrator on all the network's sites, maybe
 that role should rather be called "Network Manager", while "Network
 Administrator" is a different role which basically means that user is an
 administrator on all the network's sites, but cannot access the network
 admin area.
     * We would certainly need to handle that in a slow migration path: If
 we introduce a network role system with a predefined set of capabilities
 in let's say 4.8, we write a dev-note at the same time that tells plugin
 authors that they now need to add their custom capabilities to the new
 network role because that role no longer automatically can do anything. At
 this point however we still keep the current super admin functionality in
 sync so that the role actually still can do anything. We wait until 2-3
 releases later to actually remove the sync thing, which means we get rid
 of the `site_admin` network option and from that point on use
 `is_super_admin()` and `get_super_admins()` only to retrieve users
 specified in the `$super_admins` global.
     * Is this the right approach at all? Currently the "Super Admin" /
 "Network Administrator" can do "anything but..." rather than having a
 predefined set of capabilities. While we can address that with a migration
 like described above, we still need to think about whether it ''is'' the
 right way to do it. Maybe we need a concept like "Role X can do anything
 under certain circumstances unless specifically denied".
 * How should we handle Multisite / Multinetwork? Multisite is the "easy"
 thing here - for all of the changes here we need to consider Multinetwork
 especially, even though it is not really supported by Core at this point.
 * What do we think a "Super Admin" is? Is that a network administrator
 with specific capabilities, is it kind of a global administrator or is it
 a special thing that can do anything, thus not having a predefined set of
 capabilities? Core itself doesn't really know what a super admin is at
 this point. In most setups it is a network administrator / network manager
 as it's stored in a network option. But if you use the `$super_admins`
 global, it suddenly turns into some kind of a global administrator. Which
 of the two are we going to stick with for that terminology?
 * Can we rename the term "Super Admin" at all (in terms of BC)? It would
 probably become either "Network Administrator" or "Network Manager"
 depending on the approach. If we can't rename it and keep the name for the
 "network administrator" role, how are we going to handle the higher role
 level?

 This will likely become a feature project, but this ticket is for more
 discussion beforehand.

--

Comment (by flixos90):

 A few related bits of information / background:

 * #37616 will lay the foundation for migrating the current super admin
 system to dedicated role / capability checks.
 * #37593 is about replacing the term "Super Admin" with "Network
 Administrator" in the admin. Depending on the outcome of the discussion
 from this very ticket, that ticket might become invalid or its goal might
 even become the opposite (Replace "Network Administrator" with "Super
 Admin"?).
 * The way the WP Multi Network plugin (https://github.com/stuttter/wp-
 multi-network) works should be considered. While it doesn't handle
 capabilities on its own for the most part, it is probably helpful to have
 a look for the discussion, also in terms of which capabilities it
 introduces.
 * For some insight on how the distinction between Network Administrator
 <--> Global Administrator is likely handled in current custom Multinetwork
 setups, https://github.com/washingtonstateuniversity/WSUWP-
 Platform/blob/master/www/wp-content/mu-plugins/wsu-network-users.php and
 https://github.com/felixarntz/multisite-fixes/blob/master/mu-plugins/wpmn-
 global-admins.php might be interesting. While both follow a simpler
 approach than using a role system (which I don't think is usable here), it
 might give an idea how some people handle that functionality currently in
 their custom setups.

 Btw "Description modified" is only about a few format tweaks, so don't
 bother re-reading the ticket description if you have already.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/39174#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list