Capability check fails for custom post type revision edit (& map_meta_cap no good)

[anmari]

I am using nightly build (1 day old).

Steps to reproduce:

1. Register post type with capability 'event'.

2. Edit custom post type till you have some revisions.

3. Attempt to view a revision. One gets sent to the normal posts edit.php screen.

I looked at revision.php and managed to work out that it was failing at

	if ( !current_user_can( 'read_post', $revision->ID ) || !current_user_can( 'read_post', $post->ID ) )

I tried

	if ( !current_user_can( 'read_'.$post->post_type, $revision->ID ) || !current_user_can( 'read_'.$post->post_type, $post->ID ) )

but that still failed.

I commented out the check and was then able to view the revision.

I think this affects the autosave too as that was how I started looking at it.

So it looks like the problem is in the current_user_can check somehow not working out that the author or admin user is allowed to view or edit the revision ?

Ticket #14122 may be relevant (detailed discussion about meta-caps?)

I found also Ticket #14749 says it fixed something similar, but that was not a capability problem, so not relevant.

I back tested and behaviour occurs in 3.0, 3.1 and the nightly build

Please paste the code you're using to define the post type.

Also, add the following code somewhere and paste the output:

function debug_role() {
	global $wp_roles;

	echo '<pre>';
	print_r( $wp_roles->get_role('your_role')->capabilities );
}
add_action('init', 'debug_role');

Obviously, replace 'your_role' with whatever role you're seeing the problem with.

Hello,

I worked out that the problem was that (in my plugin) while the admin user had plural capabilities "view_events", "edit_events", they did not have singular capabilities "view_event", "edit_event".

I had also recreated problem with another post type using brad's custom post type UI plugin (to rule out my code) and then justin's members plugin to add the custom capabilities to admin.

Using the CPT UI with default capability 'post' all is fine, can access revisions.
Change to custom capability, then one MUST add plural and singular of the capabilities. Plural not adequate access.

I then looked at edit.php to see what it was checking.

it does this:

if ( !current_user_can($post_type_object->cap->edit_posts) )

while revision.php does not use the post type object and is also a singular check:

if ( !current_user_can( 'read_post', $revision->ID ) || !current_user_can( 'read_post', $post->ID ) )

SO anyway immediate fix is:

make sure that the user has the singular capability at the very least, not just plural.

Philosophically should a user who has the plural capability be allowed to access the post even if they do not have the singular capability. This would make it functions same as edit screens etc?

Your debug code would have revealed this I think - do you need me to do anymore?

regards, anmari

plural capabilities = primitive capabilities (are actually assigned to the role)

singular capabilities = meta capabilities (map to one or more primitive capabilities)

Long story short, if you add 'map_meta_cap' => true to your post type definition, it should work.

Maybe nacin can shed some light on wether we should change from the raw 'read_post' to ->cap->read_post in revision.php

Hi,
added 'map_meta_cap' => true, to the post_type registration

Number of things then happen (latest nightly build and 3.2.1):

1) edit, and quick edit and trash links on custom post type manage screen dissappears (only have view) - take out the map_meta_cap and at least I can edit.

2) Bunch of notices on every edit screen which seem to relate to the fact that a 'null' post is picked up initially

Notice: Trying to get property of non-object in C:\web\wpbeta\wp\wp-includes\capabilities.php on line 992

$post = get_post( $args[0] );
if ( 'revision' == $post->post_type ) {

Notice: Trying to get property of non-object in C:\web\wpbeta\wp\wp-includes\capabilities.php on line 996

Notice: Trying to get property of non-object in C:\web\wpbeta\wp\wp-includes\capabilities.php on line 998

Notice: Trying to get property of non-object in C:\web\wpbeta\wp\wp-includes\capabilities.php on line 999

Notice: Trying to get property of non-object in C:\web\wpbeta\wp\wp-includes\capabilities.php on line 999

Notice: Trying to get property of non-object in C:\web\wpbeta\wp\wp-includes\capabilities.php on line 1002

Notice: Trying to get property of non-object in C:\web\wpbeta\wp\wp-includes\capabilities.php on line 1002

Adding to the list of potential items for the Revisions Feature push in 3.6.

Moving to the Revisions Component for 3.6

Next steps:

• Concrete reproductive steps on the ticket for the bug.

Replying to westi:

Moving to the Revisions Component for 3.6

Next steps:

• Concrete reproductive steps on the ticket for the bug.

i am also unclear how to reproduce the bug.

I doubt there is a bug here at all.

Revisions simply use its parent post for cap checking. This is baked into map_meta_cap directly.