id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc
20638,"Users without ""edit_posts"" capability unable to use async-upload if given capabilities for custom post type",fabrizim,,"The problem:

After checking a users capaiblity to ""upload_files"", async-upload.php pulls the current attachment during a fetch and checks the ""edit_post"" capability for that attachment. Because the meta capability mapped to attachment post type is ""edit_post"", if the current user does not have that enabled, the upload will fail. This can happen when an environment is setup with new roles that do not allow users to edit_posts, but do allow a different capability_type on a custom post type.

The fix:

Pull the attachments parent post and check the edit_post capability for that posts content type instead.

Bug in Source:

http://core.trac.wordpress.org/browser/trunk/wp-admin/async-upload.php#L37

Temporary Workaround:

{{{
add_filter('user_has_cap', 'async_upload_cap_fix', 10, 3);
function async_upload_cap_fix($all, $caps, $args)
{
    $cap = $args[0];
    if( basename($_SERVER['SCRIPT_NAME']) != 'async-upload.php' || $cap != 'edit_post' ) return $all;
    $post = get_post( $args[2] );
    if( get_post_type( $post ) != 'attachment' ) return $all;
    // get the parent post
    $post = get_post( $post->post_parent );
    $post_type_object = get_post_type_object( $post->post_type );
    if( user_can( $args[1], $post_type_object->cap->edit_post, $post->ID) ){
        foreach( $caps as $cap ) $all[$cap] = 1;
    }
    return $all;
    
}
}}}

I am not sure how to add a patch, or how you would best like to add it in, so I will just leave that temporary workaround for now.

",defect (bug),closed,normal,,Upload,3.3.2,normal,duplicate,,