An authenticated user with the permission 'Administer vocabularies and terms' only, is able to do whatever he/she wants.
Permissions like 'Edit terms in Tags' or 'Delete terms from Tags' are not taken into account: either they are set or not, the user is able to edit or delete terms, even(!) delete the whole vocabulary.
Please fix.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Berdir’s picture

I think this is by design.

Administer *something* permissions in Drupal usually allow to do everything. If you want to only give specific permissions, only grant those.

This might be a feature request instead, what exactly do you want your users allow to do?

catch’s picture

Version: 7.0 » 7.x-dev
Category: bug » support
Priority: Major » Normal

This is by design, the permission acts the same as the 'administer content types' permission (to the extent that it's possible given that node and taxonomy are a bit different).

Csabbencs’s picture

Ok, I understand your point that it could be a design question.
But if you revoke 'Administer vocabularies and terms' then the user can't view the terms even if you give him/her the permissions 'Edit terms in Tags' or 'Delete terms from Tags'.
So, to summarize:
- 'Administer vocabularies and terms' -> user can do everything if set, nothing if not set
- 'Edit terms in Tags' or 'Delete terms from Tags' -> does not matter if they are set or not, they don't affect anything (=these lines could be deleted from permissions).
So something is not quite ok here...

catch’s picture

Threre is an edit tab on all taxonomy/term/n pages, controlled by those permissions, the delete button is on that page (again consistent with nodes/users).

Csabbencs’s picture

I debugged the code: the reason I couldn't edit without setting 'Administer vocabularies and terms' was that I came from the admin pages to check taxonomy terms and got access denied.
The only path for which 'Edit terms in Tags' works is taxonomy/term/n pages, like you wrote.
My opinion is that when 'Administer vocabularies and terms' is not set, but 'Edit terms in Tags' is set, path such as admin/structure/taxonomy/vocabulary should be usable, too.

Csabbencs’s picture

Version: 7.x-dev » 8.x-dev
Category: support » feature
catch’s picture

Title: Taxonomy permissions are not alive » Allow specific vocabulary permissions to work on vocabulary admin pages
Category: feature » task

Let's have this as a task, granular access to specific features of pages in /admin isn't something we have much of in core, but I'd like to see more of it. Also someone else posted an issue in another thread where they'd been confused by how these permissions work, so there's clearly a usability or at least expectations issue here.

joelstein’s picture

When I saw those permissions, I thought that the role would be able to see the "list terms" page, re-arrange terms, and add terms.

That is not the case. All the role can do is click the "edit" tab when viewing the term, and delete it on that page.

Here's a discussion of others who were confused by this: http://drupal.org/node/992856.

Usability issue, confirmed. ;)

joelstein’s picture

Doing what I described in #8 is as simple as the following change to taxonomy.module (in D7):

--- taxonomy.module
+++ (clipboard)
@@ -325,7 +325,8 @@
     'title arguments' => array(3),
     'page callback' => 'drupal_get_form',
     'page arguments' => array('taxonomy_overview_terms', 3),
-    'access arguments' => array('administer taxonomy'),
+    'access callback' => 'taxonomy_term_edit_access',
+    'access arguments' => array(3),
     'file' => 'taxonomy.admin.inc',
   );
   $items['admin/structure/taxonomy/%taxonomy_vocabulary_machine_name/list'] = array(
@@ -347,7 +348,8 @@
     'title' => 'Add term',
     'page callback' => 'drupal_get_form',
     'page arguments' => array('taxonomy_form_term', array(), 3),
-    'access arguments' => array('administer taxonomy'),
+    'access callback' => 'taxonomy_term_edit_access',
+    'access arguments' => array(3),
     'type' => MENU_LOCAL_ACTION,
     'file' => 'taxonomy.admin.inc',
   );

Since taxonomy_term_edit_access expects to receive an object with a vid property ($term), passing it the vocabulary (as above) works just fine. Of course, we'd probably want to rename taxonomy_term_edit_access to something more inclusive of both vocabularies and taxonomy terms... perhaps taxonomy_edit_access?

For those who need an intermediate solution, place the following in hook_menu_alter inside a custom module:

/**
 * Implements hook_menu_alter().
 */
function mymodule_menu_alter(&$items) {
  // Grant those with "edit terms in [vid]" permission access to list the terms
  // and add new ones, per vocabulary.
  $items['admin/structure/taxonomy/%taxonomy_vocabulary_machine_name']['access callback'] = 'taxonomy_term_edit_access';
  $items['admin/structure/taxonomy/%taxonomy_vocabulary_machine_name']['access arguments'] = array(3);
  $items['admin/structure/taxonomy/%taxonomy_vocabulary_machine_name/add']['access callback'] = 'taxonomy_term_edit_access';
  $items['admin/structure/taxonomy/%taxonomy_vocabulary_machine_name/add']['access arguments'] = array(3);
}
rickvug’s picture

Sub. The proposal in #9 looks very logical and straightforward. I can't think of a problem with the permission. Does anyone have an objection? It would be great to get this into Drupal 8 and then consider back-porting to D7.

screenage’s picture

subscribing

JohnnyX’s picture

View/ edit/ delete own terms would be great. User based terms could also be used with access by term as access control for users own content.

ihearttacobell’s picture

I'd like to see this happen. Subscribing.

David4514’s picture

I would like to vote for this too since I just now fell into the same trap. The all or nothing approach currently used does not meet our requirements. I would like to give someone the ability to manage a vocabulary (i.e. add/delete/update terms in a vocabulary) without the ability to administer all vocabularies. I would also like them to not be able to delete the vocabulary they are allowed to manage. They should only be able to manage the terms within the vocabulary.

This would be a great plus.

afmdsouza’s picture

hook_menu_alter() solution at #9 fixes this issue as per #8, +1 for including it in D7 & D8. Thanks joelstein!

bneel’s picture

Idem
hook_menu_alter() solution at #9 fixes this issue as per #8,
+1 for including it in D7 & D8.
Thanks !

thinkact’s picture

Found this taxonomy_access_fix module implemented the workaround similar to #9 above. It works on Drupal 7.12

kristofferwiklund’s picture

Greate module in #17. Does what I needed, without having to do a patch myself.

Manuel Garcia’s picture

Status: Active » Needs review
FileSize
2.2 KB

An absolute must have for sites with content editor teams.

Find attached a patch implementing what is discussed in #9

I've also added a permission to add terms to a specific vocabulary, so now it should be granular enough.

What works:
Going to admin/structure/taxonomy/tags, editing, adding deleting and reordering terms.

What doesn't work (and should imho):
Going to admin/structure/taxonomy returns access denied
Going to admin/structure displays You do not have any administrative items.

Ideally going to admin/structure/taxonomy should list the vocabularies to which you have access.

dddbbb’s picture

I'm also pretty confused by the default permissions handling/UX. I'd love to see this straightened out in core too.

Thanks for the link to http://drupal.org/project/taxonomy_access_fix - that'll do nicely as a short term solution.

Further reading for anyone interested in seeing this fixed in Drupal 8: http://drupal.org/node/1848686

anou’s picture

Status: Needs review » Needs work

Patch #19 no longer apply to D7.22

klonos’s picture

The patch in #19 is meant for D8 (applies to /core/modules/taxonomy/taxonomy.module). AFAICT there never was a patch for D7 in this issue.

anou’s picture

Autant pour moi. I misunderstood. Thanks for the precision. And not to mention that I finally used the taxonomy_access_fix module after trying do modify, without success, the patch to apply on D7 :-)

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

realityloop’s picture

realityloop’s picture

Version: 8.2.x-dev » 8.3.x-dev

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Berdir’s picture

Status: Needs work » Closed (duplicate)

I posted a detailed overview of all related issues that we have around this topic in #1848686-179: Add a dedicated permission to access the term overview page (without 'administer taxonomy' permission) (#179 if the link does not work).

As suggested there, I'm closing this issue as a duplicate of that issue as this only has a very old patch that is no longer relevant.