QRTLY COTERMS .COM: Create Static "Seats Currently in Use Members List" for GitLab.com (Frontend)

Notes:

1. The backend issue for this MVC found here: #216996 (closed)
2. This issue is an MVC of the desired implementation found here: #27074 (closed)

---

MVC Proposal

On the parent group billing page, beneath the current subscription table, create a list of members who tie to the Seats currently in use value.

This has to be under the api_billable_member_list feature flag.

In the table include:

1. Member Name (first, last)
2. Username
3. Email address - only display when the member has elected to display the email address publicly. (see example screenshot below) UPDATE: email address will not be included in this iteration but will be addressed in a follow-up iteration.
4. IP we should not serve up this information per legal
5. This information will only be accessible by members of the parent group with owner permissions

Rules

1. 20 members per page
2. Only display a member once if they are members of multiple subgroups/projects
3. Display only billable members. Exclude GitLab generated bots (Support Bot, Alert Bot), Ghost Users, and Users with Guest permissions if the namespace subscribes to the Gold plan.
4. Include members invited from shared groups as long as they meet the conditions in rule 2.
5. The data should be updated dynamically as changes to the members in the instance are made. If this is too draining, let's update once a day and include a hover text which states that the table is updated at xx:xx time daily (including the timezone).

Documentation

Would need to update:

• Groups docs, currently has nothing on Members list in general, only adding users to group

What does success look like, and how can we measure that?

• Group owners can match their subscription user count to the group members list via UI.

Additional information

Only display email if the user has elected to publicly display it:

ROI

• IACV
• Cost Reduction
• Sales Efficiency: $50k in first 90-days post implementation
• Other
• Support Efficiency

TODOs

• New route - set it up
• User count per page - agree on number (ATM 20 is the consensus - discussion here)
• Billings table uses daily snapshot data / Seats table uses live data - discussion here
  • Add explanatory text about this (consensus ATM on The table data is refreshed live. This contrasts with the billing table, which refreshes once per day. - discussion here)
• When the table is on the bottom of the billing page, it conditionally shows only if there are billable users. However, when the table is on its own page, it needs to always show up and just show an empty state if there are no users.(discussion here)
• Put the feature under the feature flag api_billable_member_list
• Tests
• MR that removes the feature flag
• Docs
• Open follow-ups
  • Add email
  • (?) Add endpoint for getting only the total number of seats, without getting any extra info in the payload (e.g. hasBillableMembers)