[wp-hackers] Looking for the role-capability to set for add_submenu_page

[Andrew Nacin]

On Fri, Aug 27, 2010 at 7:28 PM, Paul <paul at codehooligans.com> wrote:

> I would suggest since you are setting up your own post type then go ahead
> and define your own user capability role. Then use one of the role manager
> plugins to select who can access the menu based on your defined role. Im my
> opinion this is cleaner since you are not tied to the build in WordPress
> user capabilities.
>
> So how is this done? Quite easily. From digging into this a few weeks ago I
> think there are 4 basic actions checked within post type term screen. These
> actions are 'manage', 'edit', 'delete' and 'assign. For your own post type
> just pick strings like 'myposttype_manage_terms', 'mediatags_edit_terms',
> 'mediatags_delete_terms', 'mediatags_assign_terms'. Replace 'myposttype'
> with something specific to your post type.
>
> In plugin examples I've reviewed the developer sets these up as a define in
> a main config file something like:
>
> define( 'MYPOSTTYPE_MANAGE_TERMS_CAP', 'myposttype_manage_terms' );
> define( 'MYPOSTTYPE_EDIT_TERMS_CAP', 'myposttype_edit_terms' );
> define( 'MYPOSTTYPE_DELETE_TERMS_CAP', 'myposttype_delete_terms' );
> define( 'MYPOSTTYPE_ASSIGN_TERMS_CAP',  'myposttype_assign_terms' );
>
> Then when you setup your post_type you just pass in the defines to the
> function as an array like:
>
> $default_caps                           = array();
> $default_caps['manage_terms']   = MYPOSTTYPE_MANAGE_TERMS_CAP;
> $default_caps['edit_terms']             = MYPOSTTYPE_EDIT_TERMS_CAP;
> $default_caps['delete_terms']   = MYPOSTTYPE_DELETE_TERMS_CAP;
> $default_caps['assign_terms']   = MYPOSTTYPE_ASSIGN_TERMS_CAP;
>

Custom capabilities are indeed the proper route.
manage/edit/delete/assign_terms are the capabilities for taxonomies, so it
looks like you're confusing the two. Same concept applies, with one
important caveat.

In the post type case, there are meta capabilities: edit_post, delete_post,
read_post. These meta capabilities should *not* be granted to the user, but
instead you need to roll your own meta handling the way core does it in
map_meta_cap() (we'll probably make core-like handling opt-in for 3.1).
Basically, you check the post, and if the post is private, then you need to
require the read_private_posts capability, etc.

There's also capability_type, which if set to 'mytype' will simply take the
default capability names and s/post/mytype/ them. That's much easier than
setting each cap, as long as you don't need that kind of fine-grained
control. But you still have to deal with meta handling.