[UserCap BE]: Billable members without pending members
Why are we doing this work
In &4315, we introduced a User Cap
setting for self-managed admins to prevent accidental user overages, now we are doing the same for SaaS group owners to prevent accidental overages.
This work will be broken down into the following backend steps:
- Add user cap setting
- Adding/inviting members
- Notifications
- Member management
- Auto approval
- Approval Modal
- Group access modifications
- Group sharing
- UserCap availability
-
Billable members
👈🏽 we are here
For this issue, we should prevent members in a pending
/awaiting
state from being considered billable for a group.
Relevant links
- Discussion around this requirement: #332596 (comment 725450369)
Implementation plan
We should consider the use of a feature flag for this given it's implication on billing
Additional notes
- The
Member
class already defines anactive
scope which relates to theUser
state, not theMember
state, here, which may be confusing - This change will likely need involvement from the database team for discussion around query performance/plans
- We will also need to update the documentation around this area to be clear that pending/awaiting members are not billable. If it's not already there by the time this issue is worked on, we could add a new section to Groups for User Cap related docs
- We should consider the impact of this change on related classes such as
GitlabSubscription
with regards to the seat usage calculations
Edited by Vijay Hawoldar