Introduce dedicated capabilities for managing attachments

[flixos90]

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.

[flixos90]

All of these are part of a larger goal.

[dlh]

Hi @flixos90,

@westonruter and I have been looking into something similar with the changeset post type in #40922, at least in that it involves potentially changing default capabilities for an existing post type.

What's best for attachment capabilities might not be best for changeset capabilities, but to the extent it would be useful to consider them consistently, I'd be happy to help.

[flixos90]

@dlh Great, do you have some proposals (or possibly code already) for how you are intending to do this?

41332.diff​ is a take on how it could work for attachments. It uses a straightforward approach, where the capability_type of the post type is simply changed to 'attachment', and then these "kind of meta" capabilities are granted through a user_has_cap hook based on the regular 'post' post type capabilities (which are actually the properties of each post type's $cap object).

The reason I prefer this approach over using map_meta_cap() is that I consider these capabilities essential in that, if we were to start WordPress development now, they would be primitive capabilities and not be mapped at all, similar like post and page capabilities are. Furthermore this approach is more simple.

As you can see, the by far biggest part of the patch are tests: This is because I thought it's useful to have a dedicated area for this new kind of capability. Now we not only have primitive capabilities and meta capabilities, but also these "fake primitive" capabilities that are granted through user_has_cap ([41268] actually added the first one). Therefore there are now similar checks made for those new capabilities in Tests_User_Capabilities::testFakePrimitiveCapsTestsAreCorrect(). The capabilities themselves are available through Tests_User_Capabilities::getFakePrimitiveCapsAndRoles(). By the way, the term "fake primitive" is just the first thing I came up with. There's probably a better term for this. These new kind of tests should probably committed separately if we agree on doing it, before the actual attachment changes for this ticket.

There are two minor other adjustments in tests as well: In one test, I replaced a capability related to the 'post' post type with another one so that it doesn't affect the fake primitive 'attachment' capabilities. In another test I simply replaced the old capability name for editing attachments with the new one.

@johnbillion What's your thought on this?

[flixos90]

The infrastructure changes from here are now part of #44468. Once that ticket is figured out, I'll remove those bits from here, and we can move this forward.

[SergeyBiryukov]

Related: #19834

[danielbachhuber]

Related https://core.trac.wordpress.org/ticket/23391#comment:4