Thanks Andrew - depends on how literally you read Justin's post I guess. I read "I’ve also added in a couple of extra capabilities that were not shown in my previous tutorial on post types: delete_posts and delete_others_posts." and didn't mentally add "because WordPress doesn't do it." :-)
I'll use the overloading instead of being lazy and look out for the patch - is it looking definite for 3.1? A. On 21 Oct 2010, at 12:29, Andrew Nacin wrote: > On Thu, Oct 21, 2010 at 7:08 AM, Andrew Macaulay-Brook > <[email protected]>wrote: > >> I can't work out whether this is covered by >> http://core.trac.wordpress.org/ticket/14122 or not. >> >> I'm using a custom post type called property, assigning capabilities using >> 'capability_type' => 'property' and then giving my Editors *_property and >> *_propertys capabilities wherever I can see they already have *_post or >> *_posts. >> >> The rationale for all this is that it lets me turn off all the capabilities >> for blog Posts, hiding the Posts menu for Editors, as this site doesn't use >> the blog. I then give my client an Editor level login. >> >> I'm mapping meta-capabilities using Justin Tadlock's code at >> http://justintadlock.com/archives/2010/07/10/meta-capabilities-for-custom-post-types >> >> Problem: Neither my clients, nor the Admin login can Trash custom posts. >> >> It seems that using the argument 'capability_type' => 'property' only sets >> up the following mappings in the post type object: >> >> <!-- Capability mapping: stdClass Object >> ( >> [edit_post] => edit_property >> [edit_posts] => edit_propertys >> [edit_others_posts] => edit_others_propertys >> [publish_posts] => publish_propertys >> [read_post] => read_property >> [read_private_posts] => read_private_propertys >> [delete_post] => delete_property >> ) >> --> >> >> ... which I generated using $post_type = get_post_type_object( >> $post->post_type ); print_r($post_type->cap); >> >> It looks like the mappings for $post_type->cap->delete_posts and >> $post_type->cap->delete_others_posts aren't being set up. >> > > This is indeed the same ticket at issue. > > If you read Justin's post again, you'll see that he deliberately sets up > those additional capabilities by overloading what gets passed to the > capabilities array. > > I haven't yet got around to committing my meta capabilities patch for 3.1 > yet, basically because after a few attempts I don't think I've quite nailed > it yet. > > But what you'll see is when map_meta_cap is true (a new flag for > register_post_type), then these additional capabilities will need to be set > up, or WordPress will do it for you, based on capability_type. > > Hope that makes sense. > > Nacin > _______________________________________________ > wp-testers mailing list > [email protected] > http://lists.automattic.com/mailman/listinfo/wp-testers Andrew Macaulay-Brook, BEng MBCS CITP, trading as theburo.net mailto:[email protected] • http://www.theburo.net/ _______________________________________________ wp-testers mailing list [email protected] http://lists.automattic.com/mailman/listinfo/wp-testers
