When node_access_grants() is called, node_view_permissions does not set a grant rule even though a user may have the "view own of type" and/or "view any of type" permission set on their account.
Original Posting
I have confirmed that this is related to Node View Permissions by trying without it. Whenever I select some content types for Node View Permissions, nothing short of "Bypass content access control" or being admin will show any nodes in views.
I tried to update all modules. Drupal core is 7.17.
Here is a simple test view that does not show any nodes (two content types selected in filters, no matter if it is only one or if none, no Node View Permission related nodes are shown):
$view = new view();
$view->name = 'testin_kym_';
$view->description = '';
$view->tag = 'default';
$view->base_table = 'node';
$view->human_name = 'TEST-VIEW';
$view->core = 7;
$view->api_version = '3.0';
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
/* Display: Master */
$handler = $view->new_display('default', 'Master', 'default');
$handler->display->display_options['title'] = 'Test-view';
$handler->display->display_options['use_more_always'] = FALSE;
$handler->display->display_options['access']['type'] = 'perm';
$handler->display->display_options['cache']['type'] = 'none';
$handler->display->display_options['query']['type'] = 'views_query';
$handler->display->display_options['exposed_form']['type'] = 'basic';
$handler->display->display_options['pager']['type'] = 'full';
$handler->display->display_options['pager']['options']['items_per_page'] = '10';
$handler->display->display_options['style_plugin'] = 'default';
$handler->display->display_options['row_plugin'] = 'node';
/* Field: Content: Title */
$handler->display->display_options['fields']['title']['id'] = 'title';
$handler->display->display_options['fields']['title']['table'] = 'node';
$handler->display->display_options['fields']['title']['field'] = 'title';
$handler->display->display_options['fields']['title']['label'] = '';
$handler->display->display_options['fields']['title']['alter']['word_boundary'] = FALSE;
$handler->display->display_options['fields']['title']['alter']['ellipsis'] = FALSE;
/* Sort criterion: Content: Post date */
$handler->display->display_options['sorts']['created']['id'] = 'created';
$handler->display->display_options['sorts']['created']['table'] = 'node';
$handler->display->display_options['sorts']['created']['field'] = 'created';
$handler->display->display_options['sorts']['created']['order'] = 'DESC';
/* Filter criterion: Content: Published */
$handler->display->display_options['filters']['status']['id'] = 'status';
$handler->display->display_options['filters']['status']['table'] = 'node';
$handler->display->display_options['filters']['status']['field'] = 'status';
$handler->display->display_options['filters']['status']['value'] = 1;
$handler->display->display_options['filters']['status']['group'] = 1;
$handler->display->display_options['filters']['status']['expose']['operator'] = FALSE;
/* Filter criterion: Content: Type */
$handler->display->display_options['filters']['type_1']['id'] = 'type_1';
$handler->display->display_options['filters']['type_1']['table'] = 'node';
$handler->display->display_options['filters']['type_1']['field'] = 'type';
$handler->display->display_options['filters']['type_1']['value'] = array(
'article' => 'article',
'page' => 'page',
);
/* Display: Page */
$handler = $view->new_display('page', 'Page', 'page');
$handler->display->display_options['defaults']['hide_admin_links'] = FALSE;
$handler->display->display_options['path'] = 'testview';
$translatables['testin_kym_'] = array(
t('Master'),
t('Test-view'),
t('more'),
t('Apply'),
t('Reset'),
t('Sort by'),
t('Asc'),
t('Desc'),
t('Items per page'),
t('- All -'),
t('Offset'),
t('« first'),
t('‹ previous'),
t('next ›'),
t('last »'),
t('Page'),
);
Comment | File | Size | Author |
---|---|---|---|
#18 | node_view_permissions-node_grants_override-2086813-18.patch | 7.26 KB | rossb89 |
#5 | 2086813-node-grants-override.patch | 6.77 KB | minorOffense |
Comments
Comment #0.0
mmakela CreditAttribution: mmakela commentedCorrected one typo.
Comment #1
minorOffense CreditAttribution: minorOffense commentedI'm seeing the same issue on Drupal 7.23 and 1.3 of the module.
Comment #2
minorOffense CreditAttribution: minorOffense commentedLooking at the node_access table. It would appear no entries are made for nodes with the node view permissions settings enabled.
In views_handler_filter_node_access it uses the data from node_access to determine if the user can see the node. This will always fail with node view permissions enabled.
http://drupalcode.org/project/views.git/blob/refs/heads/7.x-3.x:/modules...
Comment #3
minorOffense CreditAttribution: minorOffense commentedOk, I think I know what's going on. This is a special case when Node View Permissions is on and another module which implements hook_node_grants is also enabled. Since the node access calls in Views only run when node_grants is implemented and node_view_permissions does not implement that hook, it is left to the other node_grants implementation to tell Views if the user has access or not.
Essentially, since node_view_permissions avoids using node_grants, when something else uses node_grants, the permissions defined by node_view_permissions are ignored by any system checking against the grants table.
It appears as though a default entry is attempted to be added to the grants table ( by node_view_permissions_node_access_records) but I don't think that's working as expected in this use case.
I'll post more as I go.
Comment #4
minorOffense CreditAttribution: minorOffense commentedComment #5
minorOffense CreditAttribution: minorOffense commentedOk, I've figured it out. When a module implements grants, I've added an option to have node_view_permissions to add a grant entry for view on the appropriate permissions.
I did *not* add an implementation of hook_node_grants. Instead I used hook_node_grants_alter() to make the necessary changes. I also changed hook_node_access_records() to make the appropriate record entries when this option is enabled.
Have a go and enable the override as required. Tryed it out with Views and it works great there.
Comment #6
minorOffense CreditAttribution: minorOffense commentedI should note that this patch was made against the master branch. It won't apply to 1.3.
Comment #7
minorOffense CreditAttribution: minorOffense commentedComment #8
GemQueen CreditAttribution: GemQueen commentedI have 1.3, I have this problem too. I disabled node view permission for the affected content type, changed permissions to anyone, and I STILL can't get the link to work in View - I'm really stuck. Any ideas how to turn this off? I can't uninstall the module, I have other content types that are working (not using views), and need to stay that way. I'm handy with SQL so if you could point me in the direction of clearing stuff out the DB, I'd appreciate it. I have cleared caches, and rebuilt permissions - didn't help.
OK - NEVER MIND - I found a conflicting field permission setting I had - totally pilot error! Sheesh - too many places to set too many different types of permissions, easy to forget what you set where.
Comment #9
minorOffense CreditAttribution: minorOffense commentedThe patch should fix any issue. Just run the latest from git.
Comment #10
jiakomo CreditAttribution: jiakomo commentedI am about to use 1.3 version. Does this bug mean that it will not work with Views?
Comment #11
minorOffense CreditAttribution: minorOffense commentedNo it just means you can't have a node grant module enabled and expect your node view permissions to work in views. (Ex OG access, Content Access)
The patch does fix this however.
Comment #12
adwuk CreditAttribution: adwuk commentedI have applied the patch to 1.3 and the override works well for authenticated users. When the override is enabled for anonymous users errors like "Notice: Undefined index: view own content_type content in node_view_permissions_node_grants_alter() (line 139 of .../sites/all/modules/node_view_permissions/node_view_permissions.module)." are reported.
I have added the following code:
around the offending lines. That seems to sort the problem.
Comment #13
hoter CreditAttribution: hoter commentedThanks a lot for your response. I understand that you've done a great job. But as we wrote in the description of this module, we tried to develop this module in a non-conflict way. So if any module will set its node grants, we will not override them. But your additional option in the settings form is very interesting solution. We will discuss your solution.. Thank you again, we are grateful for your contribution.
Comment #14
minorOffense CreditAttribution: minorOffense commentedIf you don't put that patch in, or do something to work with node grants I would then suggest notifying the user on the status report page with a warning. Stating that those permissions will be ignored due to node grants being in use.
Comment #15
ssankara73 CreditAttribution: ssankara73 commentedI ran into the same issue with anonymous users not being able to get access to any published content in spite of having the "View Published Content" set and having permissions in Node View Permissions to specific Content type (any content in the Content Type) set.
I also have OG access enabled and from your post, I suspect that the reason why anonymous users are not able to see the content is because of the OG access module. I disabled the Node View Permissions module but still am not able to get anonymous users to see the published content through a view. What else do I need to do? I really cannot revert back to the configuration before OG was installed as there is a considerable amount of OG related work that has already been done.
The principal problem that I was trying to solve was to make sure that anonymous users were given access to certain content types but some other content types were strictly for the consumption of authorized users and OG active members.
Thank you for your help!
Comment #16
minorOffense CreditAttribution: minorOffense commentedOG access uses node grants. So if the grant isn't in place it won't work (regardless of node view permissions). There are settings in OG Permissions for this. But this is really a support request for OG. Not really to do with this issue.
The only thing this patch would help with is create a node grants entry alongside the settings from OG.
Comment #17
TajinderSingh CreditAttribution: TajinderSingh commentedminorOffense: Thanks for working out the patch. It completely serves the purpose and completes what was done by Content_access module in Drupal 6.
Seems a little issue with patch as at end it removes space from between function argument:
function node_view_permissions_query_node_access_alter(QueryAlterableInterface $query) {
becomes
function node_view_permissions_query_node_access_alter(QueryAlterableInterface$query) {
after patch. Space before $query is being removed which will lead in errors.
Thanks again.
Comment #18
rossb89 CreditAttribution: rossb89 commentedThanks for the patch, solves the issue(s) I was having.
I also had the problem mentioned in comment #12, with various "Notice: Undefined index:...."
So have re-rolled the patch against latest dev (1.5), to add the array_key_exists() from comment #12 and fix the missing space issue with:
QueryAlterableInterface$query changed to QueryAlterableInterface $query
Comment #19
bmango CreditAttribution: bmango commentedThank you so much for your patches guys. My nodes weren't displaying in the contents list, but were visible individually. I couldn't work out what the problem was, until I came across this thread. I checked what other modules were using hook_node_grants, and found that the quiz module was using it, which was causing the conflict. I installed the patch in #18, and then ticked the node permissions override and this solved my problem.
I just wanted to mention that the patch didn't work at first, it was only when I used git apply with the --ignore-whitespace option that it applied. I applied it to the 7.x-1.x-dev version.
Thanks again :)
Comment #20
thomasmurphy CreditAttribution: thomasmurphy commentedI tried applying the patch from #18 but it didn't solve the problem in my particular circumstances. I disabled Node View Permissions which fixed the problem, and I replaced the functionality with https://www.drupal.org/project/nodetype_access which is now working fine.
Comment #21
SebCorbin CreditAttribution: SebCorbin at Makina Corpus commentedlike @bmango the module totally becomes useless (and more, denies all access) once quiz is enabled, so I applied the patch from #18, enabled override and it works again.
Thanks a lot for the patch
Comment #22
Roadking CreditAttribution: Roadking commentedWill this patch apply correctly to 1.6 as well? Or was it possibly already rolled into 1.6? I've been using it successfully in 1.5 for years and had not applied 1.6 yet. ..and thanks for the work on the patch!
Comment #24
adci_contributor CreditAttribution: adci_contributor at ADCI Solutions commentedThank you all for looking into this and especially to minorOffense for the patch! We applied changes into dev branch of module.
If you prefer stable release — this patch can be applied to 1.6 version of the module, although one of hunks will fail but nothing critical.
Comment #25
adci_contributor CreditAttribution: adci_contributor at ADCI Solutions commented