OG roles relationship missing and og_roles field/filter not functioning in Views

Created on 12 July 2025, 10 days ago

Problem/Motivation

In Drupal 7, the OG module provided an og_users_roles relationship labeled “OG Roles from membership”, which allowed Views to expose and filter OG roles associated with a user’s group membership. In Drupal 10, this relationship appears to be missing. The replacement field, og_roles (“The OG roles related to an OG membership entity”), appears in Views but does not display any values. Additionally, when exposed as a filter, it is presented as a plain text input instead of an options list, reducing usability compared to the Drupal 7 version.

Steps to reproduce

  1. Create a View of OG membership entities.
  2. Attempt to add a relationship or field that shows OG roles related to each membership.
  3. Note that:
    • There is no equivalent relationship to og_users_roles.
    • The og_roles field does not return any values in the output.
    • The exposed filter for OG roles is a plain text field instead of a select list.

Proposed resolution

Restore a working relationship or field that connects OG membership entities to their associated OG roles, similar to og_users_roles in Drupal 7. Ensure that:

  • The field displays actual role values in the View.
  • The exposed filter renders as a select list with role options, not a text input.

Remaining tasks

  • Investigate why og_roles returns no values.
  • Determine whether a relationship plugin for OG roles is missing.
  • Add or fix the OG roles relationship.
  • Ensure the exposed filter uses a select list with available OG roles.
  • Write automated test coverage to validate field output and filter behavior.
🐛 Bug report
Status

Active

Version

2.0

Component

og.module

Created by

🇨🇦Canada joelpittet Vancouver

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @joelpittet
  • 🇨🇦Canada joelpittet Vancouver

    I'm simplifying the scope as it seems the relationship and field are actually working (my migration needs a bit of help for the roles apparently).

  • 🇨🇦Canada joelpittet Vancouver

    D7:

    D10 (Work in Progress):

    In D7, access was determined based on the role labels, which allowed targeting roles across bundles more easily.
    In D10, I’ve shifted to using role IDs, but the tradeoff is that I can’t easily target roles across bundles unless I explicitly include each one.

    Would it make sense to introduce a role name (label-based) lookup helper so that the behavior mirrors D7?
    One concern with continuing to rely on role machine names is the potential for duplication—especially if roles are auto-generated per-node,
    resulting in names like ENTITY_TYPE-ENTITY_BUNDLE-member and ENTITY_TYPE-ENTITY_BUNDLE-member-1.

    Any suggestions or direction would be appreciated.

  • 🇮🇱Israel amitaibu Israel

    Just to make sure I understand. I don't remember how it works on D7, but based on what you wrote, you want each role label to appear only once (Admin, Member, Non-admin).
    And it should work regardless of the group type, because you want it to filter by the role label?

    Can you give your use case, that might help finding the right solution

  • 🇨🇦Canada joelpittet Vancouver

    We have various views with exposed role filters—like filtering for who’s the chair of a committee, or who’s an administrator of a group. In some cases, we also want to filter by any role except "Hidden" or "Portfolio” (that’s a real example). From a user’s perspective, they don’t care which group type (bundle) a role is attached to—they just want to filter by the Role (label).

    I’d prefer not to prefix the role labels with the bundle to distinguish them to the site builder configuring this, and since that would mean using grouped exposed filters and manually relabeling everything for clarity, which adds unnecessary complexity. So I guess I am leaning towards the helper to lookup roles by label and just showing (unique) labels like D7 had.

    Feel free to disagree if that doesn't make sense still

  • 🇮🇱Israel amitaibu Israel

    Just throwing an idea: `OgRole` is a fieldable entity. So you could have a `field_simple_label` that would hold the name of the role as you expect to.

    Then Views core Contextual filters could be setup to filter by that field.

    Does that make sense for your use case?

  • Merge request !44WIP options list based on role ids → (Open) created by joelpittet
  • 🇨🇦Canada joelpittet Vancouver

    That’s a novel idea—definitely good to think of alternate approaches. That said, I’d prefer not to add custom fields just to filter roles by label. It feels a bit off to decouple the display label from the core role entity, and it adds extra overhead that’s easy to miss or forget about later. At that point, using a grouped exposed filter in Views might be simpler, even if it requires some relabeling.

    What I was originally thinking was something like adding a method to OgRoleManagerInterface, maybe getRolesByLabel(), to return a unique list of roles keyed by label regardless of bundle. But maybe there’s some resistance to that since it could introduce ambiguity or complicate the API? Curious what your take is?

    The current MR shows what's in the screenshot in comment #3 BTW

Production build 0.71.5 2024