[wp-trac] [WordPress Trac] #41332: Introduce dedicated capabilities for managing attachments

[WordPress Trac]

#41332: Introduce dedicated capabilities for managing attachments
-------------------------+-----------------------------
 Reporter:  flixos90     |      Owner:
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  Media        |    Version:
 Severity:  normal       |   Keywords:  2nd-opinion
  Focuses:               |
-------------------------+-----------------------------
 The capabilities for attachments currently use the regular post
 capabilities, so it is impossible to grant users specific attachment
 capabilities without giving them the same post capabilities. While this is
 fine for WordPress itself, it can be a pain for custom setups which need
 specific users to have access to their attachments without them being able
 to write a post.

 It is rather easy to change that by setting the `capability_type` argument
 for the `attachment` post type to `attachment` instead of `post`. To make
 this change compatible we could do two things:

 * For new setups, we could simply add the necessary capabilities to the
 respective roles. Note that this won't work retroactively as it would
 require a heavy migration none of us wants to invest their time for. :)
 * For existing setups, the necessary capabilities could be granted to
 users through a default filter for `'user_has_cap'`, so that it would
 basically map back to posts. Custom setups could remove that filter to
 invent their own handling of the attachment capabilities.

 It might be a bit of a tough idea to have two different ways for this to
 work, so if we are too wary of doing it, we could of course only do what I
 described in the second point everywhere.

 An alternative to the whole thing would be to not change anything but
 introduce a filter for the attachment post type's `capability_type`
 argument. Otherwise the value would need to be hacked on the already-
 registered post object. This solution would clearly lay the responsibility
 more on the plugin authors, which might make sense given the benefits do
 not really matter for core itself.

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