giseldo/neodataset huggingface dataset:
Users should be able to enter credit card cvc with leading zero

### Problem
When user enters the details for a credit card in the `Edit` form within the customers portal, if the CVC has a leading `0`, the form strips the 3-digit entry of the zero and leaves only the 2-digit entry. 

When the user submits the form to save the details like this, they receive this error: `Body: [{"Errors"=>[{"Code"=>"TRANSACTION_FAILED", "Message"=>"Transaction declined.invalid_cvc - Your card's security code is invalid."}], "Success"=>false}]`

### Proposal
We should not remove the leading zero from CVC codes.

Story points: 1.0
Create a mapping of interactions between the Customer Portal to Zuora and Salesforce.


### Problem

Our internal teams do not have documentation to help them understand all of the interactions between the Customer Portal, Zuora, and Salesforce. 
### Proposal
Create a mapping so that we can start to determine where the gaps are currently with data flowing between the systems.


### Result
Identify new issues and opportunities for improving data flow and processes. 


### Next steps (if any)
Time boxed effort to provide the mappings. 

These materials may help: 
* https://drive.google.com/drive/folders/1kfCEQM6XYGWYxq3Ke4TNvtmDR-46erVD
* https://about.gitlab.com/handbook/business-ops/business_systems/portal/#zuora-and-salesforce 

### How will we measure success?

Story points: 2.0
Hook staging environment up to Salesforce sandbox


### Problem
Our staging environment is not hooked up to the Salesforce sandbox that was recently provisioned. This makes testing changes that could impact the flow of data to Salesforce difficult and we often find issues in production that could'be been caught in staging if we had a better way to test them.


### Proposal

Per @tyleramos: This might not be too difficult now that we have access to the salesforce sandbox. This might just be a matter of updating some credentials in the `stg` environment and testing it out. Probably a weight of 1 for our team. It'll probably require opening a ticket with infrastructure to get the credentials added to the chef vault so we might be delayed by that.

### Result

Once we have a functional place to do testing, we can reliably develop new features incrementally.

### Next steps (if any)

### How will we measure success?

Story points: 0.0
Fix broken CI related to postgres image

### Problem
As of the last hour or so, we are seeing errors like the following in CI:
```
PG::ConnectionBad: could not translate host name "postgres" to address: Name or service not known?
```

Example: https://gitlab.com/gitlab-org/customers-gitlab-com/pipelines/118021482

### Proposal
The underlying problem and fix has already been applied for gitlab with https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25274.  A similar fix would probably solve it for customers.gitlab.com.

### Result
A functional CI.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
GitLab.com users should be able to purchase additional users without adding members

There are many instances when a user wants to purchase additional users for their GitLab.com subscription even though the users don't exist in their system yet. When this occurs, we have to defer the user to sales to issue a sales-assisted quote for the sale.

For example, when trying to use the rest of the money in their budget for the quarter/year, when planning on ramping up employees but they are not yet hired, etc.

Like the self-managed `Add more seats` workflow, we should offer GitLab.com users the ability to purchase prorated users without having to add them to their system.

---

## ROI

* [ ] IACV 
* [ ] Cost Reduction
* [x] Sales Efficiency: [$50k in first 90-days post implementation](https://docs.google.com/spreadsheets/d/1fLu95rdXLa1Y9zq5oI86AAneVsdMctB7NA7EAb7UgLM/edit?usp=sharing)
* [ ] Other

### Testing and Availability

This issue seems to be from a pure frontend perspective. UI tests to add (page rendering validation and purchase flow):

#### On Customer Portal
- `Add more seats` button shows for active .com subscription
- Subscription start/expire/renewal date remains the same
- Subscription renews with correct quantity (original + seats added)

#### GitLab.com -> Billing page
- Total seat quantity for a subscription is updated with successful purchase
- Seats remains the same if purchase did not go through

e2e Test tracked via #1772

Story points: 3.0
Adjust countries/states components to be reused in "Sign in/Registration" Page

The following discussion from !967 should be addressed:

- [ ] @vitallium started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/967#note_287387305):  (+3 comments)

    > We can use existing Vue components for countries and states here. WDYT, @aalakkad?

We have these 2 points regarding countries/states components:

1. no straight forward way to set the `name` attribute for the rendered select.
1. couldn't save the selected country to the main app to pass it to the state select component.

Story points: 3.0
Provide a callback from Zuora when the subscription is cancelled.

### Problem
Currently, An admin from Zuora can go to admin panel and can cancel a running subscription. This subscription is then not shown on the manage subscription page on the customers portal and the corresponding GL namespace is still using the paid plan. 

### Proposal
To add a new callback in the customers portal called from Zuora when the subscription is cancelled (or deleted) which will update the Order table and also make a call to the GL namespace updating its plan information. 

### Result
corresponding .com subscription is downgraded to free/cancelled

Story points: 2.0
Evaluate SentryJS initialization

https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/924 moved Sentry to a separate webpack entrypoint and inserts a script tag via `javascript_pack_tag`

However mixing `javascript_pack_tag` and `javascript_packs_with_chunks_tag` with [`splitChunks`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/config/webpack/environment.js#L39) enabled is a no-go.

https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1013 addresses this issue.

It's worthwhile to evaluate the best strategy for loading and initializing SentryJS.

Additionally it'd be great to find a strategy for testing SentryJS is active in production; so we don't have the error service go down for a week without noticing it.

Story points: 3.0
Ensure amendment error messages are JSON serialized

<!-- 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

Currently we're passing the IronBank error message to the frontend and rendering it on failure.

![Screen_Shot_2020-04-30_at_17.51.21_copy](/uploads/35875d2ecc65a62c57dbbbbbe056910f/Screen_Shot_2020-04-30_at_17.51.21_copy.png)

There are quite a number of purchase routes that need to be covered here.

### Steps to reproduce

1. Navigate to Buy more CI minutes for an active subscription (bronze for example)
1. Try to purchase with card that will decline: `4000 0000 0000 0002` **note that this needs to be selected from the dropdown; adding a new credit card that will decline will not cause this bug**
1. Note the error message

### Proposal

Provide error message so that users know what's going on.

### Result

### Next steps (if any)

### How will we measure success?

Customers know why they cannot continue with their purchase and able to proceed to corrective action (change/update credit card information) themselves without contacting support.

Story points: 3.0
Spike: Determine approach for creating restricted view of the license database

### Problem

In order to better protect customer data, we should enable restricted views of the license database so GitLab team members can be removed from having access to production customer data, while still being able to support customer issues.

### Proposal

* Create a "middle view" where customer PII information is scrubbed from the database, allowing for debugging / troubleshooting without access to sensitive customer information.

This issue is to determine the technical approach and should involve reviewing the proposal with stakeholders to ensure we are solving the problem fully and correctly.

### Result

Understanding of next steps and technical implementation details

Story points: 2.0
Change find by zuora account id to salesforce subscription id

<!-- 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 found that what was previously labeled as the zuora account id in the version application is actually the salesforce subscription id in the customers application. 

### Proposal

Change the rails admin finder override to use salesforce account id instead of zuora account id


### How will we measure success?

Ability to link from version application successfully to admin area on customers app.

/cc @timhey

Story points: 1.0
Consider enabling eager loading in dev and/or test environments

### Problem
In [a recent discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/972#note_280295821) in !972, @oswaldo raised a valid point about enabling eager loading in the dev and/or test environments to avoid a bug where some `Zuora::` namespaced classes have not been loaded.  In the interest of fixing that particular bug quickly to avoid CI errors, we decided to move forward with the solution of using `const_get(resource_name, false)`. See !972 for more information on the specific error and solution.

### Proposal
Another potential solution would be to enable eager loading in Rails which would ensure those Zuora classes (and others) are loaded just as they are in Production.  It's worth considering the implications of enabling this setting in both environments.  A potential downside is the longer boot time in Rails but it might not be prohibitive.  Part of this issue should be reaching out to the team for consensus on this topic.  For perspective, the GitLab code base eager loads in the test environment but not development.

### Result
All classes are loaded up front which is more consistent with Production usage.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Intermittent CI rspec failures with `IronBank::Authentications::Token::InvalidAccessToken`

### Problem
Since we've [enabled the `zuora_rest_api` feature flag by default in rspec](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/916), we've seen flakiness in some tests with the error `IronBank::Authentications::Token::InvalidAccessToken`.

Here's an example of the failure: https://gitlab.com/gitlab-org/customers-gitlab-com/-/jobs/420976521

### Proposal
The credentials for the Zuora API user are valid so we should investigate what leads to this error.  One thing to look at is the session caching in `IronBank`.

### Result
A more stable CI Pipeline.

### Next steps (if any)

### How will we measure success?

Story points: 3.0
NoMethodError: undefined method `access_token' for nil:NilClass

https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1100779/

```
NoMethodError: undefined method `access_token' for nil:NilClass
  app/services/gitlab/namespace/list_service.rb:13:in `execute'
    return unless @customer.access_token
  app/helpers/gitlab_plans_helper.rb:86:in `gitlab_namespaces'
    @gitlab_namespaces ||= Gitlab::Namespace::ListService.new(current_customer).execute(params[:plan_id]) # rubocop:disable Rails/HelperInstanceVariable
  app/helpers/gitlab_plans_helper.rb:9:in `gitlab_namespace_options'
    gitlab_namespaces
  app/views/subscriptions/new_extra_ci_minutes_plan.html.haml:29:in `_app_views_subscriptions_new_extra_ci_minutes_plan_html_haml___1101725331863083723_87541060'
    = select_tag 'gl_namespace_id',
  app/controllers/application_controller.rb:99:in `render_custom_or_default_template'
    render name
...
(108 additional frame(s) were not displayed)

NoMethodError: undefined method `access_token' for nil:NilClass
```

Story points: 0.0
Update documentation about feature flags

### Problem

Right now we get 500s and permission denied errors in the app when enabling a feature flag via `root` - https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1212441/

### Proposal

Update the documentation to make sure files are written as `gitlab-customers` when enabling this via the console

### Result

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Cannot enable Auto-Devops on this project without Container Registry enabled

### Problem

The container registry was disabled on this project for security reasons.

With the container registry disabled, Auto-Devops cannot build an image for this application.  This is the error:

```
$ /build/build.sh
322 Logging to GitLab Container Registry with CI credentials...
323 WARNING! Using --password via the CLI is insecure. Use --password-stdin.
324 WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
325 Configure a credential helper to remove this warning. See
326 https://docs.docker.com/engine/reference/commandline/login/#credentials-store
327 Login Succeeded
328 Building Heroku-based application using gliderlabs/herokuish docker image...
329 invalid reference format
330 invalid reference format
331 invalid argument "/enable-autodevops:c539778ab1e155e7d621e7e45feee9bfa43ca507" for "-t, --tag" flag: invalid reference format
332 See 'docker build --help'.
```
![Screen_Shot_2020-01-29_at_12.58.36_PM](/uploads/83ad012505eef40b4722de232eeab85b/Screen_Shot_2020-01-29_at_12.58.36_PM.png)

When the above setting is turned on, the build proceeds.


### Proposal

In order to use Auto Devops, we need to do one of the following:

- Decide that the risk is acceptable and enable the registry
- Take the project private so that the registry is private, and enable the registry
- Implement more granular permissions on the registry and enable it

This open issue regarding registry permissions is 3 years old: https://gitlab.com/gitlab-org/gitlab/issues/878

There is also one regarding private/public registries: https://gitlab.com/gitlab-org/gitlab/issues/19585

### Result

Somehow, the registry will need to be on for Auto Devops to be enabled.

### Next steps (if any)

Temporarily enabling the registry results in Auto-Devops working, so we know that turning it on will unblock the Auto-Devops work.  We just need to decide how we are going to do that.

Story points: 0.0
Follow-up from "Adjust font sizes for the new nav bar"

The following discussion from !957 should be addressed:

- [ ] @vitallium started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/957#note_278318558):  (+1 comment)

    > @timnoah, could you please review changes in this merge request? Thanks!

Story points: 1.0
Subscription names with non-standard characters result in 404s when purchasing/upgrading

### Problem
In some cases, strange characters in a subscription name aren't handled correctly.

See https://gitlab.com/gitlab-com/support/dotcom/dotcom-internal/issues/1477 where a customer with a `+` in their name triggered this.

### Proposal
Handle these more gracefully :wink: 

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Gracefully handle errors when fetching GitLab namespaces

### Problem
There was recently a hiccup in the GitLab namespace service that caused unhandled errors in the customers portal for purchases.
https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1100780/?query=is:unresolved

This is reproducible locally if you try to purchase CI minutes or any .com plan with GDK turned off.

### Proposal
Gracefully handle errors when the GitLab service is unreachable or returns an error code.  We could display a helpful message on the page instead of erroring.

### Result
A better UX in the purchase workflow when GL.com is down.

### Next steps (if any)

### How will we measure success?

Story points: 3.0
Daily pipeline run fails due to empty vcr cassettes

### Problem
There is a [daily pipeline](https://gitlab.com/gitlab-org/customers-gitlab-com/pipeline_schedules) run at 9:00 am UTC which runs the rspec job with `VCR=all`. This job always fails due to some vcr cassettes not being able to be recreated. Some cassettes require a date bump in the spec file and others are not recreatable.

The failing of the pipeline is noticed because there is now a deployment status entry in the `#g_fulfillment_status` slack channel. This is the [slack discussion](https://gitlab.slack.com/archives/CL7SX4N86/p1579944896005700) for this issue.

Example of a failing daily pipeline run: https://gitlab.com/gitlab-org/customers-gitlab-com/pipelines/112228583

### Proposal
We should try to fix this and make the daily pipeline run pass.

### Result
Passing pipeline for the daily pipeline job.

### Next steps (if any)

### How will we measure success?

Story points: 3.0
Follow-up from "Fixes an issue with id not always being string"

The following discussion from !940 should be addressed:

- [ ] @jackie_fraser started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/940#note_276736235):  (+6 comments)

    > I'm not sure if this quite makes sense because the return value has changed from false to nil.
    > The true/false response would actually need `(/[a-fA-F]/).match?(id.to_s)`

We should add addition test coverage to `spec/features/rails_admin/customer_show_spec.rb`.

Story points: 1.0
Rely more on Zuora object factories to create zuora records in tests

The following discussion from !928 should be addressed:

- [ ] @dstull started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/928#note_276608606):  (+1 comment)

    > **not blocking:** Wonder if we could leverage a `trait` in the `customer` factory to remove the need for   using the `create_zuora_account` helper here...and perhaps altogether as I see it defining instance variables and such as well - which I try to avoid doing in tests as they have a tendency to leak and lead to flaky testing.
    > 
    > maybe something like this in the customer factory?
    > 
    > ```
    >     trait :with_real_zuora do
    >       zuora_account_id  { create(:z_account, :with_contact).id }
    >     end
    > ```
    > 
    > then something like this in the `:z_account` factory?
    > 
    > ```
    >     trait :with_contact do
    >       after(:create) do |record|
    >         zuora_contact = create(:z_contact, account_id: record.id)
    >         create(:z_payment_method, account_id: zuora_account.id)
    >         record.update_attributes!(
    >           status: 'Active',
    >           bill_to_id: zuora_contact.id,
    >           sold_to_id: zuora_contact.id
    >         )
    >       end
    >     end
    > ```
    > 
    > the above is just a start, but gets toward using factories a bit more


That being said, the main code smell comes from the `instance variables` of `module ZuoraTestHelpers`. So the ultimate goal is to eliminate all instance variables from `ZuoraTestHelpers`.

But this issue will limit the scope to be: add the FactoryBot for Zuora account, and use the factoryBot in `some` of the specs. 

To achieve the ultimate goal of `removing all instance variables from ZuoraTestHelpers`, it requires lots of specs to re-run VCR re-recording. Due to the complexity and effort is non-trivial, we will avoid this part in this issue. We leave the ultimate goal in another follow-up issue [Remove instance variables from spec/support/helpers/zuora_test_helpers.rb](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2306) for the next step.  BTW: with the MR https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2229 , we could already remove all `destroy_zuora_records` from `ALL` specs, per https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2229#note_468181231. But this is not urgent. And it will naturally happen in issue https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2306 anyway.

Story points: 3.0
Spike: Determine approach for creating restricted view of the customers database

### Problem
In order to better protect customer data, we should enable restricted views of the customers database so GitLab team members can be removed from having access to production customer data, while still being able to support customer issues.


### Proposal
* Create a "middle view" where customer PII information is scrubbed from the database, allowing for debugging / troubleshooting without access to sensitive customer information. 

This issue is to determine the technical approach and should involve reviewing the proposal with stakeholders to ensure we are solving the problem fully and correctly. 


### Result
Understanding of next steps and technical implementation details

Story points: 2.0
Subscriptions cannot be created when Zuora REST API feature turned on

### Problem
When the `zuora_rest_api` feature is turned on, users are not able to purchase subscriptions.  This feature was newly introduced by !829 but it's not currently breaking in production as the feature is not turned on at the moment.

### Proposal
Adjust specs in `subscriptions_controller_spec.rb` to run with the feature flag turned on or off, which should highlight the bug, then fix the bug.

### Result
A functional purchase process for subscriptions when the REST feature is enabled.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Enable customers to be found by zuora_account_id under the admin path

<!-- 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 way to find the customer's account in the customers application from the version application.

### Proposal

Use the Zuora account id that the version application has access to, and use that to find the proper customer account in the admin area of the customers application.

### Result

Provides a linkable url for the version application to reference: `https://customers.gitlab.com/admin/customer/:zuora_account_id`

### Next steps (if any)

Use this path in https://gitlab.com/gitlab-services/version-gitlab-com/issues/206 

/cc @timhey

Story points: 3.0