Allow group members to view subgroup members without being subgroup members themselves

The Group module can be used to build "communities" of users on a Drupal site with access restrictions. The Subgroup module allows you to set up a "hierarchy" of groups with "permissions" being inherited along the tree. The keyword here is "permission", not membership - which means that users in a subgroup do not become members of a group (see this issue). They inherit permissions for the group. That is to say, that group role permissions can be propagated "down" or "up" the tree. Remember that there is a tree structure such that there is a parent and child group(s).

The issue with membership not being inherited is that parent group members cannot directly see child group members on the parent group page (note with appropriate permission they can see all child group members on the child group pages). This documentation shows we can create a display using Views such that it is possible to see all child group members on the parent group page. Further access control can be layered on top of this. 

Use case: Build a website that allows healthcare workers (HCWs) of different institutes to view patients of their institute and not others. The parent group is an institute and the Child group is the disease site. 

The subgroup tree structure is 

Institute (Parent Group) -> Disease Group (Child Group)

Group roles:

1. Care seekers (patients).
2. Care providers (HCWs).

Role inheritance:

1. Care seeker in disease site becomes care seeker of the institute.
2. Care provider in Institute becomes care provider in disease site.

This step ensures that care providers are provided with the appropriate permissions (in this case view members and view content permissions are given to HCWs in institute propagate to these roles in disease site without them being actual members of disease site).

View configuration:

1. Start with the group content view bundle - no need to filter by type. Create a page. 
2. In the view add a relationship to Group
3. Add a contextual filter - Tree (with relationship Group) 
4. In the contextual filter click the Provide default value and select Group ID from URL in the dropdown
5. In the Page settings, the path should be set as group/%group/<your-choice-of-page-name>
6. Make this as a menu tab under the parent Main navigation
7. Access: Group permission View Individual group members

Add any fields that you would like to have in the field. 

This ensures that all HCWs of a given institute are able to see all patients in their institute (under all disease sites) without having to make the HCWs members of each disease site or patients members of each institute. 

Note 1:

If you are interested in displaying this view on the Parent group page then simply add an Entity View Attachment (EVA Module). Keep the same structure for the relationships and contextual filter. 

In the EVA settings:

1. Entity Type should be Group
2. Bundle can be left blank to select all bundles or can be restricted to the Parent Group
3. Choose Arguments as "Use the ID of the entity the view is attached to"
4. Choose to restrict access to the view by Group permission as above. 

The advantage of this method is that it automatically shows the list of the patients on the parent group page (thus saving an unnecessary navigation step). 

Note 2: 
If you wish to include additional information about the user activity in the view you should start with the parent view bundle (e.g. for Webform submissions results I started with the parent Webform Submission view type). From there I added the following relationships

1. User
2. (User) User group content - Filter by membership
3. (User group content) Group 
4. (User group content) Group content user. 

Note that relationships 3 and 4 allow the proper contextual filters (subgroup_tree) to be used. 

You can configure this with an EVA to display the list of all subgroup members who have submitted a specified type of Webform. 

Note 3:

For even better usability it is preferable that the HCW is redirected to a page that shows the EVA directly. The problem with this group permission will only work when there is a {group} parameter in the route. If not, it will always deny access. To ensure that this works properly, set up a view that shows a list of groups (in this case the parent group). Note that because of the way group access works it will only show the list of groups to which the HCW has access (in this case each HCW can belong to a single institute). To add the previous view simply use the "Views Field View" module to add the view to each row with the group ID being provided as a contextual filter. You can additional restrictions for access on this view itself. 

This can then be combined with a global redirect module to ensure that all HCWs (parent group members) are redirected to the page which shows all the patients (subgroup members) available for their institute who have submitted a webform when to log in.