WordPress.org

Make WordPress Core

Opened 6 years ago

Last modified 2 years ago

#26409 new defect (bug)

Non-Editors can create (non-hierarchical) terms even though they can't manage_terms

Reported by: westonruter Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.0
Component: Taxonomy Keywords: needs-patch
Focuses: Cc:

Description

When a taxonomy is registered, the $default_caps are:

	'manage_terms' => 'manage_categories',
	'edit_terms'   => 'manage_categories',
	'delete_terms' => 'manage_categories',
	'assign_terms' => 'edit_posts',

This should mean that Authors and Contributors should not be able to create new terms because they (normally) do not have the manage_categories capability. For hierarchical taxonomies (like categories), the UI for creating new terms is removed from the metabox. However, for non-hierarchical taxonomies (like tags), the UI does not change based on whether the they can manage_categories or not: they can still enter arbitrary terms and add them, and when saving the post, the new terms get created. This seems wrong.

There should be current_user_can( $taxonomy->caps->manage_terms ) checks done when saving a post, and the UI should be updated to prevent new terms from seeming to be accepted. The ajax-tag-search could be used to determine if the entered tag exists, and only allow it to be added if it does.

Attachments (2)

manage-terms-cap-checks.patch (4.7 KB) - added by westonruter 6 years ago.
First stab at adding manage_terms cap checks whenever a new term is to be created when saving a post
26409.diff (2.9 KB) - added by obenland 6 years ago.

Download all attachments as: .zip

Change History (14)

#1 @westonruter
6 years ago

  • Keywords has-patch added

#2 @kucrut
6 years ago

  • Cc kucrut.dz@… added

@westonruter
6 years ago

First stab at adding manage_terms cap checks whenever a new term is to be created when saving a post

#3 follow-up: @obenland
6 years ago

  • Milestone changed from Awaiting Review to 3.9

We could also just not show the meta box in the first place and not give them the opportunity to mess with it.

@obenland
6 years ago

#4 @obenland
6 years ago

  • Version set to 3.0

Just found r13855, stating the purpose of the current implementation to show terms but not allow to edit them.
I assume that more often than not users will see that box empty though, especially with custom taxonomies.

#5 in reply to: ↑ 3 @westonruter
6 years ago

Replying to obenland:

We could also just not show the meta box in the first place and not give them the opportunity to mess with it.

If we just hide the metabox, and don't add some cap checks into the underlying API calls, then there could be other ways that a user could illegally add terms (e.g. via quick edit)

Last edited 6 years ago by westonruter (previous) (diff)

#6 @nacin
6 years ago

I am pretty sure that this is intentional. Or rather, capability handling for custom taxonomies is super weird and possibly never worked right. The ability for non-editors to create tags has always been proper behavior.

assign_terms currently holds the keys for creating tags. As to how it ended up this way: Hierarchical taxonomies are based on ID, non-hierarchical on slug. You need to be an editor to add a new category to get said ID. But any author can just type out a new tag. At some point, we'll need to improve our caps handling to make this more robust and to properly handle the different scenarios. there is likely already a ticket or two.

#7 @wonderboymusic
6 years ago

  • Milestone changed from 3.9 to Future Release

This has no steam.

#8 @danielbachhuber
5 years ago

This is still a bug.

#9 @danielbachhuber
5 years ago

This provides an immediate fix, but doesn't solve the UX problem (users still think they're adding a term until they've saved).

add_filter( 'pre_insert_term', function( $term ){
	// Accommodate any async processes
	if ( is_user_logged_in() && ! current_user_can( 'manage_categories' ) ) {
		return new WP_Error( 'insert-term', "Sorry, you can't create new terms" );
	} else {
		return $term;
	}
});

#10 @wonderboymusic
5 years ago

  • Keywords needs-patch added; has-patch removed

#11 @johnbillion
2 years ago

#38053 was marked as a duplicate.

#12 @bobbingwide
2 years ago

The UI areas to be addressed by this bug include quick edit as well as the Edit post metabox.

This defect is referenced by https://github.com/WordPress/gutenberg/issues/2545

Note: See TracTickets for help on using tickets.