Create a View with Organic Group content

Monday 11 May 2015

Tags:
Organic Groups
Views
Drupal 7

If you want to list Organic Group content in a View you must do a little more that just add
one reference.

The default example is available if you enable Organic Groups. The name of that View is
"OG content" (machine-name: og_nodes).

I put it here on the blog because our usecase didn't use Organic Groups' default reference
field (og_ref that is) and because we chained multiple groups (a group has content and a
group is part of a parentgroup).

2 og-reference-fields, 3 content-types
In our case we used 2 different og-reference fields and 3 content-types were involved:

Parent Group Content-type: country.

Normal Group Content-type: team. OG-field: field_og_country.
Content Content-type: news. OG-field: field_og_team.

Now with a View, we want to get News-content from all Teams part of a Country.

With a normal entity reference field (not OG) you need 2 relations, in our case (yes OG) we
need 4.

Add relationships to your View

Create your View, now add these 4 relations in this exact order:

1. "OG membership: OG membership from Node" [The OG membership

associated with the Node entity.]

(This is the Team-group where the News-item is posted in)

Enable 'Require this relationship' to speed up the query.
As identifier and Administrive title put "OG membership from Node Team" to
improve your maintainability.
2. "OG membership: Group Node from OG membership" [The Node group
that is associated with the OG membership.]

As Relationship use the relation created in step 1. (critical)

Enable 'Require this relationship' to speed up the query.
As identifier and Administrive title put "Group node from OG membership Team" to
improve your maintainability.

3. "OG membership: OG membership from Node" [The OG membership

associated with the Node entity.]

(This is the Country-group where the Team-item is posted in)

As Relationship use the relation created in step 2. (critical)
Enable 'Require this relationship' to speed up the query.
As identifier and Administrive title put "OG membership from Node Country" to
improve your maintainability.

4. "OG membership: Group Node from OG membership" [The Node group

that is associated with the OG membership.]

As Relationship use the relation created in step 3. (critical)

Enable 'Require this relationship' to speed up the query.
As identifier and Administrive title put "Group node from OG membership Country"
to improve your maintainability.

Add a contextual filter to your View

As last step you can create the Contextual Filter that is used to filter on the ParentGroup
(Node-ID from Country).

5. "Content: Nid" [The node ID.]

As Relationship use the relation created in step 4 = "Group node from OG

membership Country". (critical)
And if you like: 'Provide default value': Content ID from URL.

Check your results

When you render this View on a Country-node, all News articles from Teams that are linked
to the Country are listed.
It took me a while but I finally figured this out. Here is how to make a view for one piece of
group content that shows ALL the groups it is in:

Contextual filter: (if this is supposed to be on the group content's node page.)
Node ID - default value: Content ID from URL (do not use relationship)

Relationships:
OG membership: OG membership from Content
OG membership: Group Content from OG membership (link first relationship)

Fields:
If referring to group, link second relationship (called 'Group node from OG membership' by
default)

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

Understanding Organic Groups in Views

Submitted by Rich on 4 July 2014 - 4:44pm

Organic Groups is a great module, but it ain't half confusing, especially when it comes to
using Views' relationships. What I wanted to do was get a list of groups that had no users. I
had to step back and understand a lot first, so am explaining it here for future reference and
for others.

The basics/typical organic group (OG) set-up

A 'group' is a node. A group can have users and other nodes attached to it by way of
'memberships'. Each attached node and user has it's own relationship record linking it to the
group node. It can get more complex than this (apparently groups etc. do not need to be
nodes), but let's focus on this typical use case.

Let's understand what's going on at table level

The node table holds a record for a group. This group's nid is then found in the
og_membership table's gid field (g for group). The table also holds group_type, which for
our case will be node because that's where our groups are defined.

The og_membership table then has an etid (entity id) and entity_type (in our case, this will
either be node or user).
Now what are all these Views relationships?
OG membership: Group Node from OG membership

This one assumes the node you started with is a group content node, because it joins it to
og_membership.etid and then goes on to join the group node.

So great for getting the group node(s) that relate to particular group content.

OG membership: Group User from OG membership

This one is useful if you have users defining a group. So this does not fit out typical case.
Like the previous one, it assumes you're starting with a content node and you want the group,
but for cases where the group is a user.

OG membership: Node from OG membership

Again, this one assumes you're starting with group content, and it looks for other content in
the same group(s).

OG membership: OG membership from Node

This one is more raw because it just joins the membership record itself again assuming that
you're starting with group content. Membership records are usually just behind-the-scenes
ways to get to related content, but one gives you access to them directly.

OG membership: OG membership from Node group

Here it assumes you start with the group node, not group content. As the last one, this
simply brings in the og_membership rows.

OG membership: OG Roles from membership

Assumes you start with group content, and gives you access to all the OG-specific user roles
for all users related to the same group(s) as the content.

OG membership: Type

Access the og_membership_type table for the group content.

OG membership: User from OG membership

Finally, this one starts with group content and finds users related to the same group(s).

Back to the problem: finding groups without users

I'm familiar with SQL, so I aproached the problem thinking the easiest way would be to add
the condition into the LEFT JOIN, and then test on NULL:
SELECT g.title
FROM node g
LEFT JOIN og_membership m
ON g.nid = m.gid
AND m.group_type = 'node'
AND m.entity_type = 'user'
WHERE g.type = 'my_group_node_type'
AND m.etid IS NULL;

However, you can't do this in Views, because the JOIN conditions are set-up by the
relationships; you can only affect the WHERE and the HAVING conditions.

Also, in looking at the tables I found that the Admin user (uid 1) had somehow been given
membership to all the groups (which were created programmatically). I also found that OG
will not let you delete this user from the group - you can try in the groups interface and it says
"Performed Remove from group on 1 item." in a green box, but it hasn't actually done
anything!

So this moved the goal posts. Again, in SQL I would just do:

SELECT g.title
FROM node g
LEFT JOIN og_membership m
ON g.nid = m.gid
AND m.group_type = 'node'
AND m.entity_type = 'user'
AND m.etid > 1
WHERE g.type = 'my_group_node_type'
AND m.etid IS NULL;

... but Views won't let me. So I resorted to a far less efficient HAVING COUNT solution as
follows

1. First, my View begins with nodes, with a node type filter for my group bundle.
2. I need the OG membership from Node group relationship, which will give me
access to all the membership records for this group.
3. I need to filter this relationship on Entity_type = user. This means I now have the
groups and their users (i.e. I've excluded the groups content nodes from the
relationships).
4. I need Use aggregation turned on.
5. I need to add another filter on the OG membership from node group relationship,
this time on Entity Id = 1, with aggregation set to Maximum.

So what's that done? Well it's looking at the maximum user Id for a group. As Admin will
always have user id 1, this works to find groups whose only user member is admin.

Phew, that was complicated. Well, if you know a better way, please leave me a comment.