In #2894728: Performance issues with og_moderation_node_grants(), hook_node_grants() and hook_node_access_records() were replaced with hook_node_access() for performance reasons.

However - hook_node_access is only called when viewing an actual node - not when building a view for example.

This is discussed in views issue #1266388: Views does not respect hook_node_access as well as https://drupal.stackexchange.com/questions/23225/having-views-respect-ho...

With the patch from #2901558: View any unpublished group permissions no longer work., if a user has the 'view any' permission from og_moderation, they can see the node if they visit the actual node path.

However the unpublished node does not appear in view listings which means if you have administrative views for group administrators to allow them to approve content - those will no longer work.

This same issue came up with workbench_moderation in #1492118: View all unpublished content permission not working - and I believe they made the switch to hook_node_access_records.

The approach in #2894728: Performance issues with og_moderation_node_grants() may be better for performance, but it fundamentally changes how useful this module is.

Comments

jastraat created an issue.

shenzhuxi’s picture

shenzhuxi CreditAttribution: shenzhuxi commented

In my test, Post is "Group content" type.
User with "View any unpublished Post content" can view unpublished Post at its owned URL and view fields showed with views. (right)
User with "Administer group" can view/edit unpublished Post at its owned URL and view fields showed with views. (right)
User without "View any unpublished Post content" and "Administer group" can't view/edit unpublished Post at its owned URL (right), but can view fields showed with views (wrong). Is it what you want to fix? Say "Views doesn't respect hook_node_access"?

However the unpublished node does not appear in view listings which means if you have administrative views for group administrators to allow them to approve content - those will no longer work.

Is it the description of the bug or what you want to do with views? Using VBO to approve content?

jastraat’s picture

jastraat CreditAttribution: jastraat at Technivant commented

> Using VBO to approve content?

We're not using VBO in this case. It's not relevant to the issue.

However, each group has it's own content administrators who can publish and unpublish content. These content administrators can view the content within their groups using views that contain both published and unpublished content.

> User with "Administer group" can view/edit unpublished Post at its owned URL and view fields showed with views. (right)

The administer group permission allows that role to manage USERS - who is a member, what roles they have. So that permission is usually not associated with our group content administrator role, and the ability to to see unpublished content should not be tied to having global control of membership within a group. Otherwise, what is the point of having a separate view unpublished permission? Given that, please exclude the 'administer group' permission from this conversation as well. It's also not relevant to the issue.

If a user has permission to view a node (view any unpublished within a group), that node should appear in all views for that user assuming that the view filters do not exclude it. An example of this is that private OG content is visible to members of that private group - not just at the URL of the content but also in views of that content.

Hook_node_access() only applies if node_load() is called. And obviously for performance reasons it doesn't make sense to call that on every node shown in a view. So hook_node_access is a poor choice when applying a view permission to content.

emerham’s picture

emerham CreditAttribution: emerham as a volunteer commented

I have also ran into this issue now when using the latest Dev release of og_moderation. Also to note that the OG module uses hook_node_grants() and hook_node_access_records(). So if there were to many SQL calls and thus performance was impacted maybe there is a better way to implement those two calls for views and menu to work correctly.

To top it off Drupal only calls hook_node_access() When viewing the Full Node https://api.drupal.org/comment/24158#comment-24158

crystaldawn’s picture

crystaldawn CreditAttribution: crystaldawn commented

#2894728: Performance issues with og_moderation_node_grants() breaks views compatibility resulting in this issue being created. We had to revert this by using a custom module and the old hook_node_access_records and hook_node_grants functions. It's not ideal to have 2 permissions schemes for this. Using hook_node_access() is not the correct fix here since it doesnt account for views, menus, etc. These 2 functions are less performant than hook_node_access() but a non-performant feature is better than a feature that doesnt work at all.