Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Our site has certain products restricted to customers in specific roles (elite members). Even though the permissions are set up to exclude access on a per node basis to other customers (e.g. preferred members), the restricted products still show up in views to all roles.
We have tried flushing caches and rebuilding permissions, but nothing had worked.
Comments
Comment #1
codeglyph CreditAttribution: codeglyph commentedYes, i can confirm this.
I have a list of nodes and the ones that should be restricted aren't in fact cleared from the list. Nonetheless , clicking the link to the node leads to a 'Access Denied' page if the access is restricted. So the access module does function.
On the other hand selecting the 'Nodeaccess' filter restricts EVERYTHING from the list, even the nodes that should be allowed. This is very annoying.
Probably related to the way the node access and views are working together.
Any ideas?
Comment #2
jasonaaronwood CreditAttribution: jasonaaronwood commentedI have been having the same problem. I have set up a Views block that displays titles (with links) of all nodes of one type (which I've called "Lesson Post"). I'm displaying this block in a Panel Pane, except it displays all of the posts.
So far I have tried both the "Node Privacy By Role" and "Content Access" modules in every configuration I could imagine to restrict which nodes appear by role, but I had no luck.
With Nodeaccess, I was able to finally get this to work but it was very tedious:
* Every role must have permissions set to "Access Content" (under Roles > Permissions > Node Module)
* Administer > User Management > Nodeaccess: under "Allowed Roles," check the box beside every role that you want to be able to add node-specific access to.
* Then on the same page, scroll down to the content type that you are listing in your View (or any content type you want to control with Nodeaccess) and check the box for "Show grant tab for this node type".
* Then press the "Save Grants" button.
Now, you have to individually go to each node, and there will be a new tab called "Grant" (in addition to "View" and "Edit"). Click on that tab, then from the list check the box(es) beside the role(s) you want to allow access for that specific node.
I hope this helps...this was a total nightmare until I haphazardly figured this out.
Comment #3
jasonaaronwood CreditAttribution: jasonaaronwood commented....and you know what, it didn't work after all.... I thought I had it figured out, sorry!
Still trying to pinpoint the source of the conflict between Views and Nodeaccess.
Comment #4
Anonymous (not verified) CreditAttribution: Anonymous commentedI'm fairly certain this is an issue with views...
The node access system is managed by drupal core. modules such as this are only consulted when saving or updating a node to tell core what permissions to give. When it comes to actually viewing nodes, the module is not consulted at all, drupal core just manages permissions based on it's own access table. So, I would say it would not be possible for this module to have any influence on what views shows, if the nodes are properly restricted (you can't go to them) then the problem would be with views.
Comment #5
mmilo CreditAttribution: mmilo commentedRe-opening.
My use case may show this is -might- be an issue within nodeaccess?
Let's say I have:
- Content type "Apple"
- User role "Red"
- A view "Fruit" which shows all 3 Apples I have
-
admin/user/nodeaccess
grants all of view/edit/delete to "Red" for "Apple"If I:
- edit Apple#1 using under admin (uid == 1) role, "Fruit" shows up normally
- view "Fruit" under "Red" right after, Apple#1 no longer shows up in the view.
The only way it will show up is if I open up the node only logged in under "Red"
Of course, this means that I need the direct URL to the node, because it no longer shows up in the view. However, the admin isn't going to send the URL manually to Apple#1 everytime it's updated, so that it will show back up in the view.
If I check the "Show grant tab for this node type" option, and add a user with the "Red" role however, everything works as expected. Adding the user manually, is of course, redundant.
Since this problem with Views can be worked around with what I performed above,
is your statement below false?
Thanks!
Comment #6
Michsk CreditAttribution: Michsk commentedi haven't read all the comments in this issue, but im having no problems with views.
Comment #7
cmcintosh CreditAttribution: cmcintosh commentedIt could be causing issues maybe if you set your permissions so that role can access any views, i have seen this happen inside of a Services API call i did for a flash application. I think it is more an issue with how views is checking permissions versus how node access is setting them.
Evansville Website Desginer - http://ChrisMcIntoshDesigns.com
Comment #8
Michsk CreditAttribution: Michsk commentedhave you unchecked all the perms for the node_type. You have to uncheck all the options for the node_type and then only let the author set who can view it. Then everything should work in views.
Comment #9
1timer CreditAttribution: 1timer commentedsub
Comment #10
llillf CreditAttribution: llillf commentedsubscribe
Comment #11
jduhls CreditAttribution: jduhls commentedPlease add views integration so I can filter by nodeaccess grants. I'm on 7.x.
"Content Access" module is not working.Switched to dev branch of "Content Access" and "ACL" modules and they work great with "Views" using filter by content access. Also provides granular integration with "Features" module.Actually had to disable/remove "Content Access" and "ACL" - they didn't work on my production site for some reason. This module actually seems to be working quite well even with views.Comment #12
vlad.pavlovic CreditAttribution: vlad.pavlovic commentedViews integration will only be added to Drupal 7 version, no new features will be added to 6.x-1.x.
Workarounds from https://drupal.org/comment/3664216#comment-3664216 and https://drupal.org/comment/3426840#comment-3426840 sufficiently cover requirements at this time.