WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 2 years ago

#16847 closed defect (bug)

Capability check fails for custom post type revision edit (& map_meta_cap no good) — at Version 10

Reported by: anmari Owned by:
Milestone: Priority: normal
Severity: minor Version: 3.0
Component: Revisions Keywords: reporter-feedback has-patch dev-feedback
Focuses: Cc:

Description (last modified by SergeyBiryukov)

I am using nightly build (1 day old).

Steps to reproduce:

  1. Register post type with capability 'event'.
  1. Edit custom post type till you have some revisions.
  1. 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

Change History (10)

comment:1 @scribu4 years ago

  • Component changed from Revisions to Role/Capability
  • Keywords reporter-feedback added; needs-patch removed

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.

comment:2 @anmari4 years ago

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

comment:3 @scribu4 years ago

  • Cc nacin added

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

comment:4 @anmari4 years ago

  • Summary changed from Capability check fails for custom post type revision edit to Capability check fails for custom post type revision edit (& map_meta_cap no good)
  • Version changed from 3.1 to 3.3

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

comment:5 @anmari4 years ago

  • Version changed from 3.3 to 3.2.1

comment:6 @westi3 years ago

  • Keywords revisions-3.6 added

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

comment:7 follow-up: @westi3 years ago

  • Component changed from Role/Capability to Revisions
  • Keywords revisions-3.6 removed
  • Milestone changed from Awaiting Review to 3.6

Moving to the Revisions Component for 3.6

Next steps:

  • Concrete reproductive steps on the ticket for the bug.

comment:8 in reply to: ↑ 7 @adamsilverstein3 years ago

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.

comment:9 @nacin3 years ago

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.

comment:10 @SergeyBiryukov3 years ago

  • Description modified (diff)
  • Version changed from 3.2.1 to 3.0
Note: See TracTickets for help on using tickets.