Investigation in !226612 uncovered larger issue with how we query for billed members. As the issue has a broader scope than initially identified, I'm adjusting the weight to 3️⃣ based on Fulfillment estimation table to reflect:

1. Architecture change required for new finder
2. Performance consideration for new billed member query with deduplication logic
3. Clear requirement with existing pattern in Group model, BilledUsersFinder, GroupMembersFinder, and MembersFinder

@karichards You're right, nice catch, we wouldn't want to lose any records. I just discovered another finder MembersFinder that handles a similar deduplication challenge that we could follow.

It uses a custom DISTINCT ON query that:

1. Deduplicates by (user_id, invite_email)
2. Uses ORDER BY to decide which row to keep per user (preferring ProjectMembers over GroupMembers)
3. Doesn't force a final sort order, so subsequent sorting (like last_joined or access_level_desc) would work

We could adapt this approach for BilledMembersFinder by creating a similar custom distinct_on_billed_members method that keeps the max access level and oldest join date, then lets Member.sort_by_attribute handle the requested sorting afterward. Wdyt?

is the suggestion to add member_access_level and member_joined_date to the response? I think the payload itself doesn't necessarily need new fields

@karichards Yes, that's my suggestion, but you're right that the payload doesn't need new fields. I suggested it thinking it might help clarify the sort order since the response currently doesn't return any member-specific data.

My thinking is that the fix is to sort the member records and then extract the users in that sorted order, WDYT?

For sure, that sounds like a good MVC, we can always add additional fields later if needed.

LGTM!

@vij Passing it off to you for maintainer review 😄

Since this MR is focused on event details coverage, I'd suggest leaving the code in and having a separate follow-up MR to specifically update the stub and test the correct user.

Having said that, I'm not strongly opinionated either way and it'd be fine if we remove it now, as long as we address it in a follow-up.

What does this MR do and why?

Add tests for audit event details to the group SCIM deprovisioning service specs.

Issue: #588829

References

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Great initiative, thanks for the context!

Why is this change being made?

This MR fixes broken links on the Communication page

Author and Reviewer Checklist

Please verify the check list and ensure to tick them off before the MR is merged.

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
• Assign reviewers for this MR to the correct
  • The when to get approval handbook section explains when DRI approval is required
  • The who can approve handbook section explains how to identify the DRI
  • If the MR does not require DRI approval, consider asking someone on your team, such as your manager.
  • The approver may merge the MR. If they approve but don't merge, you can merge.
• For transparency, share this MR with the audience that will be impacted.
  • Team: For changes that affect your direct team, share in your group Slack channel
  • Department: If the update affects your department, share the MR in your department Slack channel
  • Division: If the update affects your division, share the MR in your division Slack channel
  • Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR
    • For high-priority company-wide announcements work with the internal communications team to post the update in #company-fyi and align on a plan to circulate in additional channels like the "While You Were Iterating" Newsletter

Commits

• Fix broken links in communication

Sandra To (0b650c58) at 17 Mar 18:30

Async issue update

1. Summary: The billable members API endpoint has a larger underlying issue where it uses BilledUsersFinder to query users instead of members, preventing all member-specific sort options (access_level_asc, access_level_desc, last_joined, oldest_joined) from working. See more: !226612 (comment 3151751284)
   • Root cause: The endpoint uses BilledUsersFinder which calls User.sort_by_attribute instead of Member.sort_by_attribute
   • Existing partial solution: GroupMembersFinder uses distinct_on_user_with_max_access_level to remove duplicated users found, but it's designed for general member listing (ancestors, shared groups) rather than billing-specific filtering (banned users, guest billing rules)
   • Proposed solution: Created ::Members::BilledMembersFinder that extends the existing pattern from BilledUserFinder and uses scopes from Group model to cover both billed group and project members. See MR diff: !226612 (diffs)
   • Performance concerns: Reviewers flagged concerns about adding a new finder and its performance implications. See thread: !226612 (comment 3156356861)
   • Feedback needed: What is the recommended approach to fix this issue:
     • Should we extend on the existing GroupMembersFinder or BilledUserFinder?
     • Create a new BilledMembersFinder?
     • Are there any other approaches we can take while maintaining performance?
2. How confident are you that this will make it to the current milestone?
   • Not confident
   • Slightly confident
   • Very confident
3. Are there any opportunities to further break the issue or merge request into smaller pieces (if applicable)?
   • Yes, depending on recommended approach
   • No
4. Were expectations met from a previous update? If not, please explain why.
   • Yes
   • No, this is the first update.
5. Are the related issues up to date? Please link any missing issues in the epic that could be linked to this issue
   • Yes
   • No

cc @karichards

@abdwdd Will do, thanks! I just found GroupMembersFinder. Related to the other thread, this finder handles member deduplication using distinct_on_user_with_max_access_level. We should definitely review this with a domain expert to figure out the best approach.

Great catch! We can use the distinct_on_user_with_max_access_level scope from the Member model, which removes duplicates and selects the highest access level. It also uses the oldest join date as a tie-breaker when access levels are equal.

      ]).distinct_on_user_with_max_access_level(group)

For sure, I'd be happy to document it! I've created a new BilledMembersFinder that properly handles member sort orders. I tested it locally and confirmed it works correctly for both access level and join date sorting.

Since you mentioned this may need rescoping, should I focus on documenting the findings for now, or would it be helpful to complete the remaining work:

• Add specs to cover the new finder
• Update the API response to include member-specific fields

Happy to keep going with the remaining work if you estimate it to be low-effort, or we can save it for later, whatever works best!

Yes, you're correct, thanks for catching that! Some more updates in another open thread: !226612 (comment 3152998038)

@abdwdd @karichards Thank you for the feedback!

By joined, I understand that the users should be sorted by the date of joining the group

This is how I understand it as well, based on the description of these attributes in the API reference.

That makes sense, you're absolutely right! I referenced Member.sort_by_attribute, and after checking the Member model more closely, I can see that the logic wouldn't be transferrable to User since  Member.created_at (join date) is different from  User.created_at (account creation date). Thank you both for pointing this out!

we're not joining on the members table and sorting

I think that join would be complex as it would require knowing about the specific group and its hierarchy to find relevant member records, plus handling cases where a user has multiple membership paths 🤔

Good news! It looks like the joins and some complex queries are already handled in the Group model for finding group projects and group/project members. We can reuse it! (see BilledMembersFinder below). See ee/app/models/ee/group.rb for existing implementation.

I'm surprised that the endpoint uses BilledUsersFinder to query for the billable members rather than a BilledMembersFinder or the like that uses sorting options for members. It looks like we don't have something like this at the moment.

Great suggestion! Following the pattern in BilledUsersFinder and using the queries in the Group model, I created ::Members::BilledMembersFinder which properly accesses Members.sort_by_attribute and fixes the sorting for access_level_asc, access_level_desc , last_joined, and oldest_joined . Note: I had to place it in the Members module because rubocop requires new finders to be within a bounded context namespace. Please take a look: !226612 (diffs)

We can update the endpoint to use the new finder, then remove the new scopes added to Users , no database changes needed!

Since the endpoint is public-facing, I think the safest approach would be to continue returning users in the API response but add member_access_level and member_joined_date fields to provide the missing member data while maintaining backward compatibility. What do you think of this approach? Open to suggestions 🙂

Sandra To (32fb3850) at 12 Mar 04:13