giseldo/neodataset huggingface dataset:
Duplicate RatePlanCharges are created for ramp subscriptions in Zuora

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem
Duplicate `RatePlanCharges` are created in Zuora when we add different products to a ramp subscription. Since we use `RatePlanCharges` to show ramps in the subscription card design for ramp subscriptions, duplicate rows will be shown to the customer if we show these `RatePlanCharges` without filtering.  

**Currently implemented solution:** Filter out `RatePlanCharges` with `$0 TCV`. 

**Problem with current solution:** The check to filter out `$0 TCV` `RatePlanCharges` feels a bit flimsy and could lead to filtering out of valid `RatePlanCharges` if we do have products in ramp subscriptions in the future which are sold at $0.  
Details in this [thread](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5654#note_1264773352).

Video recording of problem:
![video1463154554](/uploads/79cd34301add07ca84820f4edef96aa7/video1463154554.mp4)

### Proposal
Keep the current `$0 TCV` check for %15.9 release and [research for more robust solutions going forward](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5654#note_1265047333). Get EntApps and Zuora involved in this if needed.

### Updated Proposal
For %"15.10" as per this suggestion from `@tgolubeva`, we could filter out the duplicate `RatePlanCharges` based on the condition that `EffectiveEndDate` is same as `EffectiveStartDate`.

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Removal of the ResellerNotificationService

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem

Once we have completed the work in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5204, all the notifications covered in the [`LicenseNotificationService`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/app/services/license_notification_service.rb) will have a voucher email sent to the SFDC address and a background copy sent to the resellers.

This service currently reports `Invoice for reseller not found` when the subscription does not have an invoice at the time of the notification. However, this not uncommon as reseller managed subscriptions can be billed after provisioning. 

As a result we get a few errors reported each day (see [this example](https://console.cloud.google.com/logs/query;query=%22RuntimeError:%20Invoice%20for%20reseller%20not%20found%22%0Aseverity%3DERROR;timeRange=P1D;cursorTimestamp=2023-02-01T17:13:40.615Z?project=gitlab-subscriptions-prod) at the time of writing) which get reported by the [`ZuoraCallbackWorker`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/2fa4bfb8cb2e472d08a546d271002a433589cdb4/app/workers/zuora_callback_worker.rb#L69) too ([example](https://console.cloud.google.com/logs/query;query=%22Error%20sending%20license%20notification%22%0Aseverity%3DERROR;timeRange=P1D;cursorTimestamp=2023-02-01T17:13:40.619Z?project=gitlab-subscriptions-prod)). This generates a lot of noise to our logs.  


### Proposal

Since the [`ResellerNotificationService`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/app/services/reseller_notification_service.rb) only usage is happening in the `LicenseNotificationService` and it's mostly being noisy at this point, we could remove the service and its usage from the codebase once we validate that resellers are getting the expected vouchers.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Reuse confirmation email after CDot admin update

## Problem

There are currently no guardrails in place when changing the email of a CDot account through the [CDot admin panel](https://customers.staging.gitlab.com/admin).

This is a risk because human error can occur, and an incorrect email can be used for a CDot account. This could lead to the wrong person gaining access to another CDot account and receiving all of its email notifications containing sensitive information (anything related to subscriptions).

FYI: Related [RCA](https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/1026)

## Proposal

We reuse the [confirmation email](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/vs%2Fupgrade-rails-admin/app/views/customers/mailer/confirmation_instructions.html.erb) that is sent when a CDot account email address is changed. The same email should be sent to customers when a CDot email address is updated via the [admin panel](https://customers.staging.gitlab.com/admin).

Additionally, we reuse the email to [inform the old email address owner](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/app/views/devise/mailer/email_changed.text.erb) about the change.

## Result

Affected CDot customers are notified of the email change and must confirm the new email address to access their CDot account. Even if the wrong email is used, the affected CDot customer will be notified.

Story points: 2.0
Add sales team as stakeholder for review

### Problem

The [Sales Systems team](https://about.gitlab.com/handbook/sales/field-operations/sales-systems/) is responsible for sales systems, notably [Salesforce](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/6b2e3dd5f4ebcfd8f295cc46b1e8474093f276ea/doc/salesforce/README.md) at GitLab.  Salesforce is a business critical Order-to-Cash system that is linked with CustomersDot.  SFDC Lead, oportunity, account creation and more can be triggered from CDot.  Changes to SFDC are synced to Zuora, which then makes it way to CDot by way of callouts.

Given this important interactivity between systems, we need to make sure changes to CDot don't break this interaction and cause outages or data loss.  To prevent outages, Fulfillment engineers should request a review from a Sales system team member if an MR contains changes that impact Salesforce.  

Currently, we have a checklist item in [our default MR template](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/.gitlab/merge_request_templates/Default.md#conformity) to remind engineers to request a review.  It can be easy to miss this checklist item and forget to request the review.

### Proposal

It looks like Danger was improved as part of https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/738+ to make suggestions for sales systems reviewers if the MR contains the `Affects Salesforce` label. You can find the related [Dangerfile here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/63835bcc3d0e7e6b634ced392f4fa6f5892f2eed/danger/business_system_review_roulette/Dangerfile).

We might be able to take this a step further by automatically adding the `Affects Salesforce` label, prompting a Sales System review.  For instance, this Dangerfile could check the changed files for any filenames containing the word "salesforce" and append the MR label.

Story points: 2.0
Add EntApps team as stakeholder for review

### Problem

The [Enterprise Applications team](https://about.gitlab.com/handbook/business-technology/enterprise-applications/) is responsible for all of GitLab's finance systems and Enterprise Applications integrations.  The most important of these systems is Zuora.  In Fulfillment, we work with Zuora Billing quite often as it is a [critical Order-2-Cash system](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/83a95b12efd44ce00ea03d26e3c953a310d8228f/doc/architecture/data_architecture.md#L10).

CustomersDot directly interacts with Zuora Billing in many ways like Subscription creation and Billing Account management.  Changes in CustomersDot around Zuora Billing logic could impact this integration, leading to downtime or data loss. To prevent this, Fulfillment engineers should request a review from a Enterprise Apps member (Zuora architect) if an MR contains changes to Zuora-related logic.  It's easy to forget to request a review, even with [a checklist item to the MR template](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/.gitlab/merge_request_templates/Default.md#conformity).

### Proposal

Similar to https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5616 or https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5618, let's look at using Danger to automate requesting a review from `@gitlab-com/business-technology/enterprise-apps/zuora-architects` if the MR contains Zuora-related logic changes.

Detecting which changes are Zuora-related is the key detail for this issue.  It might be something as simple as looking for files that include the word "zuora" but the might be too aggressive.  We could consider specific files or directories as well (`lib/zuora`, `app/services/zuora`, `app/workers/zuora*`, etc).

Story points: 2.0
Add data team as stakeholder for review

### Problem

The Data team is responsible for [pipelines that export the CDot database](https://about.gitlab.com/handbook/business-technology/data-team/platform/pipelines/#gitlab-customer-dot-database) for [Snowflake](https://about.gitlab.com/handbook/business-technology/data-team/platform/snowflake/).  Some database migrations in CustomersDot could impact this pipeline, leading to downtime. To prevent outages, Fulfillment engineers should request a review from a Data team member if an MR contains database changes.  It's easy to forget to request a review, even if we add a checklist item to the MR template.

### Proposal

Let's update Danger in CDot to prompt MR authors to request reviews from the Data team when the MR contains database changes.  The Danger is already configured prompt authors to get reviews from a Database reviewer and maintainer for database changes. You can find this configured [in `danger/database/Dangerfile`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/a370c2b4b1a4fec50a6be2291c7b0ec7c73e0cd7/danger/database/Dangerfile).

Story points: 3.0
Marketplace::CreateSubscriptionService do not send to Sentry for most validation failures

Per [slack discussion](https://gitlab.slack.com/archives/CL7SX4N86/p1674803657451299), many validation failures are noisy. 

<details><summary>Snapshot of the slack discussion</summary>
![image](/uploads/837cae5d2dacd7f5fa424bbfc419b0d2/image.png)
</details>

### Proposal

It is suggested for Marketplace::CreateSubscriptionService do not send to Sentry for most validation failures. 
- Only `log_error` for the really concerning failures. 
- For most of them validation failures, `log_warn` is enough.
   - We can search from the log if we want to do some analysis in the future.
  

### Result

### Next steps (if any)

### How will we measure success?

Story points: 1.0
[Spike] GitLab Dedicated Automated Provisioning Scoping

## Background
~"group::provision" is planning to automate the provisioning of GitLab Dedicated, which today is a fully manual process done with legacy licenses created by the Support team.

Details about current process & LOE estimate can be found here: https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/754

## Outcome of this Issue 
Review and breakdown the work needed to successfully setup provisioning for GitLab Dedicated. Specifically, we should:
* Receive the Zuora callout for all Dedicated products
* Generate an activation code for the correct seat count
* Display correct product details in Customers Dot

## Result: Issues Created
1. https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/6148+ - this issue should be able to address the MVC for provisioning of GitLab Dedicated, including generation of an activation code

Follow-ups:
1. https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/6269+ - this will allow custom Dedicated-specific content for customers
1. https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/6270+ - this will ensure we track GitLab Dedicated provisioning accurately as part of the ~"Provision Tracking System" 

---
**Support Priority Score:** (-, -, -, -, -, -, -, -, -, -, -) => 13

Story points: 2.0
[Backfill] Create activation codes for any remaining SM subscriptions without one

## Background
https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/782+ defines the process for customers to activate with Cloud Licensing mid-term if they already have an active legacy license subscription. Previously, for most customers, a Support ticket was required to move to Cloud Licensing. With the changes made to backfill `TurnOnCloudLicensing` = `null`, plus the work done in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5602 to begin creating codes for all SM subscriptions (even `TurnOnCloudLicensing` = `No`), we have significantly increased availability for customers to self-activate with Cloud Licensing.

The last step for all customers to be able to self-activate will be this issue, that will backfill all remaining subscriptions missing an activation code.


## Proposal
Backfill any active SM subscriptions missing an activation code.

We can reuse [the code](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/1ba32625852d05582e328e3b2f46e4df7e335d2f/lib/tasks/data_maintenance/pre_strict_cloud_license/backfill_cloud_activations.rake) introduced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4892 and make some modifications to support the different context. The code was left in place with this change in mind. It can be removed afterwards.

## Result
ALL Self-Managed customers will have a cloud license activation code available for download visible in the Customer Portal, allowing for mid-term activations of cloud licensing without the need for a support ticket.

Story points: 1.0
Update browserslist dependency

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem
Whenever you serve the CDot app, it complains about the `browserslist` being out of date. 
### Proposal
Run `npx browserslist@latest --update-db` to update the list with the latest versions.
### Result
No error is displayed
### Next steps (if any)

### How will we measure success?

Story points: 1.0
Hide ramp details for products which do not ramp

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem
We should hide details section in the new card design if any product in the subscription does not ramp. See this [comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6327#note_1251545677) for more details.  
Discussion [thread](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3916/designs/Ramped_subscriptions__MVC.png#note_1204057072) in Figma.  

**Note:** Need to check if we should show the details section for CI minutes as it shows the purchase date which is not shown in the card header.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Customer link on License Seat Link list admin page is not correct

### Problem

`@tom.houston` in Support [reported a problem](https://gitlab.slack.com/archives/CMJ8JR0RH/p1674573876782299) with the link to the Customer from the License Seat Links list page in Rails Admin.  

> When going to the List of [License seat links page](https://customers.gitlab.com/admin/license_seat_link) and selecting any customer on the list it directs me to the Site Administration page with the error Model 'RailsAdmin::Customer' could not be found at the top of the page.  I have a customer who has multiple mirrored environments for their GitLab self-managed setup and they're trying to activate cloud licensing on them.  This has resulted in 200 duplicate licenses and I'm trying to determine which if any of the licenses actually completed the activation process.  I was directed to the List of License seat links page to help with that only to find it doesn't work for me.

As it turns out, there is a bug in the construction of the customer link on this page.

### Proposal

Fix the construction of the customer link.  It should look something like `https://customers.gitlab.com/admin/customer/360255` instead of `https://customers.gitlab.com/admin/RailsAdmin::Customer/360255`.

Story points: 1.0
Mutation to add seats to a subscription

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem

We use the `subscription#update` API to add new seats to an existing subscription. In this issue, we create a GraphQL mutation to perform this operation.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

- Create a mutation namespace `subscriptions` in `app/graphql/mutations` if it does not already exist
- Create a mutation class `AddSeats` in the namespace

#### Step 1: Define the following arguments:

|Argument|Type|Required?|
|---|---|---|
|`subscription_number`|`GraphQL::Types::String`|Yes|
|`quantity`|`GraphQL::Types::Int`|Yes|
|`payment_method_id`|`GraphQL::Types::String`|No (`payment_method_id` is not included during preview) |
|`preview`|`GraphQL::Types::Boolean`|No (defaults to `false`)|

#### Step 2: Tweaks to Order related services

- [Define new custom action](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/90561f906dfcf42afd25a086d5ea68bd183a733f/app/services/zuora/orders/actions/mapping.rb#L7): `add_seats`. Map the action to `UpdateProduct`. We currently [combine](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/90561f906dfcf42afd25a086d5ea68bd183a733f/app/services/zuora/orders/amendment/action_types_generator.rb#L95) adding of seats independently with adding of seats during renewal, reconciliation. This will give us an opportunity to decouple the logic [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/90561f906dfcf42afd25a086d5ea68bd183a733f/app/services/zuora/orders/actions/param_constructor/update_product.rb#L34).
- Define the new custom action `add_seats` in `ParamConstructor::UpdateProduct`. 
  - Set `product` to `main_product`
  - `quantity` to `new_quantity` + existing quantity of `main_product`
  - `contract_effective_date` as current date

#### Step 3: Define `resolve` method:

- Perform [seat max validation](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/90561f906dfcf42afd25a086d5ea68bd183a733f/app/services/zuora/orders/amendment/action_types_validator.rb#L61)
- Invoke `OrderManagerService`: 

  ```
    Zuora::Orders::OrderManagerService.new(customer: customer, order_action_types: action_types, params: params, subscription: subscription)
  ```

  - `action_types` = `add_seats`
  - `params` should contain `id` (subscription number), `quantity`, `payment_method_id`. May contain `preview`

### Result

The mutation should add the seats specified to the main product of the subscription.

### Next steps (if any)

### How will we measure success?

Story points: 3.0
Add Sync Billing Account action to Admin

### Problem

When enabling the new CustomersDot Billing Account architecture we need to make sure we continue to support all the actions used to manage Customer associations with Zuora Billing Accounts via the Admin.

We will document the updated procedures via https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5434+

Updating the `salesforce_account_id` related to a CustomersDot Billing Account is not possible ATM given we don't allow the editing of `BillingAccount` records via the Admin.

We don't want to allow setting **any** value for the `salesforce_account_id` value at this given we want to keep Zuora as the SSoT for it via the `crm_id` in the Zuora Billing Account.

We want to implement a Sync action for a CDot Billing Account via the Admin that will allow us to refresh its `name` and `salesforce_account_id` to those in Zuora.

:heavy_plus_sign: See: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5434#note_1248078612 for more context.

### Proposal

Implement the "Sync Billing Account" action via CustomersDot Admin.

One click action with confirmation on successful sync.

### Acceptance criteria

A CustomersDot Billing Account can be synced with Zuora via the CDot Admin.

---

Note this might share some logic with https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5574

Story points: 3.0
Add Create Billing Account action to Admin

### Problem

When enabling the new CustomersDot Billing Account architecture we need to make sure we continue to support all the actions used to manage Customer associations with Zuora Billing Accounts via the Admin.

We will document the updated procedures via https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5434+

Associating a CustomersDot user to a Zuora Billing Account that is not represented via a CustomersDot Billing Account is not possible ATM given we don't allow the creation of `BillingAccount` records via the Admin (just `BillingAccountMembership`s)

:heavy_plus_sign: See: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5434#note_1248078612 for more context.

### Proposal

Implement the "Create Billing Account" action via CustomersDot Admin.

Inputs for the new form: `zuora_account_id`

When the user enters a `zuora_account_id` and submits the `new` form:
- If the id is already associated to a CDot account display the error in the form.
- If the id is not associated to a CDot account:
  - Fetch the Zuora Billing Account for the provided id
  - Create the CDot Billing Account using the info in the Zuora one for the other fields: name, salesforce_account_id.

### Result

A CustomersDot user can be added as a member to any existing Zuora Billing Account.

### Acceptance criteria
- When a Zuora Billing Account is represented in CDot via a Billing Account we can add a membership for an existing customer via the Admin.
- When a Zuora Billing Account is not represented in CDot via a Billing Account we can create a CDot Billing Account for it **and** add a membership for an existing customer via the Admin.

Story points: 3.0