giseldo/neodataset huggingface dataset:
Combine all frontend files under app/frontend

This is a follow up to a discussion started in https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/547#note_233805127

I'm thinking about moving all the javascript code in an MR from `app/assets/javascript` to `app/javascript` so all JS will be in one folder instead of being spread on 2 folders.

@vitallium suggested that if we are going to do that the better name will be `app/frontend` because we will add styles there too. But I like the idea of moving JS from `app/assets`.

Do you mind combining everything related to the frontend (JS, Sass, tests) including webpacker's entry points `app/javascript/pack` under one `app/frontend` folder?


### Update

We will gradually adopt this structure while we work on &1788.

The file structure will look similar to:

```
frontend
├── packs
├── javascripts
├── javascripts
│   ├── account
│   │   ├── components
│   │   │   ├── account_app.vue
│   │   │   └── personal_details_form.vue
│   │   ├── constants.js
│   │   ├── index.js
│   │   ├── mixins
│   │   ├── services
│   │   └── store
│   │       ├── actions.js
│   │       ├── getters.js
│   │       ├── index.js
│   │       ├── mutation_types.js
│   │       ├── mutations.js
│   │       └── state.js
│   └── pages
│       └── customers
│           └── edit.js
└── stylesheets
    ├── components
    │   └── _buttons.scss
    └── pages

```

Story points: 1.0
Follow-up from "Bootstrap version 4" - Rename plan-info-panel to plan-info-card

The following discussion from !545 should be addressed:

- [ ] @ClemMakesApps started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/545#note_233455706): 

    > We should probably as a follow up issue rename `.plan-info-panel` to `.plan-info-card`


We have an unfortunately named class `.plan-info-panel` in `subscription_upgrades/_plan.html.haml`.
This is because [`panels` have been renamed to `card`](https://getbootstrap.com/docs/4.0/migration/#panels-thumbnails-and-wells) in Bootstrap 3 -> 4.

# Definition of done

`plan-info-panel` has been renamed to `plan-info-card` in HTML and JS references.

Story points: 1.0
Use `autoprefixer` for CSS

<!-- 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 need to manually add vendor specific prefixes https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/558#note_232562193

This is a manual and error-prone process.

Instead we should use [autoprefixer](https://github.com/postcss/autoprefixer)

### Proposal
~~Investigate whether it makes sense to add `autoprefixer` via Gems or NPM dependency (serve it directly to `webpacker`)~~

We should use a NPM solution https://gitlab.com/gitlab-org/customers-gitlab-com/issues/785#note_233197359

### Next steps (if any)
Enable `stylelint` https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/558
### How will we measure success?

Story points: 3.0
Sign up page is broken on mobile devices

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label in relevant trackers:

- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=bug
- https://gitlab.com/gitlab-org/customers-gitlab-com/issues?label_name%5B%5D=bug

and verify the issue you're about to submit isn't a duplicate.

Do not include confidential information! 
--->

### Summary

Invisible `Country` select due to applied ad-hoc workaround for triggering HTML5 validation on `chosen-js` selects.

### Steps to reproduce

1. Navigate to https://customers.gitlab.com from a mobile device or by using device emulation in a browser;
2. Click `Sign in` from the top right hamburger menu;
3. Click `Register now` in the bottom.

### What is the current *bug* behavior?

See the missing `Country` select.

### What is the expected *correct* behavior?

You should able to see the `Country` select and interact with it.

### Relevant logs and/or screenshots

![Screen_Shot_2019-10-19_at_15.53.34](/uploads/24838b673aef3a7f974e651529a9d2d8/Screen_Shot_2019-10-19_at_15.53.34.png)

### Workarounds

Remove our ad-hoc solution for `chosen` selects.

### Reported examples

None

### Additional information

[`chosen` is disabled](https://github.com/harvesthq/chosen/pull/1388) on mobile devices such as iPhone, iPad.

<!---
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
Refactor Bulk download invoice to use REST APIs

The following discussion from !399 should be addressed:

- [ ] @asubramanian1 started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/399#note_230282933):  (+2 comments)

    > @oswaldo: Soooooo, I did some load testing with production credentials to see how long it takes to run for a month's data, and below are some inferences:
    > 
    > Initially, the job was querying for accounts for a given entity, and iterated through each of them to fetch invoices for them during the given time period.
    > 
    > Apparently, the query to return accounts for `US` entity takes way too long (waited for almost 20mins just to query for the account ids - this could be because there are too many accounts in this entity). The query ran quick for other entities though, which has less number of accounts:
    > 
    > ![Screen_Shot_2019-10-15_at_2.26.20_AM](/uploads/20b35703e3b4f0c146db9b4bd70efe3e/Screen_Shot_2019-10-15_at_2.26.20_AM.png)
    > 
    > Thus, I have modified the querying logic to: 
    > 
    > 1. Query invoices during the time period
    > 2. Check if the account of the invoice belongs to the given entity. If not, skip.
    > 3. If yes, download the pdf file for the invoice
    > 
    > It took **40 mins** to download invoices for **32 days**, total records processed: **2603**.
    > 
    > ![Screen_Shot_2019-10-15_at_2.49.28_AM](/uploads/8fafdbf4b8c4d1f0bc2694593ceb1d65/Screen_Shot_2019-10-15_at_2.49.28_AM.png)
    > 
    > The average number of invoices for a month is: 1663, maximum being 2438. Trend being:
    > 
    > ![Screen_Shot_2019-10-15_at_2.58.19_AM](/uploads/8675b5ae7c925316910a01e08f2fa6e1/Screen_Shot_2019-10-15_at_2.58.19_AM.png)
    > 
    > We can setup expectation with the Finance team that the report would be available within an hour - the request is for a month duration as mentioned in the issue (https://gitlab.com/gitlab-org/customers-gitlab-com/issues/504).
    > 
    > Let me know your thoughts.
    > 
    > Edit: Would have preferred to do a join in this situation, but for the [limitations](https://knowledgecenter.zuora.com/DC_Developers/BC_ZOQL), it won't be possible :(

Story points: 5.0
Change "Name" to "Namespace path" in GitLab Groups

### Problem

GitLab.com support team uses the `Gitlab Groups` view to get quick information about the customer. It would be much more helpful if the `namespace path` was listed instead of (or in addition to) the `name`.

### Proposal

Change the `name` field to `namespace path`

![Screen_Shot_2019-10-18_at_10.14.45_AM](/uploads/d213e10d5a99d7bd2cc0e92bdb42220c/Screen_Shot_2019-10-18_at_10.14.45_AM.png)

Story points: 1.0
Ensure payment errors are propagated to the 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
We're seeing errors in `onSubscriptionError` like [this Sentry error report](https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/234458/?query=cannot%20read) and [this](https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1000451/?query=cannot%20read)

Looking at the function nothing seems off at first glance.

```
// subscription_form.js
function onSubscriptonError(errors) {
  if (errors.attributes && errors.attributes.indexOf('coupon') >= 0) {
    $('#coupon-error').text('Invalid code');
  } else {
    ZuoraSubscriptionErrorHandler.redirectToErrorPage(errors);
  }
}

````

This fatal error is occurring because `onSubscriptonError` (I also just noticed there's a typo there) is being called with with an `undefined` object.

This happens in the callback here
```
// subscription_form.js
ZuoraSubscription.update(data, result => {
    if (result.success) {
      on_success(result);
    } else {
      onSubscriptonError(result.errors);
    }

    window.scrollTo(0, 0);

    // Whatever the response is always enable the submit button
    $('#preview-subscription').removeAttr('disabled');
  });
```

#### What does the user see?
The user just sees the loading page spinning without resolving

#### How should we have noticed this?
- Look at Sentry error reports; however [this isn't part of our workflow](https://gitlab.com/gitlab-org/customers-gitlab-com/issues/714)
- Have tests in place for this scenario
- Use static types to catch these problems; *If static type checking was in place the computer would catch this error before we'd ship this piece of code*

### Proposal
A patch here is to ensure we're not passing `undefined` to `onSubscriptonError`
```
onSubscriptonError(result.errors || {code: 500, message: 'Unknown error occurred, this has been logged in our service; Please open a Support ticket if the problem persists' });
```

The more serious problem is that we didn't catch this sooner.
We should
- Incorporate Sentry into our workflow (all fulfillment engineers should have Sentry notifications on? Open tickets automatically for new error reports?)
- Increase our test coverage
- Seriously consider adopting something like TypeScript

Story points: 2.0
Reflected XSS on customers.gitlab.com

**[HackerOne report #715760](https://hackerone.com/reports/715760)** by `badshah_` on 2019-10-16, assigned to @cmaxim:

### Summary

I found a reflected XSS at the GET endpoint **https://customers.gitlab.com/subscriptions/new?plan_id=2c92a0ff6145d07001614efff26d15da&transaction=create_subscription**

### Steps to reproduce

For firefox please visit the following url:

`https://customers.gitlab.com/subscriptions/new?plan_id=2c92a0ff6145d07001614efff26d15da&transaction[1%27%3E%3C/div%3E%3Csvg%20onload=alert(%27badshah%27);%27%3E]=%27%22`

![Firefox.png](https://h1.sec.gitlab.net/a/595a98c7-e509-4275-bcc0-93891bd6a0fe/Firefox.png)

For Chrome please visit the following url:

`https://customers.gitlab.com/subscriptions/new?plan_id=2c92a0ff6145d07001614efff26d15da&transaction[1%27></div><svg><discard%20onbegin=alert(%27badshah%27);%27>]=%27"`

![Chrome.png](https://h1.sec.gitlab.net/a/4ad7003c-27dd-416a-b40c-534f7999887d/Chrome.png)

## Impact

- Session takeover of authenticated victims. As this is a portal to manage subscriptions it would give the attacker more information like linked Gitlab account, etc.

If you are on Firefox, load the following `https://customers.gitlab.com/subscriptions/new?plan_id=2c92a0ff6145d07001614efff26d15da&transaction[1%27%3E%3C/div%3E%3Cscript%3Eprompt(document.cookie)%3C/script%3E%3C%20=%27;%27%3E]=%27%22`. This will display all the cookies.

![Session_takeover.png](https://h1.sec.gitlab.net/a/a1bac5b3-a207-4a08-8c4b-3c6a1812dc2d/Session_takeover.png)

- Malicious javascript execution on victim's browser

## Attachments

**Warning:** Attachments received through HackerOne, please exercise caution!

* [Firefox.png](https://h1.sec.gitlab.net/a/595a98c7-e509-4275-bcc0-93891bd6a0fe/Firefox.png)
* [Chrome.png](https://h1.sec.gitlab.net/a/4ad7003c-27dd-416a-b40c-534f7999887d/Chrome.png)
* [Session_takeover.png](https://h1.sec.gitlab.net/a/a1bac5b3-a207-4a08-8c4b-3c6a1812dc2d/Session_takeover.png)

Story points: 3.0
Subscription should be amended instead of created when changing Group for a GL.com subscription

### Steps

1. Create two groups, Group A with 1 member and Group B with 2.
1. Purchase a Bronze subscription for Group A.
1. After subscription is created, change the linked Group to Group B.
1. Complete the payment step.


### Expected

The original subscription is amended and Group A is assigned the Free plan.

### Actual

A new subscription is created for Group B and Group A maintains his paid plan.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
500 error during impersonation

### Summary

The customers portal is throwing a `500` error when attempting to impersonate various customer account. I've noticed this is happening more and more frequently and is really impeding our ability to assist customers.

### Steps to reproduce

1. In the customers portal admin, navigate to https://customers.gitlab.com/admin/customer/17737/edit
1. Select the impersonation icon

### What is the current *bug* behavior?

The page loads with a `500` error

### What is the expected *correct* behavior?

The page should load without an error

### Relevant logs and/or screenshots

![Screen_Shot_2019-10-16_at_9.47.54_PM](/uploads/63ac145c2607b9c189174ac4adbb953b/Screen_Shot_2019-10-16_at_9.47.54_PM.png)

### Workarounds

I'm asking the support engineers if they can clear this error here: https://gitlab.com/gitlab-com/support/dotcom/dotcom-internal/issues/989

### Reported examples

1. https://gitlab.zendesk.com/agent/tickets/134882 ; https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1017334/events/20729358/
1. https://gitlab.zendesk.com/agent/tickets/135670 ; specific event: https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1017334/events/20755426/
1. https://gitlab.zendesk.com/agent/tickets/135802

Story points: 2.0
Trouble changing trial plan from admin panel: ArgumentError: invalid date

https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/957524/

```
ArgumentError: invalid date
  lib/rails_admin/update_gitlab_namespace_plan.rb:33:in `strptime'
    Date.strptime(params[:trial_exp_on], '%m-%d-%Y')
  lib/rails_admin/update_gitlab_namespace_plan.rb:33:in `trial_expiration_date'
    Date.strptime(params[:trial_exp_on], '%m-%d-%Y')
  lib/rails_admin/update_gitlab_namespace_plan.rb:77:in `block in update_order'
    h[:end_date]             = trial_expiration_date if trial_expiration_date
  lib/rails_admin/update_gitlab_namespace_plan.rb:74:in `tap'
    attrs = {}.tap do |h|
  lib/rails_admin/update_gitlab_namespace_plan.rb:74:in `update_order'
    attrs = {}.tap do |h|
...
(99 additional frame(s) were not displayed)

ArgumentError: invalid date
```

Not sure what's happening here, because a trial expiry date existed

### Examples

1. https://gitlab.com/gitlab-com/support/dotcom/dotcom-internal/issues/985
1. https://gitlab.com/gitlab-com/support/dotcom/dotcom-internal/issues/1007
1. https://gitlab.com/gitlab-com/support/dotcom/dotcom-internal/issues/1013
1. https://gitlab.com/gitlab-com/support/dotcom/dotcom-internal/issues/1023
1. https://gitlab.com/gitlab-com/support/dotcom/dotcom-internal/issues/1014
1. https://gitlab.com/gitlab-com/support/dotcom/dotcom-internal/issues/1018
1. https://gitlab.com/gitlab-com/support/dotcom/dotcom-internal/issues/1053
1. https://gitlab.com/gitlab-com/support/dotcom/dotcom-internal/issues/1131
1. https://gitlab.zendesk.com/agent/tickets/140240

Story points: 2.0
Improvements to logger output

### Problem

@rdavila [suggested the following logging improvements in !506](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/506#note_230325305):

> - Apply ANSI colors to log lines based on the log level.
> - Add the path of the caller as the prefix, e.g: "/path/to/log_helper/caller.rb: 'LOG MESSAGE'"

### Proposal

### Result
More context and better formatting of log statements.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Make sure production::blocker issues can be confidential too

<!-- 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 ~"production::blocker" label only works if the issue is not confidential. We should use a token to actually check for all issues.

Story points: 0.0
New form of payment is broken when other payment form already exist

### Summary

Add a new form of payment is broken when where's already a payment method.

### Steps to reproduce

(How one can reproduce the issue - this is very important)

1. Add new payment method
1. Navigate to `/plans`
1. Add pick a plan
1. (select number of users) and click Proceed to checkout
1. On the billing information block click 'add a new form of payment' radio

### What is the current *bug* behavior?

Clicking 'add a new form of payment' does not show the credit cards iframe for adding new payment method.

### What is the expected *correct* behavior?

Clicking 'add a new form of payment' should show the credit cards iframe for adding new payment method.

### Relevant logs and/or screenshots

![Kapture_2019-10-16_at_8.27.26](/uploads/47bb1a94ae1662035a2c4e1cb5ea55e3/Kapture_2019-10-16_at_8.27.26.gif)

### Workarounds

Open console, remove `hidden` class from `#new-payment-method` div.

<!---
Please add both severity and priority level according to: https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#severity-labels
--->

Story points: 4.0
[REST Update] List Subscriptions through the REST API

### Problem

Currently subscriptions are listed (`Manage Purchases` section) through the SOAP API

### Proposal

- [ ] List subscriptions through the REST API

Some other sections where we list subscription details are:

- [ ] Add more seats section.
- [ ] Renew subscription section.

### Result

We will stop using SOAP for listing subscriptions.

### Next steps (if any)

Work on https://gitlab.com/gitlab-org/customers-gitlab-com/issues/759

### How will we measure success?

Story points: 2.0
[Frontend] extract zuora events from payment_method template

### Problem

When we move our JS from sprockets to webpacker, all classes will not be accessible from outside (i.e. not added to global scope).

`app/views/zuora_callbacks/payment_method.html.haml` has inline JS that depends on JS classes that will not exist in the global scope, and its functionality will break once we move the JS to webpacker.

### Proposal

Extract Zuora events from payment_method template (implemented [in this commit](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/470/diffs?commit_id=3cc325aaa5a5c796adc81529e7efb9408a9fe02d)), so no errors will happen when the haml template tries to call non-global classes (e.g. `ZuoraSubscriptionErrorHandler`, `SubscriptionUpgradeDispatcher`).

### Result

Moving forward with webpacker migration without breaking the payment methods functionality.

Story points: 4.0
[REST Update] Process Subscription updates through the REST API

### Problem

Currently simple subscription updates are processed through the SOAP API.

### Proposal

- [ ] Process [subscription updates](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/faa95ea44cbf92f11acd72ab96d4651322f59d1b/app/models/subscription.rb#L14-18) through the REST API.

### Result

Simple subscription updates will be processed through the REST API.

### Next steps (if any)

Work on https://gitlab.com/gitlab-org/customers-gitlab-com/issues/758

### How will we measure success?

Story points: 2.0
[REST Update] Process Subscription amendments through the REST API

### Problem

Currently all subscription amendments are processed through the SOAP API.

### Proposal

Adjust the [`AmendSubscriptionService`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/faa95ea44cbf92f11acd72ab96d4651322f59d1b/app/services/amend_subscription_service.rb#L8-8) and [`AmendGenerator`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/faa95ea44cbf92f11acd72ab96d4651322f59d1b/app/models/amend_generator.rb#L5-5) to use the REST API.

### Result

All subscription amendments will be processed through the REST API.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Deprecate usage of `hidden` classes

<!-- 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
[Hidden has been deprecated](https://getbootstrap.com/docs/4.0/migration/#responsive-utilities) from bootstrap and we're using our own polyfill for this class.

There's a reason this was removed from Bootstrap. Maybe we should follow suit?

### Next steps (if any)
- Investigate if this should be done
- Investigate alternatives
### How will we measure success?

Story points: 3.0
[REST Update] Make Payment Methods section use the REST API

### Problem

Currently the `Payment Methods` section (`PaymentMethodsController`)
 is using the SOAP API.

### Proposal

Use the REST API for the following features:

- [x] List all the existing payment methods.
- [x] Ability to add a new payment method.
- [x] Ability to edit payment method.
- [x] Ability to delete a payment method.
- [x] Ability to set payment method as the default.
- [x] Check that there is one payment as the default at minimum when editing an existent payment method.

### Result

`Payment Methods` section will be migrated from using the SOAP API to REST.

### Next steps (if any)

Work on https://gitlab.com/gitlab-org/customers-gitlab-com/issues/761

### How will we measure success?

Test plan: https://docs.google.com/spreadsheets/d/1HSOvrDWVtqDdr5hYtr2sEosCT0KkjKF49RPZuUe--DI/

Story points: 5.0
[REST Update] Implement REST Api client

### Problem

We're going to consume the REST API of Zuora instead of the SOAP version and we need to create a client for it.

### Proposal

Evaluate if we can use one of the following gems or if we should create the client from scratch:

* https://github.com/zendesk/iron_bank
* https://github.com/contactually/zuora-ruby
* https://github.com/netlify/zuora-ruby-client
* https://www.rubydoc.info/gems/zuora_api/1.7.08 (provided by Zuora)

### Result

After client is implemented we will be able to consume the REST API.

### Next steps (if any)

Work on https://gitlab.com/gitlab-org/customers-gitlab-com/issues/755

### How will we measure success?

Story points: 2.0