giseldo/neodataset huggingface dataset:
Can not delete payment method

### Summary

When I try to delete one of my two payment methods, I get redirected to a 404 page.

### Steps to reproduce

- Log in to customers.gitlab.com
- Go to payment methods
- Make sure to have at least two Payment methods
- For the non-default payment method click on "edit"
- On the details page for that payment method hit "Delete"
- Accept the confirmation dialog

### What is the current *bug* behavior?

- I'm getting redirected to this address: `https://customers.gitlab.com/payment_methods/%23%3CZuora::PaymentMethod:0x000000000[***]%3E` (the `[***]`-part is my replacement) which shows a 404 page.
- When I go back to the payment methods, the deleted payment method is still there.

### What is the expected *correct* behavior?

- I should get back to the list of payment methods.
- The deleted Item should be gone.

<!---
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
Ensure button UI consistency with the move to `gl-new-button`

<!-- 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've adopted `gl-new-button` (named `gl-button`) which follows the Pajamas style guide.

This means that the HAML buttons which do not follow the Pajamas style guide are visibly different.

This is especially noticeable [on pages that have HAML and Vue buttons](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1309#note_330940880).

### Proposal

Update CSS so buttons look the same.

| Before | After |
| ------ | ------ |
| ![image](/uploads/62cff3bcd6826b59af3f7d5d5d69ea55/image.png) | ![image](/uploads/3a390c44b2b02048bba1076a76f3b3f0/image.png) |

Story points: 2.0
Follow-up - Have visual indicator of disabled items in namespace-select

The following discussion from !860 should be addressed:

Original [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/860#note_330810109).

We should have a better indicator for the user to know which item is disabled visually. previously the user had to move the mouse over an item to see what's the shape of the cursor will be (pointer for clickable items and normal for disabled).

## Suggestion

| before | after |
| ------ | ------ |
| ![Screen_Shot_2020-04-24_at_13.53.22](/uploads/2080a648bf33ffa6b890419a9b9bda50/Screen_Shot_2020-04-24_at_13.53.22.png) | ![Screen_Shot_2020-04-24_at_13.53.26](/uploads/3b700710ccbc4283cf5df3a9055d2b1e/Screen_Shot_2020-04-24_at_13.53.26.png) |

Story points: 1.0
Some Web directs not creating an opportunity, only subscription

This is a follow-on issue from: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1091#note_328894575

[New examples](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1091#note_328894575) provided:

FYI: Invoice #[INV00064014](https://gitlab.my.salesforce.com/0064M00000XYlDM?srPos=0&srKp=006) and[INV00064013](https://gitlab.my.salesforce.com/0064M00000XYlDH?srPos=0&srKp=006) didn’t create an account or opportunity, and it’s for starter and bronze plan respectively. Thanks!

/cc @rdavila @kdsouza2

Story points: 2.0
Fix Salesforce Bug: Do not open closed lost Opps

<!-- 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
*  [Related Sales Systems Issue](https://gitlab.com/gitlab-com/sales-team/field-operations/systems/-/issues/645)
*  The portal has a bug in it where it may potentially update an opportunity that was closed in a previous month and then closing it in the current month. This can lead to issues with reporting on historical where we may have reported a churned/Lost opportunity but now the opportunity no longer represents that. 


### Proposal
*  Once an Opportunity is closed (Won/Lost) in a previous month it should never be changed or reopened and closed
*  [WIP/Example MR for this](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1295)

### Result

### Next steps (if any)
*  Fix to either be merged into Portal or have an improved MR in place of the prepared MR 

### How will we measure success?
*  The portal should not be able to update previously closed opportunities - this will lead to fewer headaches for the Deal Desk team

Story points: 1.0
Default rest_client as true in all stubs

The following discussion from !1280 should be addressed:

- [ ] @asubramanian1 started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1280#note_328320714): 

    > Probably not within the scope of this MR: could we default the value for `rest_client` as `true` in all [stubs](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/spec/support/stub_zuora_calls.rb)? Given `rest` is the default behavior.

Story points: 2.0
Update Zuora Objects documentation

## Problem
The [customers-gitlab-com](https://gitlab.com/gitlab-org/customers-gitlab-com) Readme [references](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/README.md#L13) the [Zuora Objects](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/doc/zuora_objects.md) doc. 

This documentation uses the deprecated `Z::` classes.

## Proposal
We need to update the [Zuora Objects](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/doc/zuora_objects.md) documentation to reference the new Zuora REST API usage, classes.

Story points: 1.0
[Change Management] Add missing business stakeholders review to Danger

### Problem

For notifying changes and requesting a review from business stakeholders, at the moment we have checklists in the MRs such as:

* [ ] Ping `@jbrennan1` for review if the issue has the ~"Affects Salesforce" label
* [ ] Ping `@gitlab-com/business-technology/enterprise-apps/zuora-architects` for review if the MR involves Zuora business logic

While we have other reviews such as backend, frontend (review + maintainer review) and Database reviews all in Danger, where it makes it more difficult to miss.

### Proposal

We could automate this perhaps based on monitoring files/namespaces and incorporate it to Danger so this is no longer easily missed.

We should make sure this process is lightweight enough so it doesn't impact delivery times. For example, this may mean that we could get up to **7 different reviews** per MR (initial review, maintainer review, database review, database maintainer review, security review, EntApps review, Sales review)

Story points: 2.0
Send the phone number to SFDC for new trials

### Problem

Phone number is not recorded

https://gitlab.com/gitlab-org/gitlab/-/issues/214849#note_326520387

### Proposal

It should be end to SFDC as stated https://gitlab.com/gitlab-org/gitlab/-/issues/214849

### Related

>  just talked to Sam and we figured it out. the API names on the form are incorrect and don’t match SFDC, so they aren’t captured.
> in SFDC, the API names are NumberOfEmployees and Phone
> here’s a sheet that should be helpful https://docs.google.com/spreadsheets/d/1kIKnHqjYE7GdCqxIKKjJGDzw086lB6FRyE7N-BZUqi4/edit#gid=0



Story points: 3.0
Spike: Namespaces can be removed in gitlab but we still have references to their subscription

### Problem
Research: We have a lot of order records with subscriptions that reference missing "groups" in gitlab. This can probably happen when users/or namespaces are removed from the system.

This is a discovery issue to see what parts of the code may be affected by the changes and come up with a fix.

### Proposal
Let's discuss it.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Clarify params used for gitlab_support_url helper method

The following discussion from !1169 should be addressed:

- [ ] @oswaldo started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1169#note_322136203):  (+1 comment)

    > I'm not sure if I follow this number, should that be extracted to some constant, or YAML config?

## Problem
Currently, [the `gitlab_support_url` helper method](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/dbb3aa0a13505f6514b43bd43b23f2a1379c9de1/app/helpers/application_helper.rb#L24) accepts an optional param for `ticket_form_id`.  This is used throughout the views with param values like `360000071293` and `334447`.  It's not clear what these values mean.

## Proposal
Instead of using these numbers directly when calling the helper method, it would be preferable to set these as constants or set them in application.yml.  Referencing them in one place will make it easier to update in the future and make it clearer when seeing the reference in code.  For example, this `gitlab_support_url(LICENSING_AND_RENEWAL_PROBLEMS)` is clearer than `gitlab_support_url(360000071293)`.

Story points: 1.0
Convert account details page to Vue.js

<!-- 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

Page `Account details` was migrated to Pajamas styles but not to Vue.js components.

What do we have on it:

4 separated sections (all screenshots were taken from Pajamas version):

<details>
<summary>Personal details</summary>
![image](/uploads/e0f5c1cb7982394deb31194726c9d143/image.png)
</details>

<details>
<summary>Company details</summary>
![image](/uploads/aa9da89cf9b39cc219d1b8cae4b86bdf/image.png)
</details>

<details>
<summary>Change password</summary>
![image](/uploads/772c062f9f2abd35b00377470841077e/image.png)
</details>

<details>
<summary>Link GitLab account</summary>
![image](/uploads/d93515fe274ef1717e60cf69cab700f5/image.png)
</details>

### Proposal

In order to complete our Pajamas update, we should update this page too. 
We already have a feature flag for that page - `pajamas_account_page` so I suggest the following plan:

* We implement a Vue.js component for each section without integrating it.

### Result

Vue.js based page for account details with more control over extensibility (VAT field visibility depends on selected country). Removed legacy `select2` selects for country and state.

### Next steps (if any)

The 4 new components:

* [x] `Personal Details`
* [x] `Company Details`
* [x] `Change Password`
* [x] `Link GitLab Account`

All have been merged now, and they are behind feature flags.

* [x] Integrate all these components to a Vue.js app 

* Move information about linked GitLab account to `CustomerPresenter`.
* Replace all 4 Vue.js applications with a single Vue.js app.
* Optional: Show all errors in the root Vue.js application for better UX (or keep them for now in their components but just scroll to an errored component and expand it).

* [ ] Enable all 4 flags in production

### How will we measure success?

### Other information

* Original issue https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/678
* Feature flag `pajamas_account_page` has been running in production since %"12.8"

Story points: 5.0
Verify polyfills presence in bundles

<!-- 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

Special ~"production::blocker" issue for https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1215 to block production deployment until we verify polyfill existence in bundles.

### Proposal

### Result

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Create model Reconciliations to save reconciliation log

### Summary

When the seat link data from a self hosted instance arrives to the customers application, a look up for the particular order takes place and is saved in license `license_seat_links` table. 

As and when an order has to be reconciled, this entry is saved in the `reconciliations` table. This table acts as the audit and also helps in avoiding fetching the active users count from the `license_seat_links` table.


| Column Name | Column Type |
| ------ | ------ |
| Id | Primary key |
| order_id | References |
| active_users | Integer | 
| last_reconciled_at | DateTime | 
| reconciled_done_at | DateTime | 
| created_at | DateTime | 
| updated_at | DateTime |

Story points: 2.0
Research: Web Direct Opportunities Need Quote and Product Data

### Issue Summary

Looking at the data in SFDC we receive from the portal, we are only receiving shell Opportunities and Subscriptions. We are not receiving data for Zuora Quotes, Zuora Rate Plans, or Zuora Subscription Charges, all of which are critical for surfacing the current entitlements and metrics for our customers. This effects any customer who uses the portal, even partially.

We need to update the customers.gitlab.com to send us additional data when a Zuora transaction is triggered.


This is an engineering research issue to:

1. investigate the proposal
1. identify implementation
1. break out the tasks into the smallest available parts and create issues if needed

### Proposal

For every transaction in Zuora, we need a:

* Zuora Quotes
* Zuora Rate Plans
* Zuora Subscription Charges

* Quote Object (similar to the wrapper you send the Opp in)
* All Related `Amendments`
* All Related `Quote Rate Plans`
* All Related `Quote Rate Plan Charges`
* All Related `Quote Charge Summaries`
* All Related `Quote Charge Details`

We would also need to double check that post transaction the following objects are inserted / updated on the Account:

* All Related `Subscriptions`
* All Related `Subscription Product & Charges`

Story points: 2.0
Graduate gitlab_com_plan_upgrades from feature flag

<!-- 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

`gitlab_com_plan_upgrades` has been live for ~9 months now. And it's living behind a feature flag, meaning developers need to enable this locally to see the page.

This leads to oversights like https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1241

### Proposal

Given the feature has been stable for a long time; remove the feature flag from the code.

Story points: 1.0
UX: UI Issues in the Upgrade flow in Customers Portal

NOTE: This is the UX Design issue for https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1241

---
### MVC Proposal to fix spacing and alignment issues.

**[Design Specs](https://sketch.cloud/s/eMypz/v/aMML7r/a/GaeydO#Inspector)**

![Manage_Purchases_9__MVC__2x](/uploads/3e9d78b483827b19ca13f5b8593a2855/Manage_Purchases_9__MVC__2x.png)

@chris_baus @amandarueda @mkarampalas This is all Frontend work to help fix the current page. Font sizes, spacing and alignment. Let me know if you need anything else.

Story points: 1.0
UI Issues in the Upgrade flow in Customers Portal

### Problem
The upgrade flow that is available for .com subscriptions in the Customers Portal has a number of UI issues: 

![image](/uploads/1d3b7d2bec341c7be31f890ce7be075c/image.png)


1. The top padding appears to be too small 
1. The font size for the box that displays the current subscription info is very large and throws off the entire page layout 
1. The box for the current subscription seems artificially small and creates a large white space area to the right that is wasted space  

### Proposal
1. TBD based on UX recommendations but I imagine there will be font and layout changes required 


### Result

1. A better upgrade flow 

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Adopt `namespace:` over `group:` in UI

<!-- 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

Surfaced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1186#note_312872175

We're currently rendering `group: Group Name` and `GitLab group: Group name` when showing the namespace in the UI.

[Namespaces can also refer to personal accounts](https://docs.gitlab.com/ee/user/group/#namespaces), so `group: *` isn't always applicable.

![Screenshot_2020-03-31_at_11.21.20](/uploads/885201f396da47c2bfb9047854263fa2/Screenshot_2020-03-31_at_11.21.20.png)

### Proposal

* Always use `Namespace: *`

**or**

* Use `Namespace: *` as default, and `Group: *` when we **know** we're showing a group

Story points: 1.0
Do not render renew CTA for addon products only subscriptions

The following discussion from !1182 should be addressed:

- [ ] @rhardarson started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1182#note_313977257):  (+3 comments)

    > @timnoah can you perform a ~UX review here?
    > 
    > I can help you setup one of these GitLab training products locally if you want.


We're rendering a "Cancel subscription" CTA for subscriptions that only have CI minute purchases.
The CTA doesn't do anything, so we should not render it, to avoid confusion.

![Screenshot_2020-03-30_at_14.19.00](/uploads/2cad51db9799d26d122fb1ca31bf5542/Screenshot_2020-03-30_at_14.19.00.png)

Story points: 1.0
Add billing state to salesforce when the customers are created

### Problem

As part of saving the billing state to the salesforce and Zuora, this issue covers addition of the state to the lead service of sales force.

When a new customer is registered in the customer application, then the customer's data is send to Salesforce as part of lead generation.
https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/controllers/registrations_controller.rb#L12

[This data](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/services/create_salesforce_lead_from_customer_service.rb#L5) does not include `state` information captured when registering the user. 

### Proposal

Add `state` information when sending customers information during lead generation. Please not that the **state** param should not be sent when the country is different than USA or Canada, otherwise the validation on SFDC will fail the the SFDC account will not be created.

### Result

Salesforce is provided with the state information of the customer.

Story points: 1.0
When at least one credit card is on file, there should always be a default record

<!-- 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

The default payment method check-box is not enforced/required for a payment method, so the customer can have no default payment method. This shows up in the customers portal, where there is no `default` label on the `Payment methods` page:

![Payment_methods_no_default](/uploads/566dc9407bc20e8ec61f87655c72b1b3/Payment_methods_no_default.png)

There is also no indication that the check-box for default payment method is required on the edit screen:

![edit_cc_default_box](/uploads/8dd82e68600f9a37d11f88ce24ec9103/edit_cc_default_box.png)

Having no default payment method results in the following error message when the customer tries to make a payment:

![no-default-error-msg](/uploads/3be0ac4f2e58d4b3ed8b00e5f7f195fc/no-default-error-msg.png)

Examples of customers experiencing this issue:
1. https://gitlab.zendesk.com/agent/tickets/150464
1. https://gitlab.zendesk.com/agent/tickets/150933
1. https://gitlab.zendesk.com/agent/tickets/162460
1. https://gitlab.zendesk.com/agent/tickets/168829

### Proposal

Make it required to have one payment method to be set as default.

### Result

A default payment method will prevent customers from seeing the error message

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Change linked group button should not be available for CI Minute Subscriptions

### Summary

Thinking through CI minutes purchases, these should never change namespaces after original purchase:

1. They are provisioned on GitLab.com and we don't have a mechanism to deprovision them.
1. You cannot purchase CI minutes without indicating a namespace.
1. They are not transferable. ([docs](https://docs.gitlab.com/ee/subscriptions/#purchasing-additional-ci-minutes)) 

![Screen_Shot_2020-03-26_at_20.38.16](https://gitlab.com/gitlab-org/customers-gitlab-com/uploads/1afb7d3247e67737e72ef319e021e4a1/Screen_Shot_2020-03-26_at_20.38.16.png)

### Proposal
Remove the button from CI Minute Subscription widgets

Story points: 1.0
total_quantity causes errors in some contexts

User attempt to purchase CI minutes and gets an error, `We have found the following error while processing your subscription: Please enter a valid quantity.`
In spite of the error, a subscription is generated, an invoice is generated, the card is charged
The minutes are not applied to the GitLab.com group.

### Problem

### Proposal

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Research: Record Billing State when account is defined

### Issue Summary

When we define the account we do not define `Billing State` and therefore we do not pass data to Zuora and SFDC, we do not pass `Billing State`.


This is an engineering research issue to:

1. investigate the proposed solution
1. break out the tasks into the smallest available parts and create issues if needed

### Proposal

* Use the `Billing State` as per: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1135#note_297404665
* When the account is defined in the rails object also record the `Billing State`
* Ensure this state is passed to Zuora and SFDC

Story points: 2.0