I have the need for a site where I can define access to individual nodes by user. In this scenario, access by permission or roles is not finite enough. Node_Access has this ability. But when I want to create a view to display the node available to a given user, View's Access setting overrides the permission and roles settings in Node_Access. There is a similar module, Content Access that tries to solve a similar problem. But there are not controls to prioritize or hierarchize how these module's permission settings should subservient to the other modules that deal with permission. If Views would work with these modules, maybe via a Better Access for Views module, that could be one solution. In this situation I could give View's Access setting least priority, thereby saying that having role X is the lowest requirement to get permission to view this node, or in the case of defining by permission, to say "be subservient to the permission settings in Node_Access" or "be to subservient the permission settings in Content Access." The Another solution might be to have a Permission Hierarchy module where you could tell Drupal how to layer permissions. I am willing to sponsor the creation of a solution to this. How can we get this rolling?
Comments
try view reference
You might be able to solve at least part of your problem by node-izing your views. If you use the view reference module (http://drupal.org/project/viewreference), you can essentially turn a view into the content of a node, at which point it presumably would work the same way as other nodes in terms of access.
The main limitation I see on this approach is that you have to set any arguments when you create the node with the view reference in it. So you essentially have to create a separate node for each argument set you might want to pass to your view. Obviously, there are circumstances under which this could be quite cumbersome.
Thank for the suggestion,
Thank for the suggestion, Sid_M. I'll check out that module. I can think of ways around the solution like creating a unique role for each user and using but this is also cumbersome. I will not be the one creating the nodes on a day-to-day basis. A moderator will be doing this, so it need to be simpler.
Here is a little bit more
Here is a little bit more which might prove useful. This is sort of a recipe which you might be able to adopt to your needs.
We have a view with several displays, each of which takes a node ID as an argument. We wanted to give our administrators an easy way to create a node which would have as its content the view's output based on a display and node chosen by the administrator.
We didn't want the administrator to have to do something like find the node, and copy its ID from the URL. So instead we created a new content type with two fields: a view reference; and a node reference.
When configuring a view reference field, you get to choose which displays for which views should be available for that field. So we chose just the displays for the particular view we wanted to work with. We also turned on support for arguments. This now gave us a field with two parts: a select control containing all of the displays we had chosen for our view; and a text field for entering arguments (more on that in a moment).
We configured our node reference field so it would only allow referring to the specific type of node we wanted to allow as an argument to our view. The result of this is a field with a select control containing the titles of all of the nodes of the correct type.
So now an administrator could create a node of our type, select which view display to use for that node, and select which node to use as an argument to the view.
However, that is not quite enough because the view reference field is expecting the argument to be in the text field it provides for that purpose, not in the value of a wholly different node reference field.
However, that gap can be bridged with a very small amount of code.
First, we need to do two things with the argument text field provided as part of the view reference. We need to give it a value because it is a required field, and we would like to do something to let the user know not to worry about it. We solved both of these problems by using form_alter for the form ID of the form used to create or edit our node:
$form['field_rss_view_ref']['0']['#default_value']['arguments'] = t('Please do not change this field.');That gives the user instructions, and lets the field pass form validation.
The final step is to get the value from the node reference field, and inserted as the value for the view reference argument field. We do this in the presave operation of nodeapi:
if ($op == 'presave' && $node->type == 'promo_feed') {$node->field_rss_view_ref['0']['arguments'] = $node->field_rss_node_ref['0']['nid'];
}
Hope that proves useful.
You are confused. Views
You are confused. Views completely respects node_access and won't let a user view a node that is inaccessible via the node_access system. You don't need to do anything.
What if it is a User view?
What if it is a User view?
disagree
While Views will observe content restrictions on a per-node basis, it still loads the content in the View, making it confusing for users.
For instance: I have a site where I need to grant permission to users on a per-node basis. I can do that. But I also want to create a summary page (in Views) that loads the applicable node types. I want a given user to be able to click a menu link to this page and ONLY see the content to which he has access. Currently, he can see ALL node titles/teasers and when he clicks the ones he can't access, he gets a 403.
What we want is to build pages and blocks in Views that load a node type, but can also suppress the appearance of any nodes of that type which user does not have access to.
Custom SQL
You can customize the SQL that generates the summary to only grab nodes that the user has access to. You will need to create a new module that defines the function _views_pre_execute. I don't have the references for what I used to do this handy, but I can get them later.
It turned out to be fairly simple to do (if you know some PHP and are willing to hack through the SQL.)