giseldo/neodataset huggingface dataset:
Add Upgrade subscription specific tracking

### Problem

Currently we are tracking clicks on subscription card buttons. This shows a general interest on features but doesn't reflect that user wants to actually do this action.

### Proposal

Update the existing tracking for subscription card buttons and add tracking to the actual pages.

Attention: some tracking **is already implemented**, we would just need to update the event labels & actions.

#### Upgrade subscription

For all the tracking events set `event_label` as `upgrade_subscription_sm` / `upgrade_subscription_saas`

| FE/BE | Page | Description | Event category | Event action |
| ------ | ------ | ------ |  ------ | ------ |
|FE| `/subscriptions/` | ![Screenshot_2022-11-15_at_21.47.33](/uploads/d9ab9aba855fb2965bb4b62115a4cb7c/Screenshot_2022-11-15_at_21.47.33.png) <br> User clicks `Upgrade plan` button <br>  | Webstore | `click_card` |
|FE| `subscriptions/A-S000XXX/upgrade/new` | ![Screenshot_2022-11-15_at_21.48.54](/uploads/b3acb618f4748398f2c2460abbf8c648/Screenshot_2022-11-15_at_21.48.54.png) <br> User clicks `Upgrade subscription` button <br>  | Webstore | `click_upgrade` |
|BE| - | Transaction is successful  | SubscriptionUpgradesController | `transaction_successful` |
|BE| - | Transaction has failed  | SubscriptionUpgradesController | `transaction_failed` |

### Next steps (if any)

After the issue is done please let `@nraisinghani` know because we need to update the values in the related dashboard.

Story points: 2.0
Add Seats addition specific tracking

### Problem

Currently we are tracking clicks on subscription card buttons. This shows a general interest on features but doesn't reflect that user wants to actually do this action.

### Proposal

Update the existing tracking for subscription card buttons and add tracking to the actual pages.

Attention: some tracking **is already implemented**, we would just need to update the event labels & actions.

#### Add seats

For all the tracking events set `event_label` as `add_seats_sm` / `add_seats_saas`

| FE/BE | Page | Description | Event category | Event action |
| ------ | ------ | ------ |  ------ | ------ |
|FE| `/subscriptions/` | ![Screenshot_2022-11-10_at_17.09.54](/uploads/0a7e4ecc4875f685dfa4ff1ba4388685/Screenshot_2022-11-10_at_17.09.54.png) <br> User clicks `Add seats` button <br>  | Webstore | `click_card` |
|FE| `/subscriptions/A-S000XXX/edit?transaction=extra_seats` | ![Screenshot_2022-11-10_at_13.49.05](/uploads/1d1c60f4c4ffb67150ed5594a089f7dc/Screenshot_2022-11-10_at_13.49.05.png) <br> User clicks `Purchase seats` button <br>  | Webstore | `click_purchase_seats ` |
|BE| - | Transaction is successful  | SubscriptionsController | `transaction_successful` |
|BE| - | Transaction has failed  | SubscriptionsController | `transaction_failed` |

### Next steps (if any)

After the issue is done please let `@nraisinghani` know because we need to update the values in the related dashboard.

Story points: 2.0
Add Renew subscription specific tracking

### Problem

Currently we are tracking clicks on subscription card buttons. This shows a general interest on features but doesn't reflect that user wants to actually do this action.

### Proposal

Update the existing tracking for subscription card buttons and add tracking to the actual pages.

Attention: some tracking **is already implemented**, we would just need to update the event labels & actions.

#### Renew subscription

For all the tracking events set `event_label` as `renew_subscription_sm` / `renew_subscription_saas`

| FE/BE | Page | Description | Event category | Event action |
| ------ | ------ | ------ |  ------ | ------ |
|FE| `/subscriptions/` | ![Screenshot_2022-11-15_at_22.01.05](/uploads/6bc6932c2dadfdad86e4f4a1c3b2e56e/Screenshot_2022-11-15_at_22.01.05.png) <br> User clicks `Renew` button <br>  | Webstore | `click_card` |
|FE| `subscriptions/A-S000XXX/renew` | ![Screenshot_2022-11-15_at_22.00.21](/uploads/55ed2e88661428ed5f8351bb83340bba/Screenshot_2022-11-15_at_22.00.21.png) <br> User clicks `Renew subscription` button <br>  | Webstore | `click_renew` |
|BE| - | Transaction is successful  | SubscriptionsController | `transaction_successful` |
|BE| - | Transaction has failed  | SubscriptionsController | `transaction_failed` |

### Next steps (if any)

After the issue is done please let `@nraisinghani` know because we need to update the values in the related dashboard.

Story points: 2.0
Add professional-services as productSubType in product presenter

<!-- 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 need a new type of [`productSubType`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/cb55ed711546c9e13306bc7333f683265a33ab70/app/presenters/product_presenter.rb#L41-51) in `product_presenter.rb` to identify professional services products. This is needed to [display professional services products](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5665/) in the new ramps subscriptions card in Customers Portal.

### Proposal
Add new `productSubType` to identify professional services.

<!-- 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
Follow-up from "Admin: Add ability to create Billing Account"

The following discussion from !6500 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6500#note_1280463491):  (+3 comments)

    > **Thought (non-blocking):** This approach totally works, but it's unfortunate that ActiveAdmin doesn't allow it to be more extensible without duplicating so much code. I'm curious if we could avoid the duplication if we used a virtual attribute and extract some of the custom logic into the model.  We've done similar things for Customer admin before ([example](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/c51a1cff53972ad740ac8cbb021188efd109f0ab/app/models/customer.rb#L75)).  That solution isn't elegant either but might avoid duplicating the boilerplate.
    > 
    > Just a thought, and definitely could be considered in a follow-up, if you think it's worth it.

Story points: 2.0
Admin UI colour contrast is not high enough

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label in relevant trackers:

- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=bug
- https://gitlab.com/gitlab-org/customers-gitlab-com/issues?label_name%5B%5D=bug

and verify the issue you're about to submit isn't a duplicate.

Do not include confidential information!
--->

# Bug

## Summary

Many of the team members who use the admin part of CustomersDot are having difficulty using the new UI.

## Steps to reproduce

1. Take a screenshot and change it to black and white.
1. Or, check the colour contrast of the colours.

Example:

![image](/uploads/209a7ca4dca6be72f1f1967af54c0443/image.png)

The inactive menu items are 2.63:1 colour contrast ratio.

## What is the current *bug* behavior?

It's difficult to read the text. Even more so for someone who is partially or fully colour blind.

It also goes against our guidelines, and legislation in most countries.

## What is the expected *correct* behavior?

Colours should follow Pajamas: https://design.gitlab.com/product-foundations/color

including the colour contrast guideline: https://design.gitlab.com/product-foundations/color#accessibility

Story points: 1.0
Check for new occurrences of BillingAccounts without salesforce_account_id

### Background

In https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5695, we introduced a rake task to set `salesforce_account_id` for any BillingAccounts where it was missing.  After running this in production, we found that 70 records were still has `nil` for a `salesforce_account_id` value. 

### Proposal

Let's check back about a month after the rake task mentioned above was run, so around 2023-03-10, to see if there are any new occurrences of BillingAccounts without `salesforce_account_id`.  We could also run the rake task again to see if any of the 70 accounts could now be updated.

If there are new occurrences, we might have a larger issue that needs to be addressed.

Story points: 1.0
Ramps UAT: Provision Testing in Staging

## Summary
The EntApps team is conducting end-to-end UAT of Zuora Ramps prior to implementation (expected Feb 1, 2023). This issue will be used to track UAT efforts of ~"group::provision" to validate all test cases sent over as part of this effort are provisioning properly. Latest planned Fulfillment UAT is planned for 2023.03.21 to 2023.03.23.

More details can be found in the EntApps related issue: https://gitlab.com/gitlab-com/business-technology/enterprise-apps/financeops/finance-systems/-/issues/1051

## Test Cases
[Test Scripts/Use Cases](https://docs.google.com/spreadsheets/d/1xmdJ6ToiCyFNtqjrNPvwcGR7gCvkskjLnZXwAzEMT40/edit#gid=0)

* Fulfillment will be using the master UAT tab to validate Ramp use cases only, which will be sent over by Deal Desk/Billing teams.
* Testing will be completed in the staging environment.


## Result
Sign-off from ~"group::provision" that all use cases work properly in CustomersDot and we are comfortable with proceeding with production deployment - _to be provided via [checkbox](https://gitlab.com/groups/gitlab-com/business-technology/enterprise-apps/-/epics/478#testing-signoff)_

Story points: 3.0
Verify subscriptions created during UAT of ramps subscriptions

<!-- 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
Based on this [suggestion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5384#note_1278260308), we could verify the subscriptions that get created in staging as a part of the [EntApp UAT](https://docs.google.com/spreadsheets/d/1xmdJ6ToiCyFNtqjrNPvwcGR7gCvkskjLnZXwAzEMT40/edit#gid=691079497).

### 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
Unable to find subscription in CreateOrderService

# Bug

## Summary

`ZuoraCallbackWorker` calls `CreateOrderService`, but sometimes that would fail and raise "Unable to find subscription" error. Since order can not be obtained, the provisioning will be skipped.

## What is the current *bug* behavior?

* SaaS provision does not occur
* renewal introduction email not sent

## What is the expected *correct* behavior?

`CreateOrderService` can find the subscription and order, and provision can occur.

## Relevant logs and/or screenshots

https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/3869825/events/1d3126b1dfeb4cd483e466887eb4fa08/

```
RuntimeError: Error when processing subscription: A-S00039151. Unable to find subscription.
  app/services/create_order_service.rb:49:in `load_subscription'
    raise "Error when processing subscription: #{params[:subscription_name]}. #{extra_error}"
  app/services/create_order_service.rb:17:in `execute'
    load_subscription
  app/workers/zuora_callout/base_worker.rb:72:in `create_order'
    .execute(subscription_name: subscription.name, amendment_types: amendment_types)
  app/workers/zuora_callback_worker.rb:40:in `perform'
    result = create_order
```

## Workarounds

N/A

## Reported examples

Sentry currently has 8 examples.

Story points: 5.0
Enhance SeatsUsagePresenter to validate subscription.main_product

From MR discussion https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6511#note_1278836726

In case of order.subscription does not have `main_product`, the SeatsUsagePresenter will be in some unexpected behaviour.

We could enhance the `SeatsUsagePresenter` to validate `subscription.main_product`. This could be a simple check in initializer:
```
  def initialize(order:, customer:, seat_link: nil)
    @order = order
    @seat_link = seat_link
    @customer = customer
    @subscription = @order.subscription_on(Date.current - 1.day) # or whatever we decided
    raise ArgumentError, 'Order has no subscription' unless subscription
    raise ArgumentError, 'Order subscription has no main_product' unless subscription.main_product

    @monthly_seat_digest_notification_cutoff = @order.monthly_seat_digest_notified_on || @subscription.term_start_date
  end
```


### Problem

### 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: 1.0
Add Grafana dashboard to show new MTTR indicator

### Proposal

This is the second issue listed in [this issue breakdown](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5582#issue-breakdown).

After being able [to provide new metrics](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5718) tracking when CustomersDot enters and leaves maintenance mode, we now need to update [the Runbooks project](https://gitlab.com/gitlab-com/runbooks) with new dashboards based on this new metric, on the Fulfillment Platform group page.

### Result

Dashboards showing the amount of time CustomersDot Production was in maintenance mode.

Story points: 3.0
Link to group button is shown for CI minutes, storage and expired ramp subscriptions

<!-- 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
`Link subscription to group` button is shown in scenarios below for which it should not be shown.

| Scenario | Screenshot |
| ------ | ------ |
|  CI minutes only subscription      | ![image](/uploads/a8f503e0c722fd6c34c096c44d174d8c/image.png)       |
|  Storage only subscription      | ![image](/uploads/b6ffa513231ab68ebd94b0f4a4b932d2/image.png)       |
| Expired subscription | ![image](/uploads/65824d2751c7864d04eab6073fb6dcfc/image.png) |

### Proposal
Add a condition to [`showLinkSubscription`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/a4eaa5d5e73a2e0da9d2d9802409c989e8f648a1/app/frontend/javascripts/subscription/components/subscription_v2/subscription_v2.vue#L119-119) to check for [`!hasExpired`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/a4eaa5d5e73a2e0da9d2d9802409c989e8f648a1/app/frontend/javascripts/subscription/components/subscription_v2/subscription_v2.vue#L124-124) and [`subscription.changeLinkedGroupPath`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/a4eaa5d5e73a2e0da9d2d9802409c989e8f648a1/app/frontend/javascripts/subscription/components/subscription_v2/subscription_v2.vue#L233-233) exists.
<!-- 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
Allow Prometheus collection of maintenance events

### Proposal

This is the first issue listed in [this issue breakdown](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5582#issue-breakdown).

[Our custom Prometheus Collector](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/main/lib/metrics/collector.rb) allows us to collect metrics related to duration of execution of requests (web and api) and Sidekiq jobs, which ultimately leads to the definition of error budgets for the Fulfillment team.

In order to create a new metric that would send amount of time CustomersDot was in maintenance mode:
1. [ ] [the `Metrics::Prometheus::EmitsMetrics` module](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/main/lib/metrics/prometheus/emits_metrics.rb) needs to be included in the HealthCheck cron jobs ([here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/main/app/jobs/health_check_cron/check_gitlab_job.rb) and [here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/main/app/jobs/health_check_cron/check_zuora_job.rb)) and [the maintenance rake task](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/main/lib/tasks/maintenance_mode.rake). Related methods such as `prometheus_collector` and `thread_data` will need to be implemented and tailored to jobs and the rake task.
2. [ ] we need to build upon the existing current Collector framework to create a new metric label.
3. [ ] finally, we'll have to capture maintenance events in the rake task and cron jobs.

### Architecture

```mermaid
flowchart TD  
    J[Health cron job in\nSidekiq process 1] --> I[Redis\ngitlab_maintenance_mode: 0 or 1\nzuora_maintenance_mode: 0 or 1\ncustomersdot_maintenance_mode: 0 or 1]
    K[Health cron job in\nSidekiq process 2] --> I[Redis\ngitlab_maintenance_mode: 0 or 1\nzuora_maintenance_mode: 0 or 1\ncustomersdot_maintenance_mode: 0 or 1]
    L[...] --> I[Redis\ngitlab_maintenance_mode: 0 or 1\nzuora_maintenance_mode: 0 or 1\ncustomersdot_maintenance_mode: 0 or 1]
    M[Rake task process for\nmanual maintenance mode] --> I[-- Redis --\ngitlab_maintenance_mode: 0 or 1\nzuora_maintenance_mode: 0 or 1\ncustomersdot_maintenance_mode: 0 or 1]
```

```mermaid
flowchart TD
    P(/metrics) --> N[Prometheus Exporter middleware]
    N[Prometheus Exporter middleware] --> O[1. Collector updates gauges based on values set in Redis\n2. Exporter exposes metrics at '/metrics' endpoint]

```

### Result

The `/metrics` endpoint should serve labels and metrics related to the existing types of CustomersDot maintenance (Gitlab, Zuora or manual).

### Next steps (if any)

Work on the Grafana implementation, directly in the runbooks project. See [this issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5725) for more details.

Story points: 5.0
Link to CDot from Version App should use BillingAccount instead of Customer

### Problem

The [version.gitlab.com application](https://gitlab.com/gitlab-services/version-gitlab-com) links to a Customer show page in CDot Admin from its Hosts index page.  [This is where the link is generated](https://gitlab.com/gitlab-services/version-gitlab-com/-/blob/master/app/helpers/current_host_stats_helper.rb#L69) in the Version App.  There is a [secret configured](https://gitlab.com/gitlab-services/version-gitlab-com/-/blob/master/config/secrets.yml#L15) for `customers_admin_url` that uses the value `http://localhost:5000/admin/customer`.

With the change to using the new BillingAccount data structure, the real `salesforce_account_id` column exists on BillingAccount.  This column still exists on `Customer` but should no longer be used and will be removed in the future.

Note: The link from VersionApp to CDot works because the customer URL uses the `salesforce_account_id` (e.g. `http://localhost:5000/admin/customer/00164000010c3XFABY`).  This lookup works in RailsAdmin because of [this code](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/4ae39fa629f11d88d5575837412df990e624b9a5/config/initializers/rails_admin.rb#L160) in the initializer.

**UPDATE:** We [realized a problem with the original solution](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6527#note_1278726123). If there are multiple Customers (and now BillingAccounts) with the same `salesforce_account_id`, this lookup logic picks the first record which could be misleading for Admins linking from VersionApp.

### Proposal

The link in VersionApp should be updated to direct Admins to the BillingAccount instead of a Customer.  Also, the link should go to the BillingAccount list page with the salesforce_account_id prefilled in the search to avoid any confusion mentioned above.

There are a couple of changes that are necessary to make this happen.

1. [x] Update version-gitlab-com app code to point to the BillingAccount search page (e.g. `https://customers.staging.gitlab.com/admin/billing_account?&model_name=billing_account&query=0017400000DGjddAAD`).  This will require an update to [the secrets file](https://gitlab.com/gitlab-services/version-gitlab-com/-/blob/master/config/secrets.yml#L15).  For production, this may need to be updated via a secrets vault.
   - https://gitlab.com/gitlab-services/version-gitlab-com/-/merge_requests/726
1. [x] The RailsAdmin initializer overrides the lookup adapter to allow `salesforce_account_id` to be used as id.  This override logic will no longer be necessary when the change to Version App above is merged/deployed.
   - https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6527

Story points: 2.0
Create new model to track maintenance mode events

### Proposal

This is the first issue listed in [this issue breakdown](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5582#issue-breakdown).

We need to record information related to events when CustomersDot enters and leaves maintenance mode.

Even though such information will be sent to Prometheus as a metric (more infor in [related issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5582)) and therefore we don't need long-term persistence, we still need to be able to record the event (maintenance) start time. This cannot be achieved through Rails caching or through some sort of global variable as a Puma restart might happen during a maintenance.

This issue tracks efforts towards the creation of such model.

### Result

A very small table with one row per type of maintenance:
- maintenance triggered because GitLab is not reachable
- maintenance triggered because Zuora is not reachable
- maintenance mode triggered manually (through the `customers:maintenance_mode` rake task)

### Next steps (if any)

Next issue listed in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5582#issue-breakdown

Story points: 2.0