[wp-trac] [WordPress Trac] #28371: Use media post type object capabilities to allow user to see actions

[WordPress Trac]

#28371: Use media post type object capabilities to allow user to see actions
-----------------------------+------------------------------
 Reporter:  lpointet         |       Owner:
     Type:  enhancement      |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Role/Capability  |     Version:  trunk
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:  administration
-----------------------------+------------------------------
Description changed by SergeyBiryukov:

Old description:

> As media is a post type, we are storing a post type object and some
> capabilities.
> For example, {{{create_posts}}} capability is mapped to
> {{{upload_files}}} one.
>
> When the admin interface is supposed to show a button or check the user
> capability to add a new post (with the 'post' or 'page' post type, this
> time), we retrieve the corresponding post type object to check against
> capabilities registered here.
>
> This is not the case when doing it for media post type.
>
> Indeed, here is how wp-admin/post-new.php is handling the cap check:
> https://core.trac.wordpress.org/browser/trunk/src/wp-admin/post-
> new.php#L42
> Now, here is how wp-admin/media-new.php is doing:
> https://core.trac.wordpress.org/browser/trunk/src/wp-admin/media-
> new.php#L15
>
> I think we should remove these direct {{{upload_files}}} checks and do it
> the other way (with post type object) instead. This implies doing it at
> least at these times:
>  - displaying an UI action (button, link)
>  - doing a cap check
>
> The consequence is that a plugin/theme developer cannot just rely on the
> post type object to update the needed capabilities. They must also hook
> into {{{map_meta_cap}}} in order to do something when the hard-coded
> capabilities are checked.
>
> I've seen some tickets that seem to address a part of the subject, but
> not really this particular thing:
>  - https://core.trac.wordpress.org/ticket/19834
>  - https://core.trac.wordpress.org/ticket/20745

New description:

 As media is a post type, we are storing a post type object and some
 capabilities.
 For example, {{{create_posts}}} capability is mapped to {{{upload_files}}}
 one.

 When the admin interface is supposed to show a button or check the user
 capability to add a new post (with the 'post' or 'page' post type, this
 time), we retrieve the corresponding post type object to check against
 capabilities registered here.

 This is not the case when doing it for media post type.

 Indeed, here is how wp-admin/post-new.php is handling the cap check:
 https://core.trac.wordpress.org/browser/trunk/src/wp-admin/post-
 new.php#L42
 Now, here is how wp-admin/media-new.php is doing:
 https://core.trac.wordpress.org/browser/trunk/src/wp-admin/media-
 new.php#L15

 I think we should remove these direct {{{upload_files}}} checks and do it
 the other way (with post type object) instead. This implies doing it at
 least at these times:
  - displaying an UI action (button, link)
  - doing a cap check

 The consequence is that a plugin/theme developer cannot just rely on the
 post type object to update the needed capabilities. They must also hook
 into {{{map_meta_cap}}} in order to do something when the hard-coded
 capabilities are checked.

 I've seen some tickets that seem to address a part of the subject, but not
 really this particular thing:
  - #19834
  - #20745

--

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