giseldo/neodataset huggingface dataset:
Namespace with extra_shared_runners_minutes_limit may prevent subscription provisioning

**Note:** this issue specifically deals with CI minutes that were added without a purchase (ie via the chatops command) - there is a similar issue that deals with namespaces that have an existing CI minutes pack purchase: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3371+

Came across [a customer](https://gitlab.zendesk.com/agent/tickets/263986) (internal) who was unable to link their new subscription purchase through customersDot "Change linked namespace".

In the [related sentry error](https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/3130777):

> Namespace change to xxxxxxxx is not allowed: Target namespace can't have additional CI minutes

I tracked this down to the customer having been at one point given extra minutes using the chatops function [`namespace minutes`](https://gitlab.com/gitlab-com/chatops/-/blob/5cdbfaecd14b0a8ee475a0fa3a2f6f09719aad77/lib/chatops/commands/namespace.rb#L65-75), which calls [`GitLab::Client#set_namespace_extra_minutes`](https://gitlab.com/gitlab-com/chatops/-/blob/5cdbfaecd14b0a8ee475a0fa3a2f6f09719aad77/lib/chatops/gitlab/client.rb#L42-45) and that invokes the API to set `extra_shared_runners_minutes_limit`.

This appears to come from the [namespace validator](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/1af3fcc24508a25e00b1cecc9f62ba15b7164aa2/lib/validators/namespace_transaction_validator.rb#L34) when called by [`UpdatePlanInfoService`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/services/gitlab/namespaces/update_plan_info_service.rb):

> if target_namespace.has_extra_shared_runners_minutes?

manually setting that value back to 0 (via API) allowed me to successfully link the customer's subscription from their cDot account.

In [some related discussions](https://gitlab.com/gitlab-com/support/toolbox/console-training-wheels/-/merge_requests/100#note_845461902), @tyleramos and @cwiesner noted that this validation may not be needed for all subscription updates, but perhaps more specifically for when a subscription is changing between namespaces.

# Reported examples

1. https://gitlab.zendesk.com/agent/tickets/263986
1. https://gitlab.zendesk.com/agent/tickets/277280
2. https://gitlab.zendesk.com/agent/tickets/314654 (Added 2022-Aug-05)
3. https://gitlab.zendesk.com/agent/tickets/313080  
1. https://gitlab.zendesk.com/agent/tickets/309643  
1. https://gitlab.zendesk.com/agent/tickets/309767  
1. https://gitlab.zendesk.com/agent/tickets/309296  
1. https://gitlab.zendesk.com/agent/tickets/313127  
1. https://gitlab.zendesk.com/agent/tickets/311366  
1. https://gitlab.zendesk.com/agent/tickets/309947
1. https://gitlab.zendesk.com/agent/tickets/315689
1. https://gitlab.zendesk.com/agent/tickets/316415
1. https://gitlab.zendesk.com/agent/tickets/316438
2. https://gitlab.zendesk.com/agent/tickets/332541

/cc @jhyson

Story points: 5.0
Follow-up from "Skip reconciliation when SM order cancelled"

The following discussion from !4257 should be addressed:

- [ ] @vshumilo started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4257#note_819799476):  (+4 comments)

> @tyleramos Do you know / remember why we want to update the order when the subscription is SaaS + with namespace associated only?
> 
> For the cases:
> - SaaS Subscription that is not linked to a namespace in Gitlab.com
> - SM
> 
> Don't we want to at least execute the [update_order](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/f1f8fd08819c755e782a971329b3bac743ff39dd/app/services/process_inactive_subscription_service.rb#L19) to keep it in sync with Zuora?
> 
> Ref: This service was created out of code from the `zuora_callbacks_controller` [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/commit/caba7cf0a41991b3cc7d0959c7e0ead7abe2b0f2)

During the `ProcessInactiveSubscriptionService` execution ONLY orders for SaaS subscriptions with an associated namespace on Gitlab.com are [updated to free](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/6e5407cf766e93cbfd11410f43314aace738b151/app/services/process_inactive_subscription_service.rb#L58-L62).

We want to keep the order up to date always including:
- SaaS subscriptions without an associated namespace
- SM subscriptions

Story points: 2.0
Remove obsolete field `usage_ping_required_metrics_enabled` from License

### Problem

The column `usage_ping_required_metrics_enabled` in the `licenses` table is no longer used and should be removed. It was planned originally as part of Super Sonics but was pretty quickly replaced by the field `operational_metrics_enabled`. I don't believe this field was ever really used. You can find more context about the field change in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3248.

### Proposal

The end goal is to remove this column from the database but must be done in a few steps:

1. [x] - Ignore the column in https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4260 (Deployed)
1. [x] - Remove the column from the DB in https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4255 (Deployed)
1. [x] - Remove the ignore column logic in https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4261 (Deployed)

Story points: 1.0
Return empty on unathenticated requests for order_preview

### Problem

New users can not purchase Storage without having CustomersDot account.

### Proposal

Remove the authenticated check for `order_preview` and instead check for user presence in the resolver itself. If the user is not present - return empty

### Result

New users are able to purchase Storage without having CustomersDot account

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Add Customers API to check whether customer should see overage alerts for the subscription usage

### Problem

As part of https://gitlab.com/gitlab-org/gitlab/-/issues/348481, we need to be able to determine whether customer should see overage alerts for the subscription usage ~~the subscription has the reconciliation flag enabled on Zuora~~, so that we only show alerts for the appropriate subscriptions.

ATM a subscription will be charged for usage overage in [several scenarios](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3934#note_818310692). This would change as we improve the process. If we won't(do not want to , or not ready to) charge the customer for a subscription's usage overage, we do not show the alert(otherwise it is confusing to customer).

This issue will iterate from show alert to `subscription has the reconciliation flag enabled on Zuora`, which I think it includes: 
- `Use case 3: Sale Assisted QSR` in the table.
- `Use case 6: self service QSR` in the table.

### Proposal

Create or modify an endpoint on the customers application to expose this information to the GitLab application and create the functionality on the GitLab application to fetch and cache this data.

Story points: 5.0
Zuora iframe date/month inputs are broken on narrow viewports

Month/year input styles for payment information are broken on narrow viewports. This is reproducible on Edge and Firefox (maybe more) on screens from 320px to 343px and from 992px to 1200px.

### Problem

![Screenshot_2022-01-17_at_10.35.51](/uploads/cd895c8446df0e6ccbd3a7c12fae3ef1/Screenshot_2022-01-17_at_10.35.51.png)

Related issue: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2545

### Steps to reproduce

1. Make sure the CustomerDot is configured and working locally
1. Open the following link [http://localhost:5000/subscriptions/new?plan_id=2c92c0f97700a4f7017704c7fe465919](http://localhost:5000/subscriptions/new?plan_id=2c92c0f97700a4f7017704c7fe465919)
1. Choose `Add a new Credit Card` in payment method form
1. Resize browser

### Proposal

Fix payment styles, test in multiple browsers, make sure that it's properly updated in test and production Zuora. For guidance on updating Zuora iFrame styles, check [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/doc/setup/frontend.md#styling-zuoras-iframe).

When verified locally, please follow the steps described in [docs](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/doc/setup/frontend.md#update-compiled-css) to apply the resulted CSS to staging/production iframe.

Story points: 2.0
[SaaS] Send introductory email about user overages after purchase

## Problem to solve

SaaS customers are being surprised and taken off-guard by Quarterly Subscription reconciliations. Because self-service SaaS customers have not historically been charged true-ups, the QSR process and the fact that they have to pay for overages is totally new. See tickets from customers [here](https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/337).

## Intended users

This issue is just for SaaS customers.

* Group Owners of a group who has just purchased a subscription
* Only groups enrolled in quarterly subscription reconciliation. See exactly which use cases we're solving for in the [Epic description](https://gitlab.com/groups/gitlab-org/-/epics/7229#saas-customers).

## Proposal

After a subscription has been purchased for a group in GitLab, send an email to **all** group Owners 1 day after a subscription has been purchased to make them aware of how users are counted and how overages are handled.

We should send an email to all group Owners (not just the group Owner who purchased the subscription), because all group Owners should be aware of the overage behavior.

[Design here](https://gitlab.com/gitlab-org/gitlab/-/issues/347267/designs/Email_to_group_Owners_1_day_after_purchase_with_info_about_QSR.png)

#### Email copy

>>>

Subject line: Managing users in your subscription

Dear [customer],

Thank you for purchasing a GitLab.com subscription! As you get started, we want to make sure you understand some important billing information.

Your subscription cost is based on the maximum number of seats you use during the billing period. If you reach the number of seats in your subscription, you can continue to add users, but GitLab bills you for the overage. These bills occur every quarter.

Read more about quarterly reconciliation in [our product documentation](https://docs.gitlab.com/ee/subscriptions/quarterly_reconciliation.html).

If you have any questions about this process, [please reach out](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=360000071293). We are happy to assist.

Thank you for your business!

GitLab Billing Team

>>>

## Implementation Plan


| Issue | Issue link|
|--|--|
| Create mailers | https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3999 |
| MVC identify CustomersDot emails to send to | https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4000 |
| Send introductory email 1 day after purchase | https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4007 |
| Send introductory email 1 day after renewal | https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4008 |
| Query GitLab.com for group owners emails and send | https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4009 |

Story points: 0.0
Discovery:  Is CDot impacted in any way to known changes of in the Quote objects in SFDC

<!-- 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
Zuora CPQ data in SFDC changes once Orders is enabled in the related Zuora environment.  CDot integrates with SFDC and interacts with Zuora CPQ data.

### Proposal
Peer into business logic in CDot to understand if there are references to known Zuora CPQ data in SFDC that is changing.  List of impacted fields is found here:  https://gitlab.com/gitlab-com/business-technology/enterprise-apps/intake/-/issues/493#summary-findings-orders-with-quote-studio-v-production-no-orders

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result
Fulfillment team can sign off that normal booking processes between CDot<>Salesforce will not break due to the known CPQ data changes.

### Next steps (if any)
Nothing additional to the Proposal

### How will we measure success?
Fulfillment:Licensing approval and confirmation that no order-to-cash disruptions are expected due to the changes in CPQ when enabling Zuora Orders.

Story points: 3.0
Fulfillment dev review of Support CustomersDot console functions

### SUMMARY

As a result of [this ask](https://gitlab.com/groups/gitlab-org/-/epics/6828#note_729956691) we want to review some Mechanizer functions to feedback support and possible detect some areas where the logic might not be inline with CustomersDot.

Review is associated to issue: https://gitlab.com/groups/gitlab-org/-/epics/6828#note_729956691

This issue exists to track the effort associated to the group and milestone as these labels cannot be set in the above referenced issue.

[Review is timeboxed](https://gitlab.com/groups/gitlab-org/-/epics/6828#note_748899271).

### OUTCOME

Highlighted functions were reviewed via MR (https://gitlab.com/gitlab-com/support/toolbox/console-training-wheels/-/merge_requests/89) with comments and suggestions.

Story points: 1.0
Incorrect purchase email styling

<!---
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

When testing the purchase flow on staging the current new purchase email seemed to be broken, it was missing styling and rendering incorrectly.

## Steps to reproduce

1. Buy a new subscription on staging
1. View `[GitLab Transactions] Your GitLab Premium/Ultimate Purchase` email

## Behavior

| What is the current *bug* behavior? | What is the expected *correct* behavior? |
| ------ | ------ |
| ![image](/uploads/d9a3d61ca7037df7a4c0c7027581f0f7/image.png) | ![image](/uploads/5bc25ff11b80b16415cdee6c1437e708/image.png) |

Story points: 2.0
Daily empty vcr cassettes not reporting anymore

### Problem

The [daily empty vcr cassettes](https://gitlab.com/groups/gitlab-org/-/epics/6519) job has stopped reporting results. The last result is from Nov 11th [Slack link](https://gitlab.slack.com/archives/CL7SX4N86/p1636601563124400). The job is still running daily as it can be seen [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/jobs/1880866396). But it apparently failed at some point and has not reached the [reporting part](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/721ae19719c84b6265148cd50f8fc50770254d39/.gitlab-ci.yml#L198) of the job. It is allowed to [fail](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/721ae19719c84b6265148cd50f8fc50770254d39/.gitlab-ci.yml#L191) though.

### Proposal

Investigate why the job is not being executed correctly anymore and submit a fix.

### Result

Running daily empty vcr cassettes job.

Story points: 2.0
Update successful purchase modal to have one CTA

### Problem

![image](https://gitlab.com/gitlab-org/customers-gitlab-com/uploads/45fe8ae1c9f6c58ef378145793918796/image.png)

The current modal has two CTA buttons. The main CTA `Activate your license` leads the user away from CDot into the [docs](https://docs.gitlab.com/ee/user/admin_area/license.html). This can be confusing and is not ideal.

### Proposal

We should only present one CTA button that should link to the `Manage purchases` page similar to the [original proposal](https://www.figma.com/file/ecx0Hv66uG2GYuLby8OBgU/Super-sonics%3A-Checkout-(without-enforcement-to-upgrade-to-14.0)?node-id=234%3A7062).

![Success-Modal](https://gitlab.com/gitlab-org/customers-gitlab-com/uploads/ca34e0b8d0cb2e6804dc539358e4c215/Success-Modal.png)

Relevant UX issue: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3870

Story points: 1.0
Fix broken link in purchase confirmation email

<!---
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

Clicking on `upload it to your GitLab instance` in the purchase confirmation email goes to a 404

## Steps to reproduce

- Purchase a license
- Check email
- Click on "upload it to your GitLab instance"

## What is the current *bug* behavior?

Link goes to a 404 on the docs site

## What is the expected *correct* behavior?

Link should go to https://docs.gitlab.com/ee/user/admin_area/license.html

## Relevant logs and/or screenshots

![image](/uploads/14c6d4fc93f57e836d8accc961cc0c42/image.png)

<!--- ## Workarounds

(Ways to get around the issue)

## Reported examples

1.
1.
1.


Please add both severity and priority level according to: https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#severity-labels
--->

Story points: 1.0
Change "Upgrade" button to "Upgrade plan"

![image](/uploads/00686353a73a00585dba2ee48f2073e5/image.png)

## Proposal

Based on [this discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3860/designs/1_-_New_subscription_purchase.png#note_764671505) it was recommended we should be more explicit with the language surrounding Upgrades of tiers and Gitlab versions. We should change the button text from `Upgrade` to `Upgrade Plan`.

Story points: 1.0
Unify root and /subscription pages

Now when `/plans` page is removed we can unify templates that we show on root and /subscription pages. Currently the only difference between them is where "Buy new subscription" link leads for users with active subscription.

| https://customers.staging.gitlab.com/ | https://customers.staging.gitlab.com/subscriptions |
| ------ | ------ |
| ![Screenshot_2021-12-06_at_15.14.31](/uploads/b5721ac65eab826ff2856adcdd7b9e6c/Screenshot_2021-12-06_at_15.14.31.png) | ![Screenshot_2021-12-06_at_15.10.43](/uploads/3d6318a42e14e58de6213f596a7e79ab/Screenshot_2021-12-06_at_15.10.43.png) |
| `Buy new subscription` is a link that leads to pricing page | `Buy new subscription` opens a modal window ![Screenshot_2021-12-06_at_15.15.36](/uploads/91dfa030cd18e8a77412db0fd685ac14/Screenshot_2021-12-06_at_15.15.36.png)|

### Suggestion

We should keep only one view. I would suggest to stick with a more simple one (current root). We should clean up th `SubscriptionController#index` and remove unnedeed views.

### Tech details to take care of during implementation (thanks @qzhaogitlab for checking it):

Check the details in the [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4124#note_752931041)

:arrow_right: This is the direction we chose.

* update `SubscriptionsController#index` to show a different (root) view
* clean up the `VisitorsController` -> previously, `VisitorsController`(as the root_url) handled both `authenticated` and `unauthenticated` users. Now we can keep only `handle_signed_in_user`
* cleanup old subscription index view & modal

:arrow_right: If we decide to keep /subscription page template (but we didn't!)

We could simply set `root to: 'subscriptions#index'` in [config/routes.rb](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/1a001e7db7b361b49dd4c2afb5fea829cc831955/config/routes.rb#L28)

But then we also need to clean up `SubscriptionsController#index`:

* simplify `@subscriptions = SubscriptionsFinder.for_customer(current_customer)`, just the same as current `VisitorsController#index`
* update the view file

Story points: 2.0
Customer salesforce_account_id is being set to null after first purchase in stg

### Problem

As described in [this thread](https://gitlab.com/groups/gitlab-org/-/epics/6606#note_750835063), we are seeing opportunities fail to create when testing OH in staging.

Here's an example from the sidekiq.log:

```
2021-11-30T13:52:01.158Z 2382585 TID-gq1lwdct1 Salesforce::CreateOpportunityWorker JID-a22456205ad4b4671c1f5770 ERROR: {"message"=>"#<Salesforce::OpportunityNotCreated: Salesforce::OpportunityNotCreated>", "error_message"=>"Salesforce::OpportunityNotCreated", "args"=>[84005, "A-S00055394", "8a8aa2e37d6ef23e017d702667464f52"]}
2021-11-30T13:52:01.159Z 2382585 TID-gq1lwdct1 Salesforce::CreateOpportunityWorker JID-a22456205ad4b4671c1f5770 INFO: fail: 1.312 sec
2021-11-30T13:52:01.159Z 2382585 TID-gq1lwdct1 WARN: {"context":"Job raised exception","job":{"class":"Salesforce::CreateOpportunityWorker","args":[84005,"A-S00055394","8a8aa2e37d6ef23e017d702667464f52"],"retry":true,"queue":"salesforce","jid":"a22456205ad4b4671c1f5770","created_at":1638264106.5169365,"enqueued_at":1638280319.847346,"error_message":"Salesforce::OpportunityNotCreated","error_class":"Salesforce::OpportunityNotCreated","failed_at":1638264107.6331813,"retry_count":9,"retried_at":1638273562.4499516},"jobstr":"{\"class\":\"Salesforce::CreateOpportunityWorker\",\"args\":[84005,\"A-S00055394\",\"8a8aa2e37d6ef23e017d702667464f52\"],\"retry\":true,\"queue\":\"salesforce\",\"jid\":\"a22456205ad4b4671c1f5770\",\"created_at\":1638264106.5169365,\"enqueued_at\":1638280319.847346,\"error_message\":\"Salesforce::OpportunityNotCreated\",\"error_class\":\"Salesforce::OpportunityNotCreated\",\"failed_at\":1638264107.6331813,\"retry_count\":9,\"retried_at\":1638273562.4499516}"}
2021-11-30T13:52:01.159Z 2382585 TID-gq1lwdct1 WARN: Salesforce::OpportunityNotCreated: Salesforce::OpportunityNotCreated
2021-11-30T13:52:01.159Z 2382585 TID-gq1lwdct1 WARN: /home/fulansdep/CustomersDot/releases/20211130083215Z/app/services/salesforce/create_opportunity_objects_service.rb:188:in `create_salesforce_opportunity'
/home/fulansdep/CustomersDot/releases/20211130083215Z/app/services/salesforce/create_opportunity_objects_service.rb:4
```

After some investigation, we determined the source of the bug was a difference between the Order Processed callout and the New Subscription Created callout.

- `New Subscription Created` callout returns `<parameter name="account_crm_id"></parameter>`
- `Order Processed` callout returns `<parameter name="account_crm_id">null</parameter>`

You can see this in the callout history for [this customer in api sandbox](https://apisandbox.zuora.com/apps/CustomerAccount.do?method=view&id=8ad09f8a7d769bad017d7990c06f3883).

### Proposal

Despite this likely being a bug in Zuora given the discrepancy in how the callouts are handled, we can account for this in CustomersDot when parsing the callout attributes from the request body.  CustomersDot can handle `"null"` value as a empty string.  The `Order Processed` callout should then be processed like other callouts at that point.

Story points: 2.0