[Accounts] Support multiple linked org setups in GH

[aj-codecov]

Problem to Solve: In GH we don't do anything to support a GH enterprise org that has child orgs under it when billing in Codecov. This create potential for double billing and under billing if we aren't very careful with how we allocate seats.

Proposed Solution: Enable a new concept (an Enterprise) that can have child orgs that are managed from a billing and user management perspective under one plan and total list of members shared across the connected orgs.

View related designs >

### Tasks
- [x] Build the concept of an "enterprise" that has orgs as children
- [x] Map users to those orgs

### Platform
- [ ] https://github.com/codecov/engineering-team/issues/1711
- [ ] https://github.com/codecov/engineering-team/issues/1740
- [ ] https://github.com/codecov/engineering-team/issues/1993
- [ ] https://github.com/codecov/engineering-team/issues/1806
- [ ] https://github.com/codecov/engineering-team/issues/1808
- [ ] https://github.com/codecov/engineering-team/issues/1807

### Design tasks
- [x] Design exploration for Q3 planning
- [x] Discuss an alternative way to treat the 5 self-service customers without introducing a lot of work
- [x] Confirmed which plan to have the Account Model experience. Enterprise Cloud for Q3 7/11
- [ ] https://github.com/codecov/engineering-team/issues/2064
- [ ] https://github.com/codecov/engineering-team/issues/2063

[katia-sentry]

We are dropping Gitlab as a requirement for the first iteration of this work for Q2'24

[trent-codecov]

Proposed structure

erDiagram
    ACCOUNT }|..|{ USERS : "has and belongs to many"
    ACCOUNT ||..o{ ACCOUNT_SETTINGS: "has zero or many"
    ACCOUNT ||..|{ OWNERS_ORGS : "has one or many"
    USERS ||..|{ OWNERS : "has one or many"
    OWNERS }|..|{ OWNERS_ORGS : "has and belongs to many"
    USERS ||..o| SENTRY_USER : "has zero or one"
    USERS ||..o| OKTA_USER : "has zero or one"

Note that I added account_settings here. That is not a requirement for this KR but will be needed for OKTA. We can either add that here or on that KR.

Also note that owners and owners_orgs are the same table. I broke them out for clarity here .... just like they should be in the db but alas.

Everything but account and account_settings already exists in the above diagram.

Account - meta object representing a collection of users and gh/bb/gl organizations Owner - gh/bb/gl user User - meta object representing a user of the system Owner_org - gh/bb/gl organization Sentry_user - Sentry user information for a given Codecov user Okta_user - Okta user information for a given Codecov user

[Adal3n3]

Enterprise plan has unlimited public and private repo so as a customer, I probably only care about the numbers of my seats because I have a limited seats.

@trent-codecov @aj-codecov @ajay-sentry @katia-sentry Do you need design for this issue? If yes, in which area?

[Adal3n3]

@ajay-sentry @aj-codecov Can we have a status update on this issue?

[katia-sentry]

I think we can get a status update on this work from @thomasrockhu-codecov or @michelletran-codecov on the platform side?

[katia-sentry]

It's not clear if/where changes are needed in the UI to support the enterprise concept in our billing - @aj-codecov @ajay-sentry any idea?

[aj-codecov]

@katia-sentry @Adal3n3 Will update around UI work by EOD today

[michelletran-codecov]

@katia-sentry We're still deciding on the data models. It's not firm, but the draft for the models can be found in this: https://www.notion.so/sentry/Account-Modelling-27888fb38b06483c963e4b15c1889625?pvs=4

[Adal3n3]

Making a note here from my learning section with @michelletran-codecov

Background Codecov charges users based on the number of seats. If a user has 2 orgs, we sometimes charge the user twice because we are not able to detect that this user is from the same (enterprise) plan. The billing system is attached to the OWNERS(org) table, where an OWNER can be an ORG as well. Therefore, we can’t detect if an ORG/USER belongs to a plan.

Two problems:

1. Codecov could charge the same user multiple times if this user is duplicated across multiple ORGs within the same paid plan.
2. Contact the Codecov account team for a package deal. We charge them based on the number of seats they provide; this is usually contract-based pricing. We can’t detect if the users are from the same plan, resulting in overcharging or undercharging.

Proposed Solution:

1. Create an Account Model. This Account Model allows Codecov to bill accurately across multiple ORGs.
2. The Stripe billing system will need to migrate from the OWNERS(ORGS) table to the new ACCOUNTS table

@aj-codecov There is no Parent/Child org concept in this issue, can you update this issue name and the description to help us align? Thank you 🙏

[katia-sentry]

@Adal3n3 Do we need a UI for this?

[aj-codecov]

Linking recording of recent convo here: https://sentry.rewatch.com/video/jwd8sjej7fg24ny8-new-accounts-model-admin-discussion-june-12-2024

The tl:dw; is that we're looking to make some small UI tweaks to inform an end user of a pro or enterprise cloud plan that their plan is tied to multiple orgs and shares seats across multiple orgs.

[nora-codecov]

Planned Structure

Further details about Okta https://www.notion.so/sentry/Account-Modelling-27888fb38b06483c963e4b15c1889625?pvs=4 Further details about billing https://www.notion.so/sentry/Codecov-Billing-67bc332086cb45babdc0da513bdfb566?pvs=4

[Adal3n3]

AJ and I had a sync last Friday, and here are the discussion note from 6/18

• Initially, we wanted to display the number of orgs on the manage plan page, but we can’t provide a place to view the list of linked orgs with access. If we only provide the number of orgs without a link, this will leave customers wondering where is the list. Is the number accurate? how can I check it? If we provide a raw file to download, we need to make sure the file is always up to date otherwise not useful, also this solution might cause too much manual work for the support team. So we decided not to make any changes on the UI in Q2.
• For Q2, we will focus on the Enterprise plan implementation only for the new accounts model.
• The accounts model should not apply to the Pro plan without the new admin flow and the UI updates.
• Now, we will do some design exploration for Q3.
• Customers need an Admin-view that has access to the new accounts page in the UI.
• Only Admins will have the access to the new account page allowing them to view the list of organizations linked to the account/plan.
• Admins will need to know the number of seats for each org so they can contact support to reallocate seats from one org to another. 
• They will also need to know the total number of orgs linked to the plan.
• Admins won’t be able to remove or add organizations. They will need to contact support for these actions.
• This design applies to both Pro and Enterprise plan customers.

[Adal3n3]

Here's the Q3 design exploration on Figma: link

Here's the discussion note from @aj-codecov and me on 6/21:

• The account table that show the list of linked orgs is located in the container on the Plan page. In the future, we can explore a new sub-tab or two-column layout for the account table.
• Add an info banner to remind admins to add seats when 90% are used.
• Update the member page to indicate the total number of available seats and multi-orgs-plan info so admins knows this org is managed by what.
• These designs apply to Enterprise plan only.
• On 7/1 @heather-codecov @aj-codecov and I will try to see if we can find an alternative way to treat the 5 self-service customers without introducing a lot of work, like introducing Admin-role, Accounts-orgs, access permission, updating the plan flow, etc.

[Adal3n3]

Notion doc for Q3 planning: https://www.notion.so/sentry/Support-multiple-linked-orgs-WIP-bb12636b63654fe99a45017d66cddcff?pvs=4

[thomasrockhu-codecov]

@aj-codecov @Adal3n3 how do we feel about splitting off the Q3 tasks into a new issue? I worry that this one is going to be in too many different states (eng - merged but only the Q2 tasks, design - in progress for Q3 tasks)

[Adal3n3]

@thomasrockhu-codecov @aj-codecov I mentioned this before during the Application sprint meeting so I believe this project will have it's own issue(s) and row(s) in Q3.

[katia-sentry]

Removing applications team as there is no UI work for this in Q2