Pending group membership requests incorrectly displayed in inherited project member lists (UI issue)

Summary

Users with pending group membership requests are incorrectly appearing in child project member lists as "Inherited from [parent]/[child]" even though their membership request is still pending approval. This is a UI display issue only - testing confirms that affected users do not have actual functional access to the projects.

Steps to reproduce

1. User is a member of top-level group parent-group (via SAML) - active membership
2. User requests access to subgroup child-group - request stays pending (requested_at IS NOT NULL)
3. User appears in a child project under child-group as "Inherited from parent-group / child-group"
4. When the pending request is denied, the user is correctly removed from the project member list

What is the current bug behavior?

Pending group membership requests are being displayed in project member lists with inheritance notation, creating confusion about user access when they do not actually have functional access to the project.

What is the expected correct behavior?

Only active group memberships (requested_at IS NULL) should be displayed in project member lists with inheritance notation. Pending membership requests should not appear in inheritance chains until they are approved.

Relevant logs and/or screenshots

The user appears in project member lists with inheritance notation despite having a pending (not approved) group membership request. Testing confirms the user cannot actually make changes to the project.

Possible fixes

The issue likely exists in the UI display logic:

1. UI Display Logic (Most Likely)

The member list display logic may not properly filter pending requests when showing inheritance chains in the project members UI.

2. User#authorized_groups method

The authorized_groups method in app/models/user.rb (lines 1432-1450) constructs complex queries for inheritance but may not properly exclude pending members in display scenarios.

3. Members::MembersWithParents inheritance logic

In app/models/members/members/members_with_parents.rb, while members_from_self_and_ancestor_group_shares correctly filters requested_at: nil (line 90), there may be gaps in other inheritance paths used for display.

4. Project member list rendering

The frontend or backend logic that renders project member lists may not consistently apply the non_request scope when displaying inheritance information.

Investigation needed

1. Trace the inheritance resolution in member list display logic
2. Identify where pending members are included in UI queries but excluded from actual authorization
3. Ensure the non_request scope is consistently applied in member list display queries
4. Review frontend member list components for proper filtering

Environment

• GitLab version: 18.6.0
• Instance: GitLab.com (SaaS)