Adding non-Required OG Relationship to View Causes View to Display no Results for Anonymous

I have a similar issue: if I create a view of group content nodes, where some of those nodes do not have a group membership, but the view uses the group membership relation, the non-admin users cannot see the nodes that do not have a group membership.

Scenario:
Post on fish (by John) - in food group
Post on ideas (by John) - not in a group
Post on cheese (by Sally) - in food group

John is member of food group

In a view of posts that are either in a user's group or authored by that user: John can see posts on fish and cheese but not ideas, even though he did author that post.

In the same view, Admins can see all three posts.

If John goes to the 'post on ideas' node, he does not get an access denied. It's only in the view that he can't see it.

In views admin - view preview, with contextual filters set to John, it appears to Admin that John can see all three posts. When John views the view for himself, he can only see the two posts.

And I *think* that this only happened since the recent OG update to 2.7.

Update:

This only happens with the following relationships in the view:
group content->og membership AND og membership->group node
And it happens even if both relationships are not required and there are no filters/fields showing on either relationship.

E.g.
- Post nodes can be group content
- John (non-admin) create Post A, which is in Food Group
- John creates Post B, which is in no group

View of posts by user, with relationship Post -> og membership
- John can see both his posts

View of posts by user, with relationship Post -> og membership AND og membership->Group Node
- John can only see Post A

If John visits /node/post-A and /node/post-B he has no problem accessing the content. The content access is only affected in a View.

Somehow the presence of the Group Node relationship in the view seems to invoke an access check that denies the user access to, presumably, a null Group Node.

I have Group Content Access enabled.

Anyone?

Rest assured, you're not the only one to encounter this issue ;)

The Problem

I too have a site where a User -> Company (OG) relationship exists. It is quite normal for a user to exist, without being assigned to a company.

I've built a View showing users with a "OG membership: Group Node from OG membership" relationship to make company fields accessible. In this case, I wanted to display the company name / logo next to each user.

The "Require this relationship" option was left un-ticked.

The expected behaviour is for all users to show, and the company fields outputted if the user has a company assigned. However, in reality only users who belonged to a company group were outputted, regardless of the "Required" setting.

One interesting observation, users with the "bypass node access" permission were able to see the missing users (i.e. an administrator).

-----------------

The Workaround

While this appears to be an issue with Organic Groups, I did find a neat trick to bypass this issue and get the desired results.

In the view, under "Query Settings", tick the box labelled "Disable SQL rewriting".

The benefit is that "Disabling SQL rewriting will disable node_access checks". This replicates the "bypass node access" permissions, but only within the context of the view which keeps things relatively secure.

Note, there are a few drawbacks, namely:

1. Additional modules will no longer be able to hook into this query (For me, this wasn't an issue).
2. With node-access checks disabled, you may find other unwanted content showing in the list.

Hmm... Thanks, that does work. But it makes me pretty nervous!

Anyone on the OG team who has any idea about this?

I have the same issue: This is a problem because it isn't possible to show associated group nodes of content for anonymous users.

To show a field of a parent group, you have to add the relationships "og membership of from node" and "og group from og membership".

When I add the first relationship "og membership of from node", the view is still accessible by anonymous users. After adding the second relationship "og group from og membership", the contents of the view aren't accessible by anonymous users.

The query produced by views:

SELECT DISTINCT node.nid AS nid, node_og_membership.nid AS node_og_membership_nid, node.created AS node_created, 'node' AS field_data_field_year_node_entity_type, 'node' AS field_data_field_project_category_node_entity_type
FROM
{node} node
LEFT JOIN {og_membership} og_membership_node ON node.nid = og_membership_node.etid AND og_membership_node.entity_type = 'node'
LEFT JOIN {node} node_og_membership ON og_membership_node.gid = node_og_membership.nid AND og_membership_node.group_type = 'node'
LEFT JOIN {field_data_field_project_category} node_og_membership__field_data_field_project_category ON node_og_membership.nid = node_og_membership__field_data_field_project_category.entity_id AND (node_og_membership__field_data_field_project_category.entity_type = 'node' AND node_og_membership__field_data_field_project_category.deleted = '0')
WHERE (( (node.status = '1') AND (node.type IN ('gallery')) AND (node_og_membership__field_data_field_project_category.field_project_category_tid IS NOT NULL ) ))
ORDER BY node_created DESC
LIMIT 10 OFFSET 0

https://www.drupal.org/node/1349080#comment-9449897 fixes the problem

I found this issue over the past few days while facing a security issue with a client. It turns out this all leads back to how the og_context() function was updated in the 2.8 release. By default, it now checks access against a given or current user, which then denies anonymous users to see a View that is passed by a contextual filter using OG validation.

I have found this issue on the Github issue queue that references this exact patch, where you can turn off access checking.

https://github.com/Gizra/og/pull/131

It looks like a Pull Request is pending based on some Travis CI issues being fixed, but the patch looks fairly basic if you'd like to implement it yourself.

File diff for patch

This has been patched and fixed on Github.

https://github.com/Gizra/og/pull/131