[wp-hackers] Custom Post Type Capabilities

[Andrew Nacin]

On Sun, May 30, 2010 at 10:54 AM, Brent Shepherd <thenbrent at gmail.com>wrote:

> I'm trying to use a custom capability_type in a call to register_post_type,
> but I've run into a few issues.
>
> For example, to allow a post of the custom type "movies" to be created and
> published, I thought that *'edit_movie'* and *'publish_**movie**s'* would
> be
> the only capabilities required.
>
> For the Movies admin menu to show however, *'edit**_movie**s' *is required
> (note the "s"). This wouldn't be an issue, except that then when *'edit_**
> movie**s'* is added to that user's role, they are also able to edit movies
> created by others, even though *'edit_others**_movie**s' *is not assigned
> to
> them. Is this a bug? My misinterpretation? Or are custom post type
> capabilities still a work in progress?


It looks like that last part is a bug, which I will look into. The rest of
it comes down to an understanding of the difference between the edit_post
and edit_posts capabilities.

edit_posts is a primitive capability, thus the user or role is literally
given this capability, not unlike manage_options or any of the others.

edit_post is a meta capability. The user/role is NOT given this capability
(doing so would do nothing). Instead, current_user_can is called with this
capability and the post ID is also passed. The function map_meta_cap then
maps it to the correct primitive capability based on the post -- if it is a
published post, they would need edit_publish_posts, if it is someone else's
post, they would need edit_others_posts, etc.

Meta capabilities are never plural -- read_post, edit_post, delete_post,
delete_user, etc. There's a full list of them in the inline documentation of
map_meta_cap().