Hi,

I ran into some problems with "grants" when using two modules together: workflow and tac_lite. This might not be a bug per se, but I think it would help to better understand why things are working the way they are.

The essential details: I have a node. The workflow module grants a particular user role view access. The tac_lite module disallows the access for this particular user role. When tested, the user really doesn't get to view the node. That's good. However, the node shows up in "Recent posts". That's not right (at least not to me anyway).

I'm a little new to the Drupal code, but after poking around a little, I understand that "Recent posts" generates the list of nodes accessible to the user by constructing a SQL query that is massaged through the db_rewrite_sql() functions. The node module OR's the grants together. When wanting to perform a specific action on the node (view, update, etc), module_grants behaves to AND the grants.

The different AND/OR modes of combining grants explains the different outcome of listing vs viewing nodes.

Ok, I noted in module_grants code, you do put a little comment in module_grants_node_access() about changing to OR mode. I did that change and I get the consistent result of listing vs viewing that I want.

My question is: Since the core node module is doing OR, is there a reason why module_grants wants to do AND by default? Is there any side effect of making the module_grants change to do OR? Apart from, of course, the obvious that I now just need one content access module to say "OK" for access to be granted.

Comments

rdeboer’s picture

Hi Izs,
I was waiting for someone to come up with a good reason for Module Grants to OR (rather than AND) between contributing content access modules. You're the first one to come up with an example -- well done!

However, reading your post again, you're basically saying that Module Grants is right and "Recent Posts" is wrong (or at least, errh.... different). So if Module Grants were to display OR-behaviour, then you'd have 2 bugs on your site, right? If I understand correctly you need to get "Recent Posts" to behave like Module Grants, rather than the other way around. I haven't looked at the code behind "Recent Posts" yet, but it would be unlikely that one can work around it, although there may be a hook().

The reason why I hard-coded an AND in Module Grants is that most of the time an AND provides the most intuitive behaviour (and having it hard-coded does away with an extra configuration option that users would have to worry about). Here's an example (from the Module Grants project page):

... when Taxonomy Access Control is set up so that an Arts moderator/publisher can't view a Sports article, because Arts moderators don't have access to the “sports” term, then it would be wrong if that Arts moderator suddenly does obtain access to Sports, when someone put content in the “review” state, and by the Workflow access grants moderators are allowed to view content in "review" (OR behaviour). Yet, this will be the behaviour you'll find if you don't have this module installed.

Nevertheless, it looks like it may be time to make the AND vs OR combination of access grants amongst modules configurable. Although it won't fix your "Recent Posts" ...
And then I'll wait until someone finds a pathological case of three content access modules with an AND between the first two and an OR between the second and third..... (sigh)

Rik

lzs’s picture

Hi Rik,

Yeah, my "complaint" is that they are different. I originally tried to do OR, because I consider "core code" to be correct and that plugins should be consistent with the former. However, you are right that the result I really want is AND. :) If I can't get AND, then consistency is the important thing.

Honestly, the mixture of OR and AND between multiple content access modules would be really cool too and in the back of my mind I feel the flexibility would come in useful. But I don't have a concrete practical example for this at the moment. :)

"Recent posts" isn't the problem per se, but it is how the problem can be shown. The real issue is how the grants are ORed in modules/node/node.module's _node_access_where_sql() and my concern is that there could be some other dependencies that execute an OR behaviour.

I would love to get the behaviour in the core code fixed. :) I wonder if there is a way for modules to override that OR in the core? At least moving forward I thought it would be important for the core code and module_grants to exhibit consistent behaviour.

Just a quick check: Is it the case that if what I want is OR, then I don't need module_grants?

rdeboer’s picture

Your are very forgiving Izs, if you're happy with just consistency, even if that means consistently wrong behaviour. I too considered core code to be correct until after extensive research on the web and in the source code I had to conclude that it really is flawed.
We could simply not meet our customers' requirements with the existing core. That's how Module Grants was born. Hopefully 'they' sort this out for D7.

Have you read this summary about node access permissions? It has some useful links.

To clarify your question... if you want OR behaviour (i.e. that what in most cases is the wrong behaviour), then you don't need Module Grants, except when you want content access to work on pre-published (as well as published) content (which is the other flaw in core that Module Grants fixes).

lzs’s picture

Thanks for the link. I've crawled so many pages that I'm beginning to forget what I read. But now that you've pointed it out it reinforces my understanding. :)

I discovered an interesting patch to do complex AND/OR combining: http://drupal.org/node/196922. But apparently it would go into D7.

I think I fundamentally prefer the AND that module_grants does. The problem is how to fix core to behave in the same way.

rdeboer’s picture

Assigned: Unassigned » rdeboer
Category: support » feature
Status: Active » Fixed

Implemented OR / AND toggle. See Administer>>Site configuration>>Module Grants
This will be available in versions dated 12-June-09 or later.

Status: Fixed » Closed (fixed)

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