Opened 15 years ago
Closed 14 years ago
#12035 closed task (blessed) (fixed)
Allow taxonomy privledges to be handled independently of categories
Reported by: | dd32 | Owned by: | dd32 |
---|---|---|---|
Milestone: | 3.0 | Priority: | normal |
Severity: | normal | Version: | 3.0 |
Component: | Taxonomy | Keywords: | |
Focuses: | Cc: |
Description
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 objectedit_cap
- Addition & Modification of a Termdelete_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)
#6
@
15 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
@
15 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
@
15 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
@
15 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 http://codex.wordpress.org/Roles_and_Capabilities#Roles
#12
@
15 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
@
15 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
@
15 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..
#16
@
15 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
@
15 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
@
15 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.
(In [12833]) First scratch at Taxonomy Capabilities. See #12035