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

[Paul]

Ah very cool. Thanks for the details on post type meta cap, master Nacin. 

P-

On Aug 27, 2010, at 10:15 PM, Andrew Nacin wrote:

> 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.
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers