[wp-trac] [WordPress Trac] #40922: Use finer-grained capabilities with `customize_changeset` post type

[WordPress Trac]

#40922: Use finer-grained capabilities with `customize_changeset` post type
----------------------------------------+------------------
 Reporter:  dlh                         |       Owner:
     Type:  enhancement                 |      Status:  new
 Priority:  normal                      |   Milestone:  4.9
Component:  Customize                   |     Version:  4.7
 Severity:  normal                      |  Resolution:
 Keywords:  has-patch needs-unit-tests  |     Focuses:
----------------------------------------+------------------

Comment (by flixos90):

 @dlh [attachment:40922.6.diff] is how I'd envision it:

 * The capabilities checked are `edit_customize_changesets` and so on (as
 in your patch).
 * The singular capabilities like `edit_customize_changeset`,
 `delete_customize_changeset` etc. are mapped in `map_meta_cap()` anyway
 due to the `map_meta_cap` argument when registering the post type, so we
 only need to take care of the plural capabilities.
 * In `wp_maybe_grant_customize_changesets_capabilities()`, give the
 capability to every user that has the `edit_theme_options` capability.
 This should preferably use the `customize` capability, but that is not a
 primitive capability, thus not available in `$allcaps`. `customize`
 however maps to `edit_theme_options`, so it would have the same effect for
 core.

 The reason I like this approach is that it's simpler than yet another
 clause in `map_meta_cap()`, and it's much easier to adjust. If I want to
 give users this capability directly (as a primitive cap) in my custom
 setup, all I need to do is remove the filter hook. If it happens in
 `map_meta_cap()`, I need to use the filter there to override the default
 way with custom logic, which is much more involved.
 Another reason is that I consider `map_meta_cap()` mainly useful for
 mapping actual meta capabilities (like singular capabilities for one
 object to more general plural capabilities): Things like
 `edit_customize_changesets` (and even `customize` although it's currently
 part of `map_meta_cap()`) are in my opinion primitive capabilities, and
 the only reason we don't treat them as such is that we can't just add new
 primitive capabilities in WordPress because of all the database migration
 that would require. In other words, if we had known from the beginning of
 core development about these capabilities, they would live in the database
 alongside the others. Therefore adding these capabilities through the
 `user_has_cap` filter makes more sense to me because that actually filters
 the data as if the user had these capabilities as primitive ones. If that
 makes sense. That's obviously just my POV.

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