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.

[johnbillion]

Dupe of #19817. See also #19834.