giseldo/neodataset huggingface dataset:
Update healthcheck fields

## Problem
In order to properly rotate self-managed users that request to speak with the sales from in-app healthchecks we need to update the form fields that the user submits on the customers app form. 
 
![image](/uploads/fa23827bbe5043ec20d9f99c715a289e/image.png)
  
## Solution
We update the form fields on this form to add the following: 
 
* Country (picklist below)
* State if US or Canada (picklist below)
* Employee Range (picklist below)
* Opt-in Language (provided above)
* Make Company **required**
* Making Phone # required will help with contact rates.
 
[Picklist values can be found here](https://docs.google.com/spreadsheets/d/1cV_hI2wAzLxYYDI-NQYF5-FDDPXPXH0VV5qRBUJAQQk/edit#gid=439131791)

And remove the following fields:

* Address (in favor of country which is included in the newly added fields above)
 
These newly added fields should sync in the same manner to SFDC. 
 
Technical details: 
* Jerome located the code associated with "healthcheck" moment here https://gitlab.com/gitlab-org/gitlab/-/issues/208291#note_295737482
* We increased the rollout on EE here https://gitlab.com/gitlab-org/gitlab/-/issues/231512
* And increased the rollout on CE here https://gitlab.com/gitlab-org/gitlab/-/issues/247634

## Merge requests
- ~database - Add new columns to `instance_reviews` field: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2714
- Align list of countries: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2731
- Align list of US states and Canada provinces: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2791
- ~database - Add optin column to instance_reviews table: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2854
- Add new field to the form: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2842

Story points: 5.0
Update gitlab-styles to 5.3.0

The following discussion from !2182 should be addressed:

- [ ] @dstull started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2182#note_450160791): 

    > bug in gitlab-styles where the empty line wasn't being alerted on for `let_it_be` - we should upgrade to [5.1.0](https://gitlab.com/gitlab-org/gitlab-styles/-/tags/v5.1.0) - just a note so I can spawn an issue here.

Story points: 1.0
New subscription purchase flow for Trial namespaces should follow new path

## Summary

When a namespace is on a trial and it is active, a user trying to purchase a new subscription for that namespace is pointing to a the legacy new subscription flow. Not only does this cause an inconsistent user experience, but it causes the user to receive an error during checkout due to not having a stored address.

## Proposal

Update the path for this use case to point to the new subscription purchase flow (via GitLab.com) so that address is collected during the purchase process.

## Reference

Additional details of this change request is described here: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1236#note_442674321

Story points: 3.0
Community Programs Self-Checkout

## Summary

The Communities teams (OSS, Start-Ups, EDU) will be working with a vendor to create an automated application process - webform to interact with the applicant which screens through the qualification process. Once the applicant is approved, they will receive a coupon code and be prompted to self-checkout on customers.gitlab.com to complete the subscriptions creation and provisioning processes.

### Process overview
1. Upon approval, the applicants receive a coupon code
1. The applicant navigates to customers.gitlab.com, selects new subscription flow
1. User enters the code at checkout and the subscription is booked at $0.00
     1. The subscription must be created using the applicable Community Programs sku
     1. The user should not be prompted to enter a credit card since the net is $0.00
1. Normal provision process follows

### Coupon Code Generator Features
1. We need to store the generated codes so they can be referenced during checkout
1. The coupon code should relate to product sku (info received from the vendor call) which when applied to a purchase flow, would dictate which product sku we are selling
1. The code can not be reused; once redeemed, we invalidate the code in our DB for future use
1. The code will provide a specific discount per sku
1. The vendor presenting the coupon code after successful application cannot utilize an API to receive the coupon from us. We will need to provide the vendor with bulk codes via a file upload periodically.

## Tasks

1. [ ] Introduce the Coupon Code on the FE (New subscription flow)
     1. There is a coupon code field which was hidden via https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/662; let's just reveal that field again.
1. [ ] Build the coupon code generator
1. [ ] Build BE logic to recognize coupon code
1. [ ] Determine how to handle Renewal Process
1. [ ] Determine how to handle Add-On users midterm

Story points: 5.0
Notify users with instructions to associate their subscription if they haven't associated it `n` days after provisioning

<!-- The first four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. -->

### Problem to solve

There are users who purchase a subscription (often sales assisted), but for some reason never link it up. 

### Intended users

* [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator)

### User experience goal

A user who purchases a GitLab.com Subscription knows if they haven't linked it, and gets a notice some days after provisioning reminding them to take the necessary actions.


### Proposal

Send email to subscription contact (CustomersDot contact).

Story points: 3.0
Add weights to sidekiq queues

# Purpose

Add weights for all the queues in [the Sidekiq config file](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/c7265500ef31b5258e314c7e2ecccf1a58855e18/config/sidekiq.yml#L20-29).  The weights will determine the priority of the queues to be processed.

## Followup from:

The following discussion from !2152 should be addressed:

- [ ] @rpereira2 started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2152#note_442861095):  (+1 comment)

    > Thanks @tyleramos, LGTM! :+1:
    > 
    > On a related note, we might need to add weights to the [queues in the sidekiq config file](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/c7265500ef31b5258e314c7e2ecccf1a58855e18/config/sidekiq.yml#L20-29). Without the weights, sidekiq will only execute jobs from queues lower in the list when the queues higher in the list are empty (ref: https://github.com/mperham/sidekiq/wiki/Advanced-Options#queues).
    > 
    > @asubramanian1 Would you please do the maintainer review?

Story points: 1.0
Checkout box design refinement

### Proposal

In #2133, @timnoah is suggesting the following changes:

![](https://gitlab.com/gitlab-org/customers-gitlab-com/uploads/a077bb414b44ca76eb5e8a3aa2e6ebd1/Checkout-box.png)

1. Increase the text size of the total amount in the checkout component.
1. Include a field label `Payment method` for the payment dropdown.

The changes above should be applied to all checkout pages.

Story points: 2.0
Update ruby to match GitLab version (currently 2.7.2)

### Problem

CustomersDot is using [ruby version 2.6.6](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/3a65e65af4796e8b04d7ce1d9159a80c9c81920d/.ruby-version#L1) at the moment but GitLab is using 2.7.2.

### Proposal

We should evaluate if we can upgrade to the same version as GitLab and perform the upgrade if possible.

Story points: 2.0
Storage: Remove `storage_plan` feature flag

Once the [storage feature has been enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/255166) and considered stable, we should remove the `storage_plan` feature flag checks in the CustomersDot repo.  Once the MR has been deployed to production, we can safely remove [the `storage_plan` feature flag](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/62/edit) from CustomersDot.

Story points: 2.0
Follow-up from "Add tests and patch company assignment issue"

The following discussion from !2141 should be addressed:

- [ ] @dstull started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2141#note_440927997):  (+3 comments)

    > @jameslopez only real ~bug I have found so far and it was [pre-existing](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2021/diffs#df783448a783e84dbb83b07691fed5e3a2259693_54_44) before the refactor - so I *think* this is a bug and we should fix it here - WDYT?

Story points: 1.0
Modify application to use auto renew based on the Zuoras auto_renew custom field

As part of https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2081, we are creating new custom field to replace the auto_renew from Zuora. 

Use the new custom field in the codebase to turn on and off the auto renew and also use it while showing in the UI the toggle button.

Story points: 3.0
Create cron service to read orders for renewal

As part of the issue https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2081, we need to run a cron service every midnight of the server which will pick the orders which have their end date within last 30 days.

After fetching these orders we make a call to Zuora to determine whether the auto_renew custom field has been turned on and there are no auto_renew_errors. 
If these conditions are met then we will call the AutoRewew Service with the order for it to perform the renew.

Story points: 2.0
Create Auto renew service to perform renewal

The auto renewal service takes an order and makes a call to Zuora to perform the _Manual_ renewal 

The Auto Renewal service would simulate checkout process and attempt to charge the default credit card on file

1. if payment fails, cancels the transaction
   1. do not send any change to zuora
1. if payment success, copy amendment process from manual renewal flow to zuora. 

After the amendment to Zuora the service exits without doing anything else. The Zuora will send in the callback to ZuoraCallbacksController which in turn will either send a new license ( for SM ) or will update GL.com

Part of https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2081

Story points: 3.0
Create custom fields in the Zuora to save the auto renew boolean

As part of the major issue https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2081, we are going to save the custom field `auto_renew` within the Zuora which will act as in future part of SSOT as well. 

As of now whenever a customer creates a new subscription then apart from (EDU/OSS/YCombinator & Stand alone CI minutes plan) the auto renew feature is turned on and instead of setting the auto renew we will toggle the custom field in Zuora. 

This issue will only create new custom field in Staging ( for development purpose ) on Zuora and later in production Zuora ( a follow up issue will follow later )

https://knowledgecenter.zuora.com/Central_Platform/Manage_Custom_Fields

cc: @chris_baus @tyleramos

Story points: 1.0
Procurement | REMOVE Support SKU for the Education Program

# SKU Request Summary
The ability to purchase support separately for the free GitLab for Education Program was deprecated as part of the [Education Pricing and Packaging Initiative](https://gitlab.com/groups/gitlab-com/packaging-and-pricing/-/epics/2). The SKUs need to be removed.

[Additional details here](https://gitlab.com/gitlab-com/marketing/community-relations/education-program/general/-/issues/54#support)

[See e-group approval here.](https://gitlab.com/groups/gitlab-com/packaging-and-pricing/-/epics/2#approvals-required)


## SKU Requirements

In order to expedite your request, please complete all of the following information.
Any questions about this template or this request can be directed to @amandarueda in the comments of this issue.

* [x] SKU Name:  Ultimate - 1 year EDU with Support and Gold - 1 year EDU with Support`
* [ ] SKU Code/ID:
* [ ] Zuora Plan Name: `enter plan name`
* [ ] Zuora Plan ID: `enter plan ID`
* [ ] Service type: `subscription | add-on | stand-alone`
* [ ] Does this need to be purchase-able via CustomersDot? `Yes | No`
* [ ] Does this service renew? `Yes | No`
     * [ ] If yes, what is the renewal cadence? `monthly | annually | other`
* [ ] Should an email be sent indicating the subscription is coming to an end?: `Yes | No`
* [ ] Is there a unit of measure, if so what? ` Yes | No`  `Users | Qty | other`
* [ ] Does this service provision anything? `Self-managed license | Gitlab.com entitlement | other`
     * [ ] If yes, please describe in detail what should be provisioned including the systems affected:
* [x] How soon do you need this SKU ? Timeline: This request is not urgent, but it would great if it could be completed with the other existing requests. [See add SKUs for Edu PnP here. ](Procurement | Add new SKUs for the Education Enterprise Subscription)
* [ ] Who in Sales-Ops approved this request: [See approval list on Edu PnP](https://gitlab.com/groups/gitlab-com/packaging-and-pricing/-/epics/2#approvals-required)
* [ ] [Link to originating Finance issue](https://gitlab.com/gitlab-com/Finance-Division/finance/-/issues/3490)
* [ ] Apply the appropriate `BTG Priority` label to this issue.

Story points: 1.0
No server-side validation on purchasing an add-on for 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 don't validate subscription on purchasing an add-on for it. Grab the correct URL for purchasing an add-on: `http://localhost:5000/subscriptions/new?plan_id=2c92c0f9699eca030169a2f1f117045f&subscription_id=A-S00048152&transaction=ci_minutes` and change the query key `subscription_id` to anything else, for example `subscriptio_id`.
Now open it in your browser. I expect a redirect to the subscription list page but instead I see the purchase screen which does not work.

### Proposal

We should validate the subscription and redirect the customer to the `/subscriptions` path if invalid subscription was provided.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Add indicator of active subscription in Customers Admin

## Summary

As an internal team member who frequently searches the Customers admin, it is very time consuming to select the `Edit` icon in search results to identify which of the returned results are related to a customer record with an active subscription.

## Proposal

Create some sort of quick reference indicator (visual or label) which allows me to discern which of the search results have an active subscription.

![Screen_Shot_2020-10-24_at_16_54_04](/uploads/4e5ca02d1d209f6f2562eae42ab277fb/Screen_Shot_2020-10-24_at_16_54_04.png)

Story points: 2.0
GitLab.com and customers.gitlab.com linkage broken

## Summary

The linkage between customers.gitlab.com and gitlab.com is displaying `No account linked` for accounts which have been linked. I was in this area on production within the last 48 hours so a regression must have occurred within that timeframe.

UPDATE: I was able to make a purchase of CI minutes in spite of the system appearing as if the gitlab.com account is linked, so I _think_ this is just a frontend visual issue, and not a backend connection issue but would like confirmation from engineering on that.

![Screen_Shot_2020-10-23_at_15.38.46](/uploads/78d4301547e054048572185c94fb811e/Screen_Shot_2020-10-23_at_15.38.46.png)

Story points: 1.0
UX: Create manual renew feature for SaaS subscriptions

This is the UX design issue for https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2132

## Proposal

| Manage Purchases| Manage Purchases | Renew SaaS Subscription |
| ------ | ------ | ------ |
| ![Billing_Page](/uploads/7d1dec021717844f321b00efbce0c141/Billing_Page.png) | ![Manage_Purchases](/uploads/f402470df8c480c6424818e2f2f8b9c5/Manage_Purchases.png) | ![Renew_-_Silver_-_page](/uploads/5a7058e6026d04952973581ceb115e31/Renew_-_Silver_-_page.png) |
| Added a `Renew` button to the subscription card table. | Added a `Renew` button to the subscription card. This would take a user directly into the Renewal flow. | This borrows heavily from templates already in production for renewing a self-managed license with one main addition.<br>This also gives users the ability to upgrade a subscription in the flow of renewing. Since https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2134 is reliant on this work, I thought it was beneficial to start thinking about how this might work now, to get us ready for that issue. |

[**Design Specs**](https://www.figma.com/file/ba0dDaAgQ7uhet8W7SkQf8/Create-manual-renew-feature-for-SaaS-subscriptions?node-id=27%3A103)

### Notable template refinements

<img width="400" src="/uploads/a077bb414b44ca76eb5e8a3aa2e6ebd1/Checkout-box.png" />

1. Increase the text size of the total amount in the checkout component.
2. Include a field label `Payment method` for the payment dropdown.

Story points: 2.0
Correct bug in Order#latest_reconciliation

The following discussion from !2080 should be addressed:

- [ ] @rpereira2 started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2080#note_430324728):  (+2 comments)

    > I think this result is wrong. I think the latest reconciliation should be `reconciliation1`, but I'll correct the implementation of `latest_reconciliation` in a separate MR.

Story points: 1.0
Remove deprecated code related to `vue_account_details_page`

The integrated component from https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1261 is completed, and is enabled with the `:vue_account_details_page` Feature Flag in production. :thumbsup:

![Screen_Shot_2020-10-21_at_1.43.53_PM](/uploads/cf81072efe9351ed4a67ccdd95346f89/Screen_Shot_2020-10-21_at_1.43.53_PM.png)

![before-after](/uploads/2a6f2f3c652a186f200399258490ffcc/before-after.png)

### Proposal

Remove deprecated code and feature flags after enabled in production

### Result

### Next steps (if any)

Monitor Sentry for 30 days and clean up the old code in `app/views/shared/customer/_edit.html.haml` once there are no further issues.

In addition to cleaning up the old haml code and the `:vue_account_details_page` Feature Flag afterwards, the following feature flags could then be removed:

* pajamas_account_page
* account_page_vue_personal_details
* account_page_vue_company_details
* account_page_vue_change_password
* account_page_vue_link_gitlab_account

### How will we measure success?

Story points: 1.0
Custom Zuora attributes should be synced in local cache

### Problem

If custom attributes as added in Zuora for Product objects, these will need to be synced as part of IronBank's local cache feature.  We started using this local cache, storing the products in the database, as part of https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1762.

### Proposal

Investigate if custom attributes are captured in the local cache.  If so, then there shouldn't be anything else required.  If not, determine a plan for including these custom attributes.

Story points: 2.0
Remove "Sign in" CTA when on sign in pages

### Details

In the sign in pages, there is no need to show the **Sign in** link in the top nav bar. Having the link there can add unneeded redundancy, as this way there are two "sign in" options in different graphical formats, with no clear way for the user to see how they differ or are alike other than clicking on both to see. Also, as the hamburger menu for the narrow views only contains the **Sign in** item, it would be recommended to remove that as well.

| gitlab.com Narrow | gitlab.com Wide | cust sign in Narrow | cust sign in Wide |
| --- | --- | --- | --- |
|![Screenshot_2020-10-20_at_18.26.27](/uploads/b0abc3d33a0c15ef1f80331ac207c568/Screenshot_2020-10-20_at_18.26.27.png) | ![Screenshot_2020-10-20_at_18.26.42](/uploads/6d55a9a90f6f880def229f8b0161e219/Screenshot_2020-10-20_at_18.26.42.png)| ![Screenshot_2020-10-20_at_18.27.08](/uploads/f48134d1ff9f5887de8814e0db99d029/Screenshot_2020-10-20_at_18.27.08.png)| ![Screenshot_2020-10-20_at_18.27.21](/uploads/06f3f00c75086d8855bab02c234dae02/Screenshot_2020-10-20_at_18.27.21.png)|

A simple solution that comes to mind might be that of removing the sign in link / hamburger menu on those views:

| Narrow | Wide |
| --- | --- |
| ![Screenshot_2020-10-20_at_18.44.22](/uploads/62fda2a08b3826ee37d7844eda8e4fdc/Screenshot_2020-10-20_at_18.44.22.png) | ![Screenshot_2020-10-20_at_18.44.40](/uploads/95bdbbca3c223543e713aa117c95b732/Screenshot_2020-10-20_at_18.44.40.png)|

Story points: 2.0
Spike: Move Salesforce calls to background job

### Problem

Related to https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/486

The call for `CreateSalesforceLeadFromCustomerService` in the [RegistrationsController](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/controllers/registrations_controller.rb#L16) can be moved to a background job. There might be other Salesforce calls that can be moved to a background job.

### Proposal
Evaluate Salesforce calls and move them to a background job if possible.

### Result
Actions can proceed without failing of third party calls.

### Next steps (if any)

### How will we measure success?

### Availability & Testing

The tests surrounding this feature likely will need to move from a Controller unit spec, to an ActiveJob spec which requires a bit of change to the test.

<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.

What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?

Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change

See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning -->

Story points: 1.0
Clean-up: graduate pajamas_new_subscription feature flag

### Problem

In #1473 we introduced changes under [`pajamas_new_subscription`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/43/edit) feature flag.

### Proposal

Changes from #1473 have been deployed to production on Sept 19, 2020.

Around Nov 19, 2020, we need to graduate the code from the feature flag and clean up the old code if there's no issue.

### Result

Less legacy code and less moving parts.

Story points: 3.0