giseldo/neodataset huggingface dataset:
Enable Pajamas styles without effecting non-migrated pages


<!-- 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/

-->

Related: https://gitlab.com/gitlab-org/customers-gitlab-com/issues/936

### Problem

How can we enable Pajamas styles without affecting non-converted pages (see overrides already introduced here https://gitlab.com/gitlab-org/customers-gitlab-com/blob/staging/app/frontend/stylesheets/_overrides.scss)

### Proposal

Determine strategy for preventing style bleedover.

* Ensure no naming overlap
* Ensure overrides are in place for name overlap 

### Result

We can turn `pajamas_design_system` on without effecting non-migrated pages

### Next steps (if any)

### How will we measure success?

Story points: 3.0
Rename Salesforce-related workers to use Salesforce namespace

The following discussion from !815 should be addressed:

- [ ] @jejacks0n started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/815#note_259585437):  (+1 comment)

    > Salesforce::CreateOpportunityWorker?
    > 
    > I know, let's not go renaming a worker without a shim, but introducing a Salesforce namespace makes some sense based on the rest of my review.

Story points: 2.0
Add %w[] to be the enforced syntax in Rubocop rules

### Problem

We see changes requested on MRs and we should add linting rules for these things when they come up so they don't delay or block MR reviews.

### Proposal

You can [see that a maintainer is looking for consistency](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/693#note_246783831) around using `%w()` vs. `%w[]`. A great way to handle this is to use linting rules. I propose we add this to the official linting rules if this is the case on the gitlab repo.

### Result

We'll see less comments on MRs around linting rules that are undefined and contributors will have less specific knowledge to be aware of.

### Next steps (if any)

Enjoy not having to think about this.

### How will we measure success?

Maybe less delays on MRs?

Story points: 1.0
Users should be able to purchase a .com plan while on trial

### Problem

This issue was addressed in https://gitlab.com/gitlab-org/customers-gitlab-com/issues/355 but unfortunately continues to exist. Users continue to submit tickets to support and we have manually disable the trial so they can purchase. 
 
![Screen_Shot_2019-12-12_at_5.24.29_PM](/uploads/0dcaee500709d9aa2136b7d0de051260/Screen_Shot_2019-12-12_at_5.24.29_PM.png)

### Steps to reproduce 
 
Have admin access to a free namespace > Start a trial in that namespace > select an upgrade option/navigate to the customers app > log in (creating separate issues for problems related to this) > select to purchase Bronze/Silver or Gold > attempt to upgrade the namespace that's active in the trial and you will be unable to it will be grayed out as seen in the screenshot above. 
 
### Proposal

Allow users to select their group during the purchase process even if the group is part of a trial.

Story points: 2.0
[Deprecate Zuora SOAP] Remove SOAP code in the workers

### Problem
Once the Zuora REST update is complete and the SOAP code is no longer needed, we will have plenty of unused legacy code that should be removed.

### Proposal
We can remove the Zuora SOAP API code and related feature flags. This issue focuses on cleaning up the SOAP logic and feature flags found in the workers which was added in #924.

As mentioned in [this discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/842/diffs#note_266564532), while we are removing the feature flag, we could also remove [the `Zuora::Invoice.invoice_files` method](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/842/diffs#6a78e4db8c9a26637fed7d2e2ae66f3fc6da5d50_9_14) in favor of an association (`with_many :invoice_files`) instead.

### Result
A cleaner code base with less feature flags.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
[Deprecate Zuora SOAP] Remove SOAP code related to the Zuora callback controller

### Problem
Once the Zuora REST update is complete and the SOAP code is no longer needed, we will have plenty of unused legacy code that should be removed.

### Proposal
We can remove the Zuora SOAP API code and related feature flags. This issue focuses on cleaning up the SOAP logic and feature flags found in the `ZuoraCallbacksController` which was added in #923.

### Result
A cleaner code base with less feature flags.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Structural testing of stories

<!-- 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/

-->

Our stories render our components in different scenarios and with different props.

This is a good chance to leverage [storyshots](https://storybook.js.org/docs/testing/structural-testing/) for smoketesting. Read: assert `this component renders without a runtime error`

I strongly recommend using [`renderOnly`](https://github.com/storybookjs/storybook/tree/master/addons/storyshots/storyshots-core#renderonly) to assert the stories since the snapshots will generate too much noise to be of any real use.

Story points: 3.0
Expose source maps to Sentry and reduce noise from ie11 errors

<!-- 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
Since Sentry does not have access to our javascript source-maps our Sentry bug reports point to a minified bundle.

This makes debugging needlessly hard.
### Proposal
Expose source-maps to Sentry.

Determine whether we should [host or upload source-maps](https://docs.sentry.io/platforms/javascript/sourcemaps/#hosting--uploading) to Sentry.

**Questions about hosting**

Many of our routes are behind an authentication: is this going to be a problem?

**Questions about uploading**

Our JS bundle is generated on a server outside of CI with [cookbooks](https://gitlab.com/gitlab-cookbooks/cookbook-customers-gitlab-com)

Do we need the same server to upload the source-maps?
Is source-map generation deterministic and can be hashed on content?

### How will we measure success?
We're able to make sense of error messages like https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1118262/?query=is:unresolved

Story points: 5.0
Investigate possibility of using JsRoutes for bringing routes to FE

<!-- 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 have nice and convenient way of getting corrects Rails routes on front-end side or in a Vue application.

### Proposal

Let's investigate possible usage of this gem - [JsRoutes](https://github.com/railsware/js-routes/issues/237)

Consider the simple Vue application that should send a request to the API endpoint `/countries`.  What are our options here to provide the correct route to this Vue application?

**First option: use `data-` attributes from HAML**

```haml
#js-app{ data: { country_end_point: countries_url } }
```

**Pros:**

* We pass the correct URL to the application;
* Changes on the backend will propagate to front-end without making changes to front-end

**Cons:**

* Additional property for the Vue application.

**Second option: `gon` gem**

```ruby
gon.routes = {
  countries_url: countries_url
}
```

```javascript
export default {
  name: 'JsApp',
  methods: {
    fetchCountries() {
      axios.get(gon.routes.countries_url);
    }
  }
}
```

**Pros:**

* We have the correct URL;
* We don't need to create an extra property in the Vue application;
* Changes on the backend will propagate to front-end without making changes to front-end

**Cons:**

* We have to manually add a new route to `gon`;
* We make our component "too smart" due to accessing the `gon` inside of it,

**Third option: JsRoutes gem**

```ruby
gon.routes = JsRoute.generate
```

```javascript
export default {
  name: 'JsApp',
  methods: {
    fetchCountries() {
      axios.get(gon.routes.countries_url);
    }
  }
}
```

**Pros:**

* We have the correct URL;
* We don't need to create an extra property in the Vue application;
* Changing the route on the backend doesn't affect the front-end.

**Cons:**

* Extra gem in our `Gemfile`;
* Possible exposing of protected routes.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 3.0
[REST Update] Move Subscribe and Contact service to use REST api

<!-- 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 services, viz., `SubscribeService`, `UpdateContactService` and `LicenseNotificationService` is accessing zuora objects using SOAP apis.

### Proposal
Modify the services to use IronBank objects instead.

Also, please verify if any other service has been missed in the above list.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
[REST Update] Move workers to use REST api

<!-- 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 workers, viz., `CreateSalesforceOpportunityWorker`, `CreateAmendmentWorker`, `BulkDownloadInvoice` is accessing zuora objects using SOAP apis.

### Proposal
Modify the workers to use IronBank objects instead.

Also, please verify if any other worker has been missed in the above list.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
[REST Update] Update Zuora callback controller to use REST apis

<!-- 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 zuora callback controller finds subscription using SOAP api.

### Proposal
Update the api call to use the IronBank query instead.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 1.0
[REST Update] Move mailers to use REST apis

<!-- 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
AdminMailer and CustomerMailer currently fetch records using SOAP apis. 

### Proposal
Add support for the mailers to fetch records from IronBank instead.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
[REST Update] Download of Invoice files in Payment History page

<!-- 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
Download of invoices is currently using SOAP apis.

### Proposal
Move the download and display of Invoice files in ReceiptsController to use REST apis from IronBank gem.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Add Vue integration to Sentry

<!-- 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/

-->

With a [Vue integration](https://docs.sentry.io/platforms/javascript/vue/) to Sentry we can get a more detailed error report when something breaks in Vue.

Story points: 1.0
Ensure SentryJS does not break local development

<!-- 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're loading Sentry from a CDN https://gitlab.com/gitlab-org/customers-gitlab-com/blob/staging/app%2Fviews%2Fshared%2F_sentry_js_lib.html.haml and exposing it on a global level.

That means that manually calling `captureException` for example in [`payment_methods_plugin`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/staging/app/assets/javascripts/payment_methods_plugin.js#L90) reaches for a global `Sentry`.

Since Sentry is not active in local development, this causes an `undefined` error, which hides what the underlying error actually was.

### Proposal
Package Sentry in an NPM package and ensure it does not break local development.

Not breaking local development is built-in to Sentry, so if we follow the documented setup route; we should be fine.
### Result

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Update frontend packages regularly

We had a meeting with @leipert about when and how often the project's dependencies should be updated.

The [meeting agenda](https://docs.google.com/document/d/17_xKVL37ao3RAb2N-L7RiYeTIUnSRLmw4eeHSxOWh44/edit) contains drawbacks, benefits and concerns about this topic.

What @leipert suggested we do is to start with gitlab's packages (`@gitlab/ui` and `@gitlab/svgs`) and enable renovate bot to send MRs.

It could start smaller and safer by enabling the bot to update some of the devDependencies like eslint and all related packages, if all went smoothly for couple weeks then we can increase the volume of the packages being updated regularly.

### Proposal

Setup renovate bot to start sending MRs about updated packages.

### Result

Relatively up to date packages, with smaller changes at a time.

### Next steps (if any)

- Schedule the task at a milestone.
- Decide which packages to start with.
- The assignee can consult with @leipert if they needed help.

### How will we measure success?

Story points: 6.0
Handle save failures on updating default payment method - throw and handle exception

The following discussion from !620 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/620#note_256094641): 

    > You may have already thought about this but I wanted to highlight that this `save!` would have thrown an error before if the save failed, whereas our REST implementation does not.  I tried tracing this upstream and it doesn't appear that we really handle these error gracefully.  I'm also not sure how much it actually occurs.  It may not be worth changing what you've done but we could create a followup ~"technical debt" issue for gracefully handling this error.  WDYT?

Story points: 1.0
Change /receipts to /invoices, implement a redirect

<!-- 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 currently have page within the customers portal with the URL `/receipts` that does not actualyl display receipts. It displays invoices. We are updating the front end link titles as part of the pajamas migration to say `View Invoices` but without updating the URL to `/invoices` we may generate some confusion for customers. 

### Proposal
* Change `/receipts` to `/invoices` 
* Implement a redirect on `/receipts` to take users that directly navigate via bookmark/history to `/invoices`

### Result
URLs and link titles reference the same thing - invoices

### Next steps (if any)
* Monitor traffic to `/receipts` and when it gets down to a small number (ex: <10 in a month) remove the redirect

Story points: 2.0
[REST Update] Incorrect value stored when updating a Zuora resource's attribute with `nil` value

The following discussion from !666 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/666#note_255369755):  (+1 comment)

    > I noticed a bug when testing this on staging after the deploy.  When the `opportunity_id` being updated on the Zuora subscription is `nil`, the resulting value is stored as `"userdata: NULL"` through the REST API logic instead of `nil` as it did with the SOAP logic.  This isn't a blocker for this rolling to production as it's behind the feature flag.  I wanted to note that I'll open an issue to tackle it now.

Story points: 1.0
Add a test that renders the receipts index action

### Problem
An [MR](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/741/diffs) was introduced that broke the receipts index action.  There was no test coverage for that view so we were unaware the page was broken after deployment to production.  

### Proposal
[We've since reverted the MR](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/788), but as suggested by @jejacks0n, we should at least add test coverage for the receipts index action to avoid this happening in the future.

### Result
Better test coverage, preventing future outages.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
[Deprecate Zuora SOAP] Remove active_zuora gem and references

### Problem
Once the Zuora REST update is complete and the SOAP code is no longer needed, we will have plenty of unused legacy code that should be removed.

### Proposal
Ensure that no `active_zuora` related code is still in use (e.g. look for references to `Z::`).  Remove all code using `active_zuora` and remove the gem dependency.

Also, remove any remaining references to the `zuora_rest_api` feature flag ([including the default state for specs](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/bd8553ec262bbccf24710272d0bac51fa7da22d7/spec/spec_helper.rb#L21)) or [the `zuora_rest_api` metadata tag](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/staging/spec/rails_helper.rb#L57) in the test suite.

### Result
A cleaner codebase. :sparkles: 

### Next steps (if any)

### How will we measure success?

Story points: 2.0
[Deprecate Zuora SOAP] Remove SOAP code related to listing subscription

### Problem
Once the Zuora REST update is complete and the SOAP code is no longer needed, we will have plenty of unused legacy code that should be removed.

### Proposal
We can remove the Zuora SOAP API code and related feature flags.  This issue focuses on cleaning up the SOAP logic and feature flags related to listing subscriptions which was added in #761.

### Result
A cleaner code base with less feature flags.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
[Deprecate Zuora SOAP] Remove SOAP code related to subscription amendments

### Problem
Once the Zuora REST update is complete and the SOAP code is no longer needed, we will have plenty of unused legacy code that should be removed.

### Proposal
We can remove the Zuora SOAP API code and related feature flags. This issue focuses on cleaning up the SOAP logic and feature flags related to subscription amendments which was added in #758.

### Result
A cleaner code base with less feature flags.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
[Deprecate Zuora SOAP] Remove SOAP code related to subscription updates

### Problem
Once the Zuora REST update is complete and the SOAP code is no longer needed, we will have plenty of unused legacy code that should be removed.

### Proposal
We can remove the Zuora SOAP API code and related feature flags.  This issue focuses on cleaning up the SOAP logic and feature flags related to subscription updates which was added in #759.  [As suggested here](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/666#note_254197888), we can also remove the `Subscription.update` class method as it is no longer needed with the REST implementation.

### Result
A cleaner code base with less feature flags.

### Next steps (if any)

### How will we measure success?

Story points: 2.0