[wp-trac] [WordPress Trac] #36940: Break `manage_sites` capability up into more targeted caps

[WordPress Trac]

#36940: Break `manage_sites` capability up into more targeted caps
--------------------------------+-----------------------------------
 Reporter:  johnjamesjacoby     |      Owner:
     Type:  defect (bug)        |     Status:  new
 Priority:  normal              |  Milestone:  4.6
Component:  Networks and Sites  |    Version:  3.0
 Severity:  normal              |   Keywords:  has-patch 2nd-opinion
  Focuses:  multisite           |
--------------------------------+-----------------------------------
 The `manage_sites` capability is currently used as a blanket, to cover all
 needs when it comes to editing a site in a multisite installation.

 Started in #15800 (and having chatted with @jeremyfelt at length) we'd
 like to break `manage_sites` up into new capabilities that more acutely
 convey what part of a site someone is allowed to edit.

 The goal is to allow users with `/network` admin access to have more fine-
 grained control over what parts of a site they can edit. For example:
 `manage_site_settings = false` so a user can modify site themes & users,
 but not have access to the raw option data.

 We are imagining they would look something like:

 * `manage_site_info` (`site-info.php`)
 * `manage_site_settings` (`site-settings.php`)
 * `manage_site_themes` (`site-themes.php`)
 * `manage_site_users` (`site-users.php`)

 In addition:

 * We would pass the site ID through `current_user_can()` to provide
 additional context
 * Switch to using `create_sites` in `site-new.php` (vs. `manage_sites`
 which was likely a copy-paste assumption that the capabilities across
 these similar files should match)

 ----

 More paraphrasing of our past 4 months of chat in #core-multisite:

 * Because only WordPress Super Admins can access any of these by default,
 renaming these capabilities should be considered a backwards compatible
 change
 * We /could/ go as far as mapping all of these new caps to `manage_sites`
 to maintain compatibility, but for plugin authors wishing to take
 advantage of this, it would require an additional `map_meta_cap` override
 that we would like to try and avoid
 * This should not result in much code churn, and will only change
 multisite files, and a handful of functions that special-case multisite
 using the `manage_sites` capability check
 * We would still keep `manage_sites` in a few higher-level places (as a
 site equivalent to `edit_posts`) to ensure that a user has access to
 certain UI elements that allow them entry to more detailed site editing

--
Ticket URL: <https://core.trac.wordpress.org/ticket/36940>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform