WordPress.org

Make WordPress Core

Opened 6 years ago

Last modified 19 months ago

#22511 new defect (bug)

Taxonomy manage screen checks for manage_terms and edit_terms, instead of just manage_terms.

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

Description

I'm trying to set up permissions so the Contributor role can add terms but not edit or delete terms. I setup my taxonomy so it looks like this:

register_taxonomy( 'custom_taxonomy', array( 'post' ), array(
	...
	'capabilities' => array (
		'manage_terms' => 'edit_posts',
		'edit_terms' => 'manage_options',
		'delete_terms' => 'manage_options',
		'assign_terms' => 'edit_posts'
	)
) );

However, when logged in as a contributor I get the error "You are not allowed to edit this item." In edit-tags.php there are two checks for caps, one is for manage_terms and one is for edit_terms. I don't believe the second one should be there, because looking at the other code it should be like this:

  • User with manage_terms can access the main taxonomy page
  • They can also add terms
  • There are checks in WP_Terms_List_Table to restrict showing the Edit/Quick Edit/Delete links for users without those capabilities (edit_terms/delete_terms).
  • There is even plenty of other checks on edit_terms in edit-tags.php to include/change the content shown to the user.. if the entire page is restricted for users without edit_terms, why are any of those necessary?

Even if I'm wrong on the fact that roles with edit_terms can't add new terms (it's not completely clear anywhere, it seems like manage_terms should be enough), I still think that this page should be viewable at the very least considering the other code in that page and the list table.

Recommended solution: move the edit_terms check back into case 'edit' (line 121 of edit-tags.php in trunk, currently) as it was before [15491].

This was introduced in: [15441] and [15491]. Related: #14343.

Change History (9)

#1 follow-up: @nacin
6 years ago

There isn't much of a purpose for edit-tags.php if it is 100% read-only. I'm actually not sure why edit_terms and manage_terms are separate capabilities.

#2 @andrewryno
6 years ago

That's why I was confused on why there were checks for edit_tags elsewhere on the page if there was no way to access the page without that capability anyway. So is there a way for users to add terms but not edit them?

#3 @nacin
6 years ago

  • Version changed from trunk to 3.0

#4 @wonderboymusic
5 years ago

  • Keywords needs-patch added

#5 @wonderboymusic
4 years ago

  • Keywords dev-feedback removed
  • Milestone changed from Awaiting Review to Future Release

This needs investigation, and a patch

#6 @danielbachhuber
4 years ago

There isn't much of a purpose for edit-tags.php if it is 100% read-only.

It would be nice to have a view capability, actually. When you're using custom taxonomies in a substantial way, adding extra data to the table, and just want to give certain users view access, you basically have to replicate edit-tags.php

#9 in reply to: ↑ 1 @SergeyBiryukov
19 months ago

Replying to nacin:

I'm actually not sure why edit_terms and manage_terms are separate capabilities.

Copying a note to self from #38958 here :)

It would be great to document the difference (if there is any) between edit_terms and manage_terms at some point, they appear to be used somewhat interchangeably in core. Stumbled upon this in comment:6:ticket:38857.

Note: See TracTickets for help on using tickets.