giseldo/neodataset huggingface dataset:
Add-on amendments with a discount different than the original subscription are creating new subscriptions


### Problem
When a sales-assisted add-on user amendment is created with a discount different than the original subscription, the amendment is treated like a new subscription rather than an update to the existing subscription.


### Proposal
When a sales-assted add-on user amendment is created, 

1. the add-on users should be appended to the original subscription
1. a new subscription should not be created
1. the user count on the original subscription should be updated with the additional users
1. for self-managed, a new license should be issued with the updated user count
1. for gitlab.com, the additional users should be passed to the total user count in gitlab.com

### Example Screenshot
![Screen_Shot_2020-03-26_at_8.07.28](/uploads/2181a59ee8b762b77fe761938e4947e3/Screen_Shot_2020-03-26_at_8.07.28.png)

### Reported examples
1. https://gitlab.com/gitlab-com/support/dotcom/dotcom-internal/-/issues/1833
1. https://gitlab.zendesk.com/agent/tickets/150162
1.
1.

Story points: 3.0
Submit button is missing on Add new payment method page

### Problem

When the user attempts to add a new payment method, the Submit button is missing. When I perform the same action while impersonating the user, I can see the submit button.

#### Steps
1. From customer account which already has a subscription, navigate to My Account > Payment methods
1. Select `Add new payment method` button
1. Fill in details, cc number starting with `51` (to trigger mastercard)
1. Fill in remaining details
1. Observe `Submit` button

#### Information from the user

```
* I am using the latest Chrome on Mac and the screen was 100% without any scroll.
* It works normally when using a private window
* And same result as before (no button) outside of incognito mode

I did some digging because I was curious:
1) The button is there, just not visible because of the height of the surrounding iframe (no scrollbar)
2) If I manually increase the height of the iframe to 412px (the height in the incognito mode), the button appears

So weirdly enough, the iframe is not correctly sized outside of incognito mode.
```

#### Screenshot from user
![Screen_Shot_2020-03-25_at_18.01.48](/uploads/4416a2661d6c10f9b2d9358837f7941d/Screen_Shot_2020-03-25_at_18.01.48.png)

#### Screenshot when I impersonate the user.
![Screen_Shot_2020-03-25_at_18.00.15](/uploads/477b38bbaf3bf731d92f9482f3d5ec73/Screen_Shot_2020-03-25_at_18.00.15.png)

#### Reported examples

1. https://gitlab.zendesk.com/agent/tickets/151238
1.
1.
1.

Story points: 3.0
ActionView::Template::Error: undefined local variable or method `pending_eula' for #<SubscriptionPresenter:0x000000000a699330>

https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1381753/?referrer=gitlab_plugin

```
NameError: undefined local variable or method `pending_eula' for #<SubscriptionPresenter:0x000000000a699330>
  app/presenters/subscription_presenter.rb:59:in `eula_request_path'
    @subscription.pending_eula_request ? eula_request_url(pending_eula.token) : nil
  app/presenters/subscription_presenter.rb:47:in `path_attributes'
    eulaRequestPath: eula_request_path,
  app/presenters/subscription_presenter.rb:12:in `present'
    subscription_attributes.merge(path_attributes)
  app/helpers/subscription_helper.rb:5:in `block in subscriptions_data_attributes'
    subscriptions.map{ |subscription| SubscriptionPresenter.new(subscription, current_customer).present }
  app/helpers/subscription_helper.rb:5:in `map'
    subscriptions.map{ |subscription| SubscriptionPresenter.new(subscription, current_customer).present }
...
(115 additional frame(s) were not displayed)

ActionView::Template::Error: undefined local variable or method `pending_eula' for #<SubscriptionPresenter:0x000000000a699330>

ActionView::Template::Error: undefined local variable or method `pending_eula' for #<SubscriptionPresenter:0x000000000a699330>
```

Story points: 1.0
Notify self-managed admin as they approach the user limit in their subscription

### Problem

Self-managed admins don't get any alerts when they are approaching their user limit. This can cause surprises for customers at renewal, and when they are contacted or charged for overages.

### Proposal

We should provide alerting to the admin potentially via the following modes:

1. In-instance banner displayed to the admin, on all pages.
1. Email to admin
1. Thoughts about a notification bubble on the admin wrench to call attention? (maybe overkill given the first step)

I'd like to get feedback on cadence of these alerts. Example, this happen when x% of the seats are used?

Story points: 3.0
Graduate Pajamas Update: Portal "Manage Purchases/Buy more CI minutes" Page 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/

-->

- [x] Remove instances of `pajamas_buy_ci_minutes`
- [x] Remove HAML implementation of CI minutes
- [x] Remove HAML specific styles
- [x] Remove specs that test `pajamas_buy_ci_minutes` on/off (since it'll always be on)
- [x] Remove feature flag from https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags

Story points: 1.0
Adopt `gl-new-dropdown`

<!-- 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/

-->

https://gitlab.com/gitlab-org/gitlab-ui/-/issues/673

`gl-dropdown` is being deprecated in favor of `gl-new-dropdown`.

The `gl-new-dropdown` is prime-time ready, where it gets tricky is replacing the name and API of the old `gl-dropdown`.

It is recommended to use `gl-new-dropdown` going forward, and then rename `gl-new-dropdown` -> `gl-dropdown` once `gitlab-ui` has renamed the component.

Story points: 1.0
Adopt `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/

-->


https://gitlab.com/gitlab-org/gitlab-ui/-/issues/608

`gl-button` is being deprecated in favor of `gl-new-button`.

The `gl-new-button` is prime-time ready, where it gets tricky is replacing the name and API of the old `gl-button`.

When using `gl-button` we get this warning:

> Note: This component is being introduced to replace the <gl-button> component as it doesn’t conform to the design specs. Please use <gl-new-button> going forward. You can read more about the migration here.

It is recommended to use `gl-new-button` going forward, and then rename `gl-new-button` -> `gl-button` once `gitlab-ui` has renamed the component.

Story points: 1.0
Modify `gitlab_info_per_namespace` to be more easily consumed by the frontend

The following discussion from !1116 should be addressed:

- [ ] @rhardarson started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1116#note_304455945):  (+4 comments)

    > Same concerns here as https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1116/diffs#note_304454658
    > 
    > I don't like doing this in the entrypoint; but the data conversion needs to happen _somewhere_


We're bending over backwards to consume the current `gitlab_plans_helper` helpers.

We should update these helpers to be more easily consumed by the frontend.

Importantly we need to make doubly sure that old usages of these helpers do not break.

Story points: 1.0
Follow-up from "Render CI Transaction behind a feature flag"

The following discussion from !1116 should be addressed:

- [ ] @vitallium started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1116#note_303698688):  (+4 comments)

    > PSA: there is a [MR](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1111) that introduces `PaymentMethodPresenter` for pulling required attributes only.

Story points: 1.0
Registration form when signing in with GitLab for the first time is not prefilled

<!-- 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

Discovered during: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1166#note_302990067

> When `pajamas_login_register` feature flag is off and the user gets redirected to `customers/sign_up` to fill in the rest of the details, the form is being populated by the user's information the user already filled in GitLab.

Filling in the same information is extra work for the user, and runs the risk of mismatched information.

### Proposal

Ensure prefill of form when being redirected from `gitlab.com/users/sign_in` 

### Result

Less work for users signing up.

### Additional Information

From [Slack conversation](https://gitlab.slack.com/archives/CMJ8JR0RH/p1601281385072400) -

>There’s a UX gap where if the user tries to sign up with “Sign in with GitLab.com” and hits the registration page where they enter a bad email, their account get’s locked to the bad email.
We got around this by deleting the Account on Customers.

Story points: 2.0
Switch to Cuprite for Feature Specs

<!-- 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/

-->

Prior work:

* https://gitlab.com/gitlab-org/gitlab/-/issues/26235
* https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25727
* https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1072

Cuprite uses [ChromeDevTools protocol](https://github.com/ChromeDevTools/devtools-protocol/) to power interactions, while Selenium uses WebDriver.

There's speed and stability to gain from adopting Cuprite: less time waiting on pipelines and less flakiness is something worth testing (:wink: ) out.

Story points: 2.0
Graduate Pajamas Update: Portal "Plan" Page from feature flag (cleanup)

<!-- 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/

-->
Pajamas Update: Portal "Plan" Page has been live for a while without incident.

We should clean up after ourselves :)

* Remove instances of `pajamas_plan_page`
* Remove old HAML implementation of Plan Page
* Remove old HAML specific styles
* Remove specs that test Plan page without feature flag
* Remove feature flag from https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags

Story points: 1.0
Users get redirected to JSON countries file on new register

<!-- 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

1. User navigates to customers.gitlab.com
1. User clicks Sign in with GitLab
1. User registers new account on gitlab.com
1. User is redirected to fill in additional details on customers.gitlab.com
1. User fills in form
1. User is redirected to JSON file

### Proposal

Investigate if this is related to changes in https://gitlab.com/gitlab-org/customers-gitlab-com/issues/682

Story points: 2.0
Missing- View Invoice Details-Tab

<!-- 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- 

There used to be an view invoice tab in the account details option at the customers.gitlab.com. This helped sales team to understand the payment methods used for past purchases and the entire purchase history of customers. Many times when a customer want to change the card associated with account, they reach to sales team. Sales re needs to find the card associated, this option used to help in finding the card used for past purchases.

Additionally, self- serving customers also could download the invoice from there and use it for filing reimbursement. 
 
With latest changes this information is not available.

New layout- 
![Screenshot_2020-03-07_at_11.23.35_AM](/uploads/32db1b9efaee23cd850de7c75c2f984c/Screenshot_2020-03-07_at_11.23.35_AM.png)
Old Layout - 
![Screenshot_2020-03-03_at_7.45.06_PM](/uploads/28bf4cfe60e9ef651e57e52b4cc0aaa5/Screenshot_2020-03-03_at_7.45.06_PM.png)
This screenshot shows the old layout for a client who made different purchases.
### Proposal- 
Kindly add this tab again

### Result- 
It will help sales rep to resolve these queries at earliest and also avoid few Zendesk tickets by customers.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Throw an error if :new_episodes record_mode used

The following discussion from !1746 should be addressed:

- [ ] @vitallium started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1746#note_406076340):  (+4 comments)

    > @tyleramos, continuing our discussion here because I renamed the class `ZuoraIntegration` to `ZuoraTimeTraveller`. `ZuoraIntegration` was a bad name.
    > 
    > So. I think it's fine to use original datetime for VCR in `new_episodes` mode. And we do the same for `once` and `none` modes. For `all` we use the current datetime.

## Problem

With the new `ZuoraTimeTraveler` class, we will make the specs that use VCR and Zuora less flakey by using Timecop to freeze time using the datetime from the VCR cassette recording.  This approach however makes the record mode `:new_episodes` unusable because the entire cassette must be created at one time.

## Proposal

Raise an error if `:new_episodes` is used with a message of why it can't be used.  It's possible that it could be used for a subset of specs as long as those specs don't use the `:zuora` rspec metadata tag ([introduced here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1746)).  Not sure if it's possible or worth it to make that distinction.

Story points: 1.0
Setting up customer portal on local machine throws database does not exist error

### Summary
Setting up a customer portal on local machine (fresh install) fails on `bundle exec rake db:setup` step with the below error. The steps I'm referring to is from the [doc/installation_steps.md#final-steps-for-customers-application](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/master/doc/installation_steps.md#final-steps-for-customers-application)

```shell
ActiveRecord::NoDatabaseError: FATAL: database "payment_app_development" does not exist
```

### Steps to reproduce

1. Checkout the latest master/staging of customer portal https://gitlab.com/gitlab-org/customers-gitlab-com
1. Follow the instructions in the [doc/installation_steps.md#final-steps-for-customers-application](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/master/doc/installation_steps.md#final-steps-for-customers-application)

### What is the current *bug* behavior?
`bundle exec rake db:setup` throws error if the database doesn't exist instead of creating a new one.

### What is the expected *correct* behavior?

`bundle exec rake db:setup` should create the database if it doesn't exist.

### Relevant logs and/or screenshots

```shell
ActiveRecord::NoDatabaseError: FATAL: database "payment_app_development" does not exist
```

### Workarounds
1. Log into the client and create the database manually with the following steps

```shell
> psql
> CREATE DATABASE payment_app_development;
> quit;
```

2. Run `bundle exec rake db:setup` to see the rest of the process working.

Story points: 2.0
Patch the IronBank gem to make error codes more accessible

The following discussion from !1856 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1856#note_405535241):  (+1 comment)

    > It's disappointing that IronBank doesn't make the codes easily accessible, forcing us to search for the code in this way.  :slight_frown:
    > 
    > This totally works though and I'm fine with it in the short term.  What do you think about opening a follow-up issue to patch IronBank to make these codes easily accessible by adding an instance method to [the error class](https://github.com/zendesk/iron_bank/blob/main/lib/iron_bank/error.rb)?  I've submitted a PR to that repo before and the maintainers seems to be very responsive.  It's not something we have to act on immediately but might be nice to work on it at some point in the future.  Thoughts?

## Problem

We can't directly access error codes for an `IronBank::Error` as [discussed here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1856#note_405535241).  It's contained inside the message of the error object which contains an unparsed json string.  This makes for a less-than-elegant solution when determining the exact error class returned from Zuora.

## Proposal

Submit a PR to the IronBank repo to make an `error_code` instance method available on [the Error class](https://github.com/zendesk/iron_bank/blob/main/lib/iron_bank/error.rb).  Once this is accepted and the gem is updated, we can use this updated gem in the portal, replacing the [code here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1856/diffs#52d3703e65dee7027b3ef5af4fd34791dfe83d1c_19_16) with something a bit more concrete (e.g. `Zuora::ErrorCodes.rescuable_codes.include?(e.error_code)`).

Story points: 2.0
Replace Timecop with ActiveSupport::Testing::TimeHelpers

### Problem
With https://gitlab.com/gitlab-org/gitlab/-/issues/214432 GitLab moves away from `Timecop` to replace it with `ActiveSupport::Testing::TimeHelpers`.

### Proposal
Align with GitLab and replace `Timecop` with `ActiveSupport::Testing::TimeHelpers` as everything can be easily replaced:

| Timecop | ActiveSUpport::Testing::TimeHelpers |
|---------|-------------------------------------|
| Timecop.freeze(&block) | freeze_time(&block) |
| Timecop.travel(time, &block) | travel_to(time, &block) |

### Result
Remove unmaintained `Timecop` gem and use Rails core feature `ActiveSupport::Testing::TimeHelpers`.

### Next steps (if any)
* [ ] Add Cop on Timecop.freeze to use `freeze_time` - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/39656#note_399654010
* [ ] Add Cop on Timecop.travel to use `travel_to`
* [ ] Enable cops and address existing violations

Story points: 2.0
Document sales-assisted subscription creation workflow

### Problem
A [possible bug](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1881) turned out not to be a bug but an issue in the workflow how sales-assisted subscriptions are created.

### Proposal
Create documentation for the correct workflow for sales-assisted subscription creation. The correct way is described in [this comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1881#note_403799485).

### Result
Have documentation about the correct way to create sales-assisted subscriptions.

Story points: 1.0
Create log_warn method in Gitlab::LoggerHelpers

There was a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1862#note_403237068) in !1862 where it was discussed if we should change `log_error` into `log(:error` or define the missing `log_warn` method instead of using `log(:warn`.

After a brief discussion with some other team members, it was decided to define the missing `log_warn` in [Gitlab::LoggerHelpers](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/lib/gitlab/logger_helpers.rb) method for consistency.

Other log levels that are defined in https://gitlab.com/gitlab-org/customers-gitlab-com/blob/staging/lib/gitlab/logger.rb#L9 and do not have a helper method yet, will be created when they are needed.

Story points: 1.0
Follow-up from "Resolve "Stop sending EULA requests for new purchases""

The following discussion from !1855 should be addressed:

- [ ] @vshumilo started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1855#note_402727249):  (+3 comments)

    > @tyleramos the `send_license_key` will execute for EE plans or `Plan::TRUE_UP_PLAN`. Just wanted to double check this one is left out in the `else` un purpose

## Purpose

Update [the `send_license_key` method](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/523c93bf52dc03a0b509bac3e96429a5b1d038ea/app/controllers/zuora_callbacks_controller.rb#L139-146) in `ZuoraCallbacksController` to remove the plan checks.  As [discussed here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1855#note_403443583), we decided these do not add much value given we already [do plan checks earlier in the action](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/523c93bf52dc03a0b509bac3e96429a5b1d038ea/app/controllers/zuora_callbacks_controller.rb#L26).

Story points: 1.0