This might be peculiar to my setup, but if you edit a node and change the access to a different term in your access vocab the permissions don't kick in unless you edit the node a second time and save it.

I am using workbench_access to provide editorial control, so there might be an issue there. I did have to set my node grant to -2 for tac_lite to take over from node_access.

devel_node_access doesn't report any inconsistencies or errors, it just doesn't change the permission for the users until the node is saved a second time.

I do have an issue with one content type with an access field not really working correctly. I have three content types all using the same taxonomy to control access (but different fields to make splitting the node types up for Features exports easier), and as far as I can tell the settings are all the same. When you first create the node you get the following from devel_node_access:

http://www.evernote.com/shard/s52/sh/13d172d4-19de-48cc-b343-ca9f491315c...

If you edit the newly created node and save it the node access is fixed and there are no more devel_node_access errors. If you then edit it and change the permission most of the time it behaves like the previous node types, requiring two saves to kick in, but sometimes you get this error:

http://www.evernote.com/shard/s52/sh/e2be9f6d-3b95-46ea-980c-c2e1e610275...

I've tried restoring back to an old version of this particular node type and re-creating the taxonomy access field, but the same thing happens. I think this particular content type is a bit stuffed, but there is definitely something going on with tac_lite in general.

Comments

ericaordinary’s picture

ericaordinary commented

I should note that clearing the cache after the first edit of the node doesn't help, it definitely requires two saves for the permissions to change.

Dave Cohen’s picture

Dave Cohen commented

First I've heard of anything like this. I suspect your setup has a problem outside tac_lite.

Maybe disable node_access, see if problem goes away.

Or if you can reproduce the problem with just core drupal + tac_lite, it would be easier for me to reproduce.

ericaordinary’s picture

ericaordinary commented

I've done a bit more investigating, and I can get tac_lite to work correctly on content types with workbench_moderation enabled. I think this is because the moderation is creating a draft and then publishing it in one step (when you choose for your node to be published straight away) which effectively saves the node twice. If I disable revisioning and moderation I get the same problem my third node type was having, needing to save it again after creating or updating the access field.

I'm wondering if this is related to workbench module, or perhaps just generally to the hairy node grants issues that seem to crop up when you have multiple node access modules working in tandem. I've tried changing the node grants priorities in my content types to some different levels and testing, but that doesn't seem to help. I will test on a sandbox with just drupal and tac_lite, and then add workbench into the mix to see if I can reproduce.

mhenman’s picture

mhenman commented

I'm having the same issue. After a bit of digging, I found that tac_lite is querying the taxonomy_index table to determine which terms are present on a node, however on my site, this table isn't updated on every save. I'm using the workflow and revisioning modules, so I'm not sure if one of them is affecting the updates to that table. I've got a bit more digging to do to see if there is an alternative method of correctly querying the taxonomy from the currently published node revision.

Dave Cohen’s picture

Dave Cohen commented

Interesting. that code in _tac_lite_get_terms() was way more straightforward in Drupal 6.x. It simply inspected $node->taxonomy.

It may not have been upgraded to drupal 7 in the best way. In D7 everything's a field and don't know of any simple reliable way to ask "what are the terms associated with this node?" Seems like something taxonomy_module should provide. And maybe it does and I don't know it.

So one option to fix would be find an entirely different way to get the node's terms. That function is passed a node with all the data, it just can't tell what's a term from a taxonomy it cares about.

The other option is to change the SQL query in _tac_lite_get_terms to be revision aware. That is, key off the node's vid (not taxonomy vid!) instead of nid. That may just not be possible, as the taxonomy_index table uses nid, not vid.

And what I'm talking about here would change tac_lite's behavior to make the node accessible based on it's current revision as opposed to it's latest revision. Which not even be the right behavior. I mean suppose a node is tagged in way that let's User X edit it. Then User Y changes the tags on the next not-yet-published revision, in a way that prevents User X from editing. Should User X be able to edit that node?

Leeteq’s picture

Leeteq commented

"And what I'm talking about here would change tac_lite's behavior to make the node accessible based on it's current revision as opposed to it's latest revision. Which not even be the right behavior. I mean suppose a node is tagged in way that let's User X edit it. Then User Y changes the tags on the next not-yet-published revision, in a way that prevents User X from editing. Should User X be able to edit that node?"

No, IMO user X should not be able to edit that node (anymore) even if that latest version is not yet published/'approved'.

Leeteq’s picture

Leeteq commented
Version: 7.x-1.0-rc1 » 7.x-1.x-dev
Status: Active » Postponed (maintainer needs more info)

Can anyone confirm if revision/workflow module(s) are causing problems like this for tac_lite on D7?

Edit:
Ref. also: #1958862: Users cannot see unpublished content in Views when TAC Lite is enabled

Dave Cohen’s picture

Dave Cohen commented

As you point out, #1958862: Users cannot see unpublished content in Views when TAC Lite is enabled has changed the way tac_lite determines the node's taxonomy. I'm curious whether that issue solves this as well.