We have a vocabulary "privacy", which is linked to several content types.

One node has privacy "vip users only", which means that only users who have role "vip user" can access and edit the node.

Our problem is, that when a vip user goes to the node, edits it and saves the node, it becomes viewable also by anonymous users!

If webmaster views the page after vip user has edited the page, everything seems to be fine (including the privacy setting). However, after webmaster has saved the page (even without doing any editing), privacy works again as intended.

What is causing this strange behaviour?

Vip users cannot (and must not be able to) view nor edit the taxonomy set for the page.

Comments

gpk’s picture

Which module are you using to control node access?

From what you say, the node's taxonomy term from the privacy vocabulary is not being altered when the vip user edits the node. But the node access permission are being altered?

How are you checking that after vip user has edited the page, the node still has the "vip users only" taxonomy term?

How are you preventing the vip user from modifying or seeing that term?

You might also want to check the {term_node} and {node_access} tables for the relevant node/node revision, to see what might be going on.

putkonen’s picture

Thanks for your reply!

> Which module are you using to control node access?

Taxonomy Access Permissions.

> From what you say, the node's taxonomy term from the privacy
> vocabulary is not being altered when the vip user edits the node.
> But the node access permission are being altered?

Exactly.

> How are you checking that after vip user has edited the page,
> the node still has the "vip users only" taxonomy term?

If I go to the page as webmaster, this term is shown.

> How are you preventing the vip user from modifying or seeing that term?

They are not allowed to "administer taxonomy" in Drupal access control (terminology might be a bit different in English as my admin UI uses a different language).

putkonen’s picture

I tested, that if I give taxonomy administration rights to VIP users (so that they can see and modify the privacy taxonomy), then this issue does not occur.

However, this is something I would not want to do.

gpk’s picture

Strange, "administer taxonomy" is not normally required in order to view or modify taxonomy terms applied to a node. "Administer taxonomy" lets you create vocabularies and define the terms within them. Maybe you have some custom code running on the site, and that is interfering with things?

Also did you manage to check the database tables like I suggested?

putkonen’s picture

There is a trigger which sends email whenever this node is modified. However disabling the trigger didn't change the issue. I'm not aware of anything else which could interfere.

The only remedy I've found so far is to allow "administer taxonomy" for the user editing the node.

There is no change in table term_node:

mysql> select * from term_node where nid=3056;
+------+------+-----+
| nid | vid | tid |
+------+------+-----+
| 3056 | 3073 | 44 |
+------+------+-----+
1 row in set (0.00 sec)

node_access table, on the other hand, gets modified after the save.

Correct data, before save:

mysql> select * from node_access where nid=3056;
+------+-----+-------------+------------+--------------+--------------+
| nid | gid | realm | grant_view | grant_update | grant_delete |
+------+-----+-------------+------------+--------------+--------------+
| 3056 | 4 | term_access | 1 | 1 | 0 |
| 3056 | 5 | term_access | 1 | 1 | 1 |
| 3056 | 6 | term_access | 1 | 1 | 0 |
+------+-----+-------------+------------+--------------+--------------+
3 rows in set (0.00 sec)

Altered data, after save:

mysql> select * from node_access where nid=3056;
+------+-----+-------------+------------+--------------+--------------+
| nid | gid | realm | grant_view | grant_update | grant_delete |
+------+-----+-------------+------------+--------------+--------------+
| 3056 | 1 | term_access | 1 | 0 | 0 |
| 3056 | 2 | term_access | 1 | 0 | 0 |
| 3056 | 4 | term_access | 1 | 1 | 1 |
+------+-----+-------------+------------+--------------+--------------+
3 rows in set (0.00 sec)

gpk’s picture

> Which module are you using to control node access?
Taxonomy Access Permissions.

I presume you mean Taxonomy Access Control? http://drupal.org/project/taxonomy_access

IIRC the gid is actually a role id, and roles 1 and 2 would be anon user and auth user respectively.

The fact that the term is not being shown on the node view or edit screen for your VIP users is suspicious to me. This could mean that the taxonomy stuff is not properly present in the node object when node grants are being determined, leading to the behavior you are experiencing. Something (contrib module, custom module or theme) must be interfering with the default behavior here. Probably whatever it is is removing the taxonomy stuff from the node edit form (the wrong approach) instead of the right approach which is to set the '#access' property of the relevant form element to FALSE (this preserves the data even while hiding it from the user).

Incidentally you say "There is no change in table term_node:" but I would expect at least the node revision (vid) to change? If not then the latest revision of the node (per the {node} table) doesn't have a corresponding entry in {term_node}. This would likely be another symptom of the problem I'm trying to identify in the para above and would be consistent with the output you have shown for the queries you have run against the {node_access} table.

putkonen’s picture

Yes, TAC is the correct name.

I rebuilt node permissions, but it didn't help.

We have also several other roles having more permissions than the VIP user. They can see the taxonomy terms, and when they save the page the access rights are not changed. It's difficult to find out what permission settings for the VIP user cause that the taxonomy terms are not shown, as the permissions page is huge.

vid is unchanged. Only if I select "create new revision", then a new row with the same nid, different vid is created.

You say "instead of the right approach which is to set the '#access' property of the relevant form element to FALSE". How is this done?

gpk’s picture

>You say "instead of the right approach which is to set the '#access' property of the relevant form element to FALSE". How is this done?
Well I think the first thing is to find out why the taxonomy terms can't be seen by the VIP user. That was just a hunch that the problem might lie in a custom module's hook_form_alter() implementation! If you are not the original developer of the site, are you in touch with them? It may not be a permission as such that is causing the problem, but rather some other configuration or as I say some custom code on the site. Bit of a detective job really... Come to think of it it could be Rules module, if you are using that, ... or plenty of other things.. maybe I'm missing something obvious...

putkonen’s picture

I'm part of the developers. The site is quite complex but there is only one custom module, and it's quite simple. I grep'd the source codes of modules and obviously there's quite a lot of hook_form_alter() used in different modules. Our custom module does not modify the form in question.

There is also about 20 rules, but I can't see a reason why any of those could affect the situation.

Problematic node uses an own content type. However, I verified that the same behaviour happens with a page.

There is nothing in the rules nor in the modules which is specific for "VIP users".

Thank you for your continuous support. I'm puzzled.

gpk’s picture

As a next step probably I'd use devel.module to view the $node object as admin and as VIP (via the Dev load tab), and also to examine (via dpm()) the $form structure when editing a node, to see what's going on with the node's taxonomy terms.

putkonen’s picture

In $node, taxonomy is empty for VIP user:

taxonomy (Array, 0 elements)

For webmaster it contains the correct taxonomy information:

taxonomy (Array, 1 element)

Where should I put the dpm($form) command in order to view the output?

gpk’s picture

>Where should I put the dpm($form) command in order to view the output?
That would go in hook_form_alter() in a custom module but since you've already determined that the taxonomy info is not being loaded with the node it probably wouldn't show anything helpful.

So why is taxonomy stuff missing... very odd... are you sure you aren't using a module to control this, e.g. http://drupal.org/project/vocabperms... or maybe your taxonomy is actually a CCK field and you are using content permissions module (bundled with CCK)???

Running out of ideas ... hard to do much more remote/blind diagnosis... Rules you said was not implicated... Head scratch...

putkonen’s picture

I think I finally found the reason, after spending once again several hours.

I duplicated the role VIP user and painstakingly compared it with a role which worked fine.

Finally I noticed that the user must have both "create" and "list" enabled in taxonomy access permissions screen (for the terms she is allowed to access). Otherwise taxonomy information of the node is lost and node access gets overwritten.

I would still like to prevent VIP users from viewing or changing the taxonomy for the node, but I'm glad I found a solution. Could this be a bug in TAC, or have I misunderstood how it should work?

Thank you so much for all your help.

gpk’s picture

>Finally I noticed that the user must have both "create" and "list" enabled ... Could this be a bug in TAC, or have I misunderstood how it should work?
Ah, I've only used tac_lite which works a bit differently. The behavior sounds a bit buggy to me... as a work around for your current settings with both "create" and "list" enabled you can implement hook_form_alter() in your custom module to set the #access property of the taxonomy form element to FALSE when VIP user is editing a node, and use themeing to hide the taxonomy terms when viewing a node. But might be worth asking a question in the TAC issue queue, since I can't off the top of my head see much use for the current behavior especially since it leads to inconsistent entries in the node access table.

Another way forward might be to put the taxonomy term in a CCK field .. I think there is a module for this.. then you can use content permissions module to control access to it (the only snag with this is that by default content permissions denies both view and edit access to all fields for all user roles so you will have to explicitly go in and grant view and edit permission for the other CCK fields too ... but that's no great headache).

Anyway, glad you got to the bottom of it!

putkonen’s picture

Here's the issue, in case somebody ends up in this thread looking for help:

http://drupal.org/node/881210