[LOE] Multiple billing account managers

Problem

This issue is to estimate high level of efforts to develop Enable customers to self-service manage multipl... (&10495).

Related designs: #4974 (closed)

Result

A list of steps that we need to do to develop the feature with high level weights

Iteration Weight
Invite billing account manager that already exists as a User in the Customers Portal ~54
Invite billing account manager that does not yet exist as a User in the Customers Portal ~25

Iteration 1: Invite billing account manager that already exists as a User in the Customers Portal.

List of steps
  1. frontend
    1. Add invite button: 1
    2. Add invite modal with text for existing customers and superficial regex email address validation (we might be able to re-use URI::MailTo::EMAIL_REGEXP on the frontend) and success message, e.g. "If the user exists in our system, they will receive an invite to become a billing account manager of your account": 3
    3. Add remove button (disabled when email of billing account manager match sold_to or bill_to contacts): 2
    4. Add remove modal: 2
    5. Add instrumentation: 2
    6. Total weight: 10
  2. backend
    1. Add feature flag: 1
    2. Implement error if customer was not found: 1
    3. Implement existing user invite mailer upon invite: 1
    4. Add a new mutation (or update the Mutations::BillingAccounts::Update) to accept billing account manager email to add them through billing_account_memberships: 2
    5. Add a new mutation (or reuse the above) to accept billing account manager email and remove them through billing_account_memberships: 2
    6. Prevent removal of billing account manager that are sold_to or bill_to contacts in the BillingAccountContacts::UpdateService using billing_account.sold_to and billing_account.bill_to: 1
    7. Prevent adding a customer who is already a billing account manager of a different account through sold_to_contact? and bill_to_contact? from each customer.billing_account_contacts: 2
    8. Handle if a custom sold_to or bill_to contact is added with the same email address as a billing account manager, and vice versa: 5
    9. There are three places (as of writing) that use some form of billing_account.customers.first. These needs to be updated and could vary in terms of difficulty:
      1. RailsAdmin::CreateCloudActivationService: 3
      2. Order model: 8
      3. CustomerFinder: 8
    10. Roll out feature flag: 1
    11. Total weight: 35

Using a buffer of 20%, we land at (10+35)*1.2 = ~54

Iteration 2: Invite billing account manager that does not yet exist as a User in the Customers Portal.

List of steps
  1. frontend
    1. Update messaging for the invite modal: 1
    2. Re-implement sign-up flow with hidden/prefilled email address field for invited billing account managers in gitlab.com: 3
    3. Total weight: 4
  2. backend
    1. Add invited state to customer model for new customers (we can probably re-use the existing unconfirmed_email and mark_as_confirmed), only sync to Zuora upon sign up: 3
    2. Implement new user invite mailers upon invite: 1
    3. Implement customer email address validation: 2
    4. Implement customers.gitlab.com sign-up (REST) flow for invited billing account managers (with forced redirect from customers.gitlab.com to link gitlab.com account): 3
    5. Implement gitlab.com redirect back to customers.gitlab.com after registering: 3
    6. Ensure uniqueness of customer email addresses (might require a backfill task): 5
    7. Total weight: 17

Using a buffer of 20%, we land at (4+17)*1.2 = ~25

Assumptions

  1. Billing account managers can already manage existing subscriptions to the required state. Any additional needs will require extra work.
  2. Billing account managers can already to purchase new subscriptions for the billing account to the required state. Any additional needs will require extra work.
  3. For iteration 2, it is assumed that the billing account manager is confirmed as soon as they have entered details in customers.gitlab.com or signed in with gitlab.com SSO.
  4. For both iterations, we assume to only use the Customer model for billing account managers as we currently do, and leave the Contact model for custom sold_to or bill_to contacts. As an alternative, it could be considered to re-use the Contact model for invites and then promote them to a Customer model, but it might also make things messy in terms of how the Contact model was intended, though there is conflicting documentation on this.
  5. The above proposes (superficial) validating of email address on the backend equal to how we do it for custom sold_to or bill_to contacts. This should be enough for now, but this following issue will become more relevant as users might add email addresses that are accepted by this regex, but not Zuora: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/8273+.
  6. We are not implementing a way for the invitee decline the invitation.
  7. We won't be able to show a toast after invitation of billing account manager is invited as we require backend validation of the email through a REST endpoint.
  8. We can ignore customer.billing_accounts.first entries for now, as we still expect one billing account per customer (but not the other way around).
Edited by Tatyana Golubeva