Heya,
Love this module and I had great success with it until my most recent Drupal Upgrade.
I'm not certain that my issue is related to my upgrade, but I did want to let you know that this was a recent variable.
Basically, I have a taxonomy called 'Rating', and when Adult is selected, only people with the Adult Role can view it.
Now...People with the Adult role can view it fine. But people w/o the adult role can still view it, BUT it hides the Taxonomy Tag of 'Adult'.
So, instead of protecting the entire node content from view. Instead, it just hides the tag word 'Adult' from view.
Eek. :)
Any help or suggestions would be greatly appreciated. We only have one piece with this rating...but I need to get it working again just in case.
Comments
Comment #1
Chairman13 commentedI figured out the issue and it seems to be a bug related to child book pages. I investigated this after skimming over previous issues and finding some similar.
So, while it seems to have nothing to do with upgrading to 6.10, it is a functionality that I'd love to see added. Or maybe there's a patch that fixes it.
Right now, I've just told the story author to make it a blog piece and assign it to the book outline. So, I have a work around as long as joint editing privileges aren't needed.
However, if there's a way that I can get the Rating Taxonomy that I created to hold it's integrity on a child book page, it would be very helpful.
Thanks!
Comment #2
Dave Cohen commentedtac_lite, and every node_access module because this is how Drupal works, does not hide content from users who could otherwise see it. Rather, it grants access to users who would otherwise not see it.
So, if some module somewhere is allowing the user to view that node, the fact that it is tagged Adult will not matter. Something is permitting the view, perhaps a permission, a module implementing hook_access, or another access control module. To confirm this, try disabling tac_lite. Can the user still see the node? If so, there's nothing tac_lite can do about it.
Comment #3
Chairman13 commented*nod*
I found that if I use it just in the blog, it works. But if I assign it to a book outline, which other users have access view, then it doesn't keep the privacy.
So...I see what you're saying. In my case it's book access. ...and drat.
So, I would need a strictly Adult section, in which case I would lose book outline integration.
Thank you for the insight...I wasn't thinking along the right lines at all. :(
Comment #4
Dave Cohen commentedIt's tricky and catches a lot of people.
Comment #5
Chairman13 commentedI'm just asking here, I totally understand if you don't have any suggestions. ...but the more I think about this, the more that I think we're going about what we're trying to do - all wrong. :)
Basically, the reason we installed your module (which is working great), was to use it for PRIVACY. When instead, the intention of this module is to grant privileges. I feel like maybe we're going backwards. Like instead of having a module where we can request 3 things to be invisible to an authenticated users, we're using this module to mark 80 things that an authenticated user can see, just to keep three of them private.
For example, the first use for this was to allow us to have private Forum topics for the administrators. So, with your module we state each forum that each role is allowed to use. It confused me until recently, (when you just explained it to me in this thread), as I wondered, why we couldn't just mark the forums that people weren't suppose to see.
Is there a privacy module? That does the opposite of your module? One that instead of granting privileges, over and above drupal core and book access....it, overwrites drupal core and book access priveleges - on a per role basis?
Thanks for reading and helping me understand this stuff! :)
Comment #6
Dave Cohen commentedThere are modules like premium content, where the node itself is visible but portions of the node are visible only to privileged users. And there's hook_access, but to implement that you must define the content type in your own module.
Drupal's node_access assumes that if you're using it, you'll have at least one entry in the node_access table for every node. I wasn't around when it was designed so I can't say for sure, but I think the idea is to make queries somewhat efficient when displaying long lists of nodes. You want to alter queries with a join that tells drupal whether to show the node to the current user. I let smarter people than me think about that stuff.
Comment #7
Chairman13 commentedI'll read up on those modules, thank you. :)
I totally get the importance of query efficiency, we already had to move hosts once, because we were using too much CPU resources. Seems like some of the modules that we're using are not resource friendly, but we just want 'em anyway.