[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                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |     Focuses:  multisite
-----------------------------------+------------------------

Comment (by johnjamesjacoby):

 Replying to [comment:2 jeremyfelt]:
 > Are there any downsides to using meta caps instead? It seems like the
 right scenario for it.
 We still need to update the individual files to check for the newly mapped
 caps.

 The reason to use `map_meta_cap` is to make assumptions that one
 capability conditionally maps to another capability. In this case, can
 `manage_site_settings` map to `manage_sites`? Yes. But if we need to rely
 on `map_meta_cap` internally for this, overriding that behavior is more
 difficult than a user not having the cap, because no users ever have these
 caps directly, which means allowing or denying from the global `$wp_roles`
 array will no longer work. Instead, one would need to also hook into
 `map_meta_cap` to override the previous `map_meta_cap` conclusion, and
 that is not terribly straight forward.

 What would we win? Is it worth the cost of complexity since there is no
 use-case inside of WordPress proper where a user would have `manage_sites`
 and not any of the others?

 > If we introduce these, are there other places in core where they may
 apply?

 `site-new.php` is the only other direct change that I found. It uses
 `create_sites` in one place, and `manage_sites` in another, so you can't
 actually create a new site unless you can also `manage_sites` which, I
 guess maybe makes sense, but one cap shouldn't be a prerequisite for
 another (that's what roles are for.)

 Any other places where `manage_sites` is used, is as a general assumption
 that the current user can manage "all" sites, though not necessarily a
 specific one.

 > Is `manage_site_` the right name when thinking about future
 compatibility for other caps at the site level?

 Probably... The `manage_` prefix is used in many places, and I think
 `_site_` is a good next-level namespace to identify that it's a network-
 area site-specific capability check. `edit_` vs. `manage_` might work too,
 but is the ability to manage something is different than the ability to
 edit something?

 If we wanted parity with Posts, for example, then we'd opt for `edit_site`
 and then toss that into `map_meta_cap()` or some other new multisite
 specific equivalent. Right now, we don't map any network area caps that I
 can think of, so we're starting to rabbit hole ourselves. :)

 > A plugin can already alter the caps required for individual tabs.

 A plugin can only alter the caps that are checked to make the tabs appear.
 The URL for the files each tab links to can still be accessed by any user
 that has the `manage_sites` capability and hits the URL directly.

 ---

 In summary:

 * Each file needs its own unique capability check at the top.
 * If we decide to use `map_meta_cap` to check the `$pagenow` instead, that
 will work, but be less efficient and require more hacks to work-around.
 And we'd likely want to use the Post object and it's single-caps as a
 guide.
 * `map_meta_cap` filtering seems unnecessary in core, since no Super Admin
 would ever not have any of the caps being mapped to `manage_sites`.

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