Make WordPress Core

Opened 14 years ago

Closed 14 years ago

#12035 closed task (blessed) (fixed)

Allow taxonomy privledges to be handled independently of categories

Reported by: dd32's profile dd32 Owned by: dd32's profile dd32
Milestone: 3.0 Priority: normal
Severity: normal Version: 3.0
Component: Taxonomy Keywords:
Focuses: Cc:


At present, all taxonomy-related actions are based off the manage_categories capability.

This means that plugins are not able to restrict who can modify/delete their taxonomies terms.

In the same light, This also restricts site managers from only allowing certain users(roles) to handle specific functions.

I'm commiting a first-scrape at it, Things that need to be looked into:

  • MultiSite integration
  • Tag-style taxonomy additions (ie. Allowed to manage(add to post object) but not add)
  • viewing of the post page should allow the user to see the current terms, but not change them (Current code will hide them entirely)
  • Ensure that when a user modifies an existing post, terms are not lost.

The caps are currently changed by passing one of the following args to register_taxonomy, empty() or not-set will result in manage_categories being used.

  • manage_cap - Assigning the Term to a Post object
  • edit_cap - Addition & Modification of a Term
  • delete_cap - Deletion of a Term

Note, That this doesnt affect plugins, plugins still have free roam over the taxonomy API regardless of the user logged in.

Related: #11838

Change History (23)

#1 @dd32
14 years ago

  • Type changed from defect (bug) to enhancement

#2 @dd32
14 years ago

  • Component changed from Role/Capability to Taxonomy
  • Owner set to filosofo

#3 @dd32
14 years ago

  • Owner changed from filosofo to dd32
  • Status changed from new to accepted

#4 @dd32
14 years ago

(In [12833]) First scratch at Taxonomy Capabilities. See #12035

#5 @dd32
14 years ago

(In [12834]) Remove accidental capability testing code. See #12035

#6 @scribu
14 years ago

+1 on the initiative. manage_categories was very limiting.

I have a use-case in mind:

How would I go about creating a custom taxonomy such that:

  • editors can create, edit & delete terms
  • authors can only use existing terms

It would be really helpful if you could provide the sample code for something like that. Thanks.

#7 @pampfelimetten
14 years ago

Have been testing it with registering a hierarchical taxonomy, including applying different capabilities to different classes. Works very fine up to now, respect!

@scribu: My test code looks like this:

	register_taxonomy( 'language', 'post', array(	'hierarchical' => true,
							'update_count_callback' => 'xxx_update_language_term_count',
							'label' => __('Language'),
							'query_var' => true,
							'rewrite' => array( 'slug' => 'language' ),
	                                                'manage_cap' => 'xxx_manage_language_tag',
	                                                'edit_cap' => 'xxx_edit_language_tag',
	                                                'delete_cap' => 'xxx_delete_language_tag'
						) );	

function xxx_update_language_term_count($terms) {
	_update_post_term_count( $terms ); // standard function

Next thing is to create the capabilities, for which I use a plugin, but I suppose there is another way to add them via script.

#8 @scribu
14 years ago

Thanks, pampfelimetten.

I was thinking of maybe automatically creating the capabilities, when registering the taxonomies.

You'd still have to map them to roles, but it would save an extra step.

#9 @dd32
14 years ago

You'd have the option of either using a pre-defined capability, or adding your own and adding it to the roles you want.

What i'd do is probably:

  • editors can create, edit & delete terms

edit_cap + delete_cap => edit_others_posts

  • authors can only use existing terms

manage_cap => publish_posts

Thats going off

#10 @dd32
14 years ago

(In [12967]) Allow viewing of Attached hierarchical Terms when the user doesnt have Manage capability of the taxonomy, Only set terms if user has Management capability. See #12035

#11 @automattor
14 years ago

(In [13212]) More Taxonomy cap checks. See #12035

#12 @dd32
14 years ago

That's most of the 'manage_categories' which is used by custom taxonomies updated.

manage_categories is still hard coded in the XMLRPC category functions, as well as the link categories page. See #12285 for 3.1 for links.

#13 @markjaquith
14 years ago

I think most of [12967] needs to be reverted. Authors have lost the ability to categorize and tag their posts! 'manage_categories' is about editing, deleting and creating categories, not assigning them. We may need separate capabilities for "assign_x" and "manage_x"

#14 @dd32
14 years ago

I havnt tested the Authors, I've stupidly assumed that a cap was actually checked before having terms assigned. As you've pointed out, It seems that no capability checks were ever attempted before assigning terms to posts.

Looks like an assign_categories cap needs to be created which covers > subscriber roles..

#15 @dd32
14 years ago

(In [13289]) Introduce assign_cap for Taxonomies, Defaults to 'edit_posts'. Allows for Authors/Contributors to tag/categorise their posts. See #12035

#16 @dd32
14 years ago

That highlighted a remaining @todo.

The Categories-style metaboxes disable the term list, yet allow you to view it if you cannot modify the taxonomy.

The Tag-style metaboxes are simply non-operationable if you cant use them.. That needs to be corrected to alllow viewing, but not modifications.

#17 @markjaquith
14 years ago

What's the argument for showing the UI in a disabled state as opposed to not showing it at all? My initial thought is that the information is of very low utility, as they can only act on it by contacting someone with higher privileges. I think a lot of people will be more confused by "when I click the checkboxes, nothing happens" than by absence.

#18 @dd32
14 years ago

What's the argument for showing the UI in a disabled state as opposed to not showing it at all

My reasoning is, The Taxonomy data is public information attached to the post, You can physically see the metadata is there, You cannot modify it however.

One example that someone brought up with me in private was having an Editor that could accept/reject postings, They wanted to be able to see the category data before accepting, but not modify it. While thats a specific use case (and one that would require greater plugin modifications of core anyway) I didnt see a problem with that.

If theres a Agreement between someone who can comment on the UI angle that hiding the box alltogether would be better, I dont mind that, I was just trying to make it as transparent to the public post data as possible, whilst still keeping the capabilities in tow.

"when I click the checkboxes, nothing happens" than by absence.

Then the disabled class styling has failed us. Disabled elements are something that people should deal with often, it even happens in WordPress that some fields are readonly... occasionally.. my point is, that the styling for such elements should make it visible that its disabled and cannot be modified.

#19 @nacin
14 years ago

  • Type changed from enhancement to task (blessed)

#20 @dd32
14 years ago

(In [13855]) Display the list of Terms in a non-hierarchical taxonomy on the Post Edit page even if they cannot modify them. See #12035

#21 @ryan
14 years ago


#22 @nacin
14 years ago

(In [14894]) Stirng capitalization fix. see #12035.

#23 @nacin
14 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

After review, this looks good for 3.0.

Note: See TracTickets for help on using tickets.