As requested: using Drupal 6.16 with taxonomy_access 6.x-1.2 with MySQL and no other access control modules

Scenario is:

  • User 'bob' is assigned two roles, 'A' and 'B'.
  • One role 'A' allows: View and List access to the default of the vocabulary and,
  • the other role 'B' allows: View, List and Create access for one of the terms of the Vocab.
  • User has the create content type permissions assigned to their role.
  • The vocab is assigned to this same content type.

When the user is logged in:

  • they can view the taxonomy/term pages for all terms - that's good!
  • they can attempt to create the item of the content type, but see all terms in the vocab select box - that's bad!

When I remove the "List" access from role 'A' on the default item of the vocabulary:

  • they then can't view the taxonomy/term page for any terms but the term specified in role 'B' - that's bad!.
  • however, when they attempt to create the item of the content type, they now only see the term they are suppose to see - that's good!

The documentation states that "Create" is the permission that allows the term to show up in the form, so why is the "List" permission doing this?

Am I doing something wrong?

Thanks!

CommentFileSizeAuthor
#2 taxonomy_access-785060.patch1005 bytesalexkb

Comments

alexkb’s picture

alexkb commented
Title: List and Create permissions causing havok » List and Create permissions dont appear to be working as documented
alexkb’s picture

alexkb commented
Assigned: Unassigned » alexkb
Status: Active » Needs review
StatusFileSize
new taxonomy_access-785060.patch1005 bytes

Ok, found out what the problem is now, I was accessing the node create form on the URL: 'admin/node/add/article' instead of 'node/add/article' and so when the taxonomy_access_db_rewrite_sql function was called, it detected the $op var as list instead of create!!

Attached is a patch to fix this problem.

alexkb’s picture

alexkb commented

Been over a week now, could someone else please test this - its not a huge patch? Happy to commit it myself if people want?

xjm’s picture

xjm
she/her
Primary language English
commented
Status: Needs review » Reviewed & tested by the community

Looks good. I want to test a couple of other scenarios before I commit it, though.

keve’s picture

keve commented

Maybe we should also consider to move this into hook_form_alter.

As If’s picture

As If commented

Same problem here, Drupal 6.16 and TAC 6.x-1.2. But in my case, even when I remove "List" permissions from role A, Bob can *always* see *every* term in the vocab dropdown when creating or editing a page. That's super-bad!

Applied the patch, it had no apparent effect whatsoever.

As If’s picture

As If commented

Ok, I discovered the cause of my problem. It isn't mentioned anywhere in the documentation, but it turns out that if you grant "administer taxonomy" permissions to a role, then ALL TERMS will always be visible to that role when creating or editing nodes, regardless of what you tell TAC. In other words, if you want to allow a role to actually edit the taxonomy term/description for a term they have TAC access to... you're out of luck.

UPDATE: There is one easy hack to get around this problem. Around line 458 in taxonomy_access.module:
if (!user_access('administer taxonomy') && ($field =='vid' || $field =='tid')) {

What you can do is replace 'administer taxonomy' with some OTHER permission that all content-editing roles have on your site. For instance, 'administer blocks'.

xjm’s picture

xjm
she/her
Primary language English
commented

#7: I thought that was in the docs... fixed now: http://drupal.org/node/748590. That's a separate issue, so if you'd like to submit a feature request, I'd open a new issue or check if another exists.

As If’s picture

As If commented

I'm not trying to diss the code ;-) I think the module rocks, and it's not an easy problem to wrap your head around. Kudos to the TAC team.

I just posted to follow-up, and to help anyone who happened to be in a similar situation in the future. Speaking as a site developer, it's not a huge deal since I can easily hack around it. But speaking as a module developer, yeah, that might be a nice feature. Maybe instead of hardcoding 'administer taxonomy' into the module, you could do a system-wide variable with 'administer taxonomy' being the default if the variable isn't set.

xjm’s picture

xjm
she/her
Primary language English
commented
Title: List and Create permissions dont appear to be working as documented » Bug with List and Create permissions at admin/ paths
Version: 6.x-1.2 » 6.x-1.x-dev
Status: Reviewed & tested by the community » Fixed

Whoops, I meant to come back to this because of keve's suggestion in #5 and then forgot about it. Patch is committed:
http://drupal.org/cvs?commit=396740

I'm a bit nervous about matching path arguments for such important parts of the functionality (see also #660668: TAC + revisioning: Empty taxonomy term select list on node/add for regular users), but I'm a little unclear on how we would use hook_form_alter() instead. It makes sense for the 'create' option to get set only when we're on a node edit page (which would be where hook_form_alter comes in), but how should we make that information available to hook_db_rewrite_sql()?

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

xjm’s picture

xjm
she/her
Primary language English
commented

The patch available in #881210: No list or create permissions on any terms may result in incorrect use of default on save should resolve any remaining problems like this. If you still encounter this bug or anything like it, please test the patch from that issue with the latest dev build of TAC. Direct link to patch:
http://drupal.org/files/issues/tac_881210-9.patch