Views: cannot reliably relate/filter group content to groups when multiple audience fields exist
>>> [!note] Migrated issue
<!-- Drupal.org comment -->
<!-- Migrated from issue #3501637. -->
Reported by: [joelpittet](https://www.drupal.org/user/160302)
Related to !22 !48
>>>
<h3 id="summary-problem-motivation">Problem/Motivation</h3>
<p>In Drupal 7, the <code>og_membership</code> table acted as an index for all group content to group relationships across any field, allowing for easy filters and contextual filters in Views. In Drupal 8+, these relationships are spread across multiple entity reference field tables (e.g., <code>node__group_ref</code>, <code>node__other</code>), making it cumbersome to achieve the same results in Views, especially when there are multiple group fields on a single group content entity.</p>
<h4 id="summary-steps-reproduce">Steps to reproduce</h4>
<ul>
<li>Create a group content entity with multiple entity reference fields pointing to different groups.</li>
<li>Attempt to create a single contextual filter in Views to retrieve all groups that the group content belongs to.</li>
<li>Note that you must create multiple contextual filters, one for each field, due to the absence of an index table consolidating these relationships.</li>
</ul>
<h3 id="summary-proposed-resolution">Proposed resolution</h3>
<p>Two alternative approaches are being explored:</p>
<ol>
<li><strong>Helper index table (existing proposal)</strong> —<br>
Add a consolidated <code>og_group_index</code> table (similar to<br>
<code>taxonomy_index</code>) to flatten group content → group references for<br>
simpler Views filtering and potential performance gains. (See <a href="https://git.drupalcode.org/project/og/-/merge_requests/22">MR 22</a>.)</li>
<li><strong>Read-time UNION (new proposal)</strong> —<br>
Provide Views handlers that, at query time, UNION across all OG audience/<br>
reference field tables for the selected group content entity type:<br>
a contextual filter “Group content by group,” a regular filter,<br>
a relationship “Group content → Group,” and an inverse “Group → Group content.”<br>
This avoids redundant storage and works across multiple audience fields. (See <a href="https://git.drupalcode.org/project/og/-/merge_requests/48">MR 48</a>.)</li>
</ol>
<p>Both aim to restore a single, reliable way to relate/filter group content and<br>
groups when multiple audience fields exist; the trade-off is write-time<br>
complexity + storage vs. read-time query complexity.</p>
<h3 id="summary-remaining-tasks">Remaining tasks</h3>
<ul>
<li>Discuss the feasibility of adding a helper table versus building UNION queries in Views.</li>
<li>Determine if the proposed table introduces redundancy and evaluate its trade-offs.</li>
<li>Write the schema definition for the <code>og_group_index</code> table.</li>
<li>Implement the table and populate it during entity save operations.</li>
<li>Update Views integration to use the new table for contextual filters.</li>
<li>Write tests to validate the functionality.</li>
</ul>
<h3 id="summary-ui-changes">User interface changes</h3>
<p>No direct UI changes; however, Views configuration will become more streamlined with the introduction of a single contextual filter for group content relationships.</p>
<h3 id="summary-api-changes">API changes</h3>
<p>Introduce a new helper table (<code>og_group_index</code>) and potentially expose new methods or plugins to interact with it in Views and other APIs.</p>
<h3 id="summary-data-model-changes">Data model changes</h3>
<p>Add a new table (<code>og_group_index</code>) to store flattened group content to group relationships.</p>
issue