Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Category, tag, and taxonomy controls don't respect the correct capabilities #5879

Closed
johnbillion opened this Issue Mar 29, 2018 · 6 comments

Comments

@johnbillion
Copy link
Member

johnbillion commented Mar 29, 2018

Issue Overview

If a user has the assign_terms capability for a given taxonomy, but not the manage_terms capability for the taxonomy, they are unable to assign terms.

Steps to Reproduce (for bugs)

  1. Create a custom taxonomy that uses the following capabilities array, or filter the capabilities for Categories or Tags to do the same:

    'capabilities' => array(
    	'assign_terms' => 'edit_posts',
    	'delete_terms' => 'do_not_allow',
    	'edit_terms'   => 'do_not_allow',
    	'manage_terms' => 'do_not_allow',
    ),
    
  2. Create a new post and note that the taxonomy is not shown in the editor, despite the user having the edit_posts capability and therefore being allowed to assign terms.

Expected Behavior

The user should be able to assign terms in the taxonomy.

Current Behavior

The user cannot assign terms in the taxonomy, not see the currently assigned terms.

Possible Solution

Respect the user's capabilities for assign_terms.

Note that there is quite a lot of logic in the Categories and Tags meta boxes on WordPress' current editing screen, all of which needs to be replicated in Gutenberg in order to respect the underlying capabilities API.

See:

  • post_tags_meta_box()
  • post_categories_meta_box()

Related Issues and/or PRs

@danielbachhuber

This comment has been minimized.

Copy link
Member

danielbachhuber commented Apr 13, 2018

I'm going to approach this issue in this order:

  1. Produce a table documenting (from the UI) what term management actions each role (contributor, author, editor) can perform (e.g. create a tag, assign a tag to a post, edit the tag description). This will serve as our reference point for 2 and 3.
  2. Ensure REST API capability checks follow aforementioned table. I'm pretty sure they don't.
  3. Ensure Gutenberg's displayed UI follows aforementioned table.
@danielbachhuber

This comment has been minimized.

Copy link
Member

danielbachhuber commented Apr 23, 2018

I did some research on this today. Here's my table of UI-focused permission review.

The key difference between categories and tags: contributors and authors can create tags, but they can't create categories. This distinction applies more broadly to non-hierarchical vs. hierarchical taxonomies.

Fortunately, the only low-level permissions check is in wp_insert_post(). More specifically:

foreach ( $postarr['tax_input'] as $taxonomy => $tags ) {
	$taxonomy_obj = get_taxonomy( $taxonomy );
	// array = hierarchical, string = non-hierarchical.
	if ( is_array( $tags ) ) {
		$tags = array_filter( $tags );
	}
	if ( current_user_can( $taxonomy_obj->cap->assign_terms ) ) {
		wp_set_post_terms( $post_ID, $tags, $taxonomy );
	}
}

After this logic, wp_set_post_terms() calls wp_set_object_terms() and neither has permissions checks. Because of how wp_set_object_terms() behaves, strings passed for a non-hierarchical taxonomy will be magically transformed into terms. wp_set_object_terms() always expects an array of integers (representing valid terms) for hierarchical taxonomies.

I say "fortunately" because core's existing implementation also means we don't have to enter the rabbit hole of developer-defined custom taxonomy UI. edit_post() blindly accepts and processes data included in tax_input, regardless of whether a developer implemented some bespoke UI for the taxonomy.

Given this information, we can assume:

  1. A user can set terms on a post if they have assign_terms for the taxonomy and can edit the post. This also means they can access all terms (including empty, non-public ones).
  2. A user can create new terms if they have assign_terms for a non-hierarchical taxonomy, or edit_terms for a hierarchical taxonomy.

However, now we run into #6361 because capabilities are evaluated at runtime.

@danielbachhuber

This comment has been minimized.

Copy link
Member

danielbachhuber commented May 15, 2018

I've created a core ticket for resolving the capability discrepancies. Now we need to apply similarly in Gutenberg, and address the fact the UI needs to reflect what the user can do.

@pento pento closed this in #6761 May 17, 2018

pento added a commit that referenced this issue May 17, 2018

@marybaum

This comment has been minimized.

Copy link

marybaum commented May 24, 2018

FWIW, I'm not seeing the categories and tags panel on marybaum.com, my photo portfolio, logged in as admin, on Bluehost shared hosting.
screenshot 2018-05-24 10 50 08
This is from a post of image blocks. Based on histrionics, I give the thing five stars for just working pretty much as advertised! 😜

@danielbachhuber

This comment has been minimized.

Copy link
Member

danielbachhuber commented May 24, 2018

@marybaum Can you open a new issue please?

@marybaum

This comment has been minimized.

Copy link

marybaum commented May 24, 2018

Sure!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.