[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 dlh):

 [attachment:40922.2.diff] tries a new approach after thinking about
 [ticket:40922#comment:8]:

 1. Set the `map_meta_cap` argument to `false` when registering the
 `customize_changeset` post type.

 2. Add cases to `map_meta_cap()` for those capabilities set by default in
 `get_post_type_capabilities()`. In each case, map the capability to
 whatever `customize` maps to.

 3. In the `capabilities` argument to the post type, manually specify the
 caps that won't be set in `get_post_type_capabilities()` now that
 `map_meta_cap` is false.

 The combination of `'map_meta_cap' => false` and adding to the `switch`
 statement would allow us to bypass the default core handling in
 `map_meta_cap()` for `(edit|read|delete)_post`, which, it seems to me, has
 been our goal. For backwards-compatibility, if we want a call like this:

 `current_user_can( $customize_changeset->cap->edit_post,
 $changeset_post_id )`

 to be equivalent to:

 `current_user_can( 'customize' )`

 then by bypassing the default `post` mappings, we could skip an
 intermediate filter and provide that compatibility directly through the
 new `case`s.

 Additionally, passing the `*_customize_changeset` capabilities to
 `map_meta_cap()` means that those caps would also be passed to the
 `'map_meta_cap'` filter, which seems comparatively easier for developers
 to act on than `'edit_post'` or other generic values.

 However, two concerns with this approach are:

 1. What should happen with the other primitive capabilities noted in point
 (3) above, like `'delete_others_customize_changesets'`? Unless we provide
 a `map_meta_cap()` filter (or similar) for those, then they won't be
 granted to any role by default -- which might be OK, because core doesn't
 check for those capabilities directly, and they're set now to
 `'customize'`, which also isn't granted to any role by default.

 2. As I understand it, once we set `'map_meta_cap' => false`, we would be
 committing to handling changeset capabilities separately in perpetuity.

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