giseldo/neodataset huggingface dataset:
Add ability for admins to downgrade GL.com subscriptions

I'm frequently receiving requests to downgrade customers from GL.com Bronze plan to the Free plan given this is not possible for customers to do on their own. I think will be useful to provide this option from the admin panel or by trying to improve the impersonate feature and detect when it's in use and enable features only when an admin is impersonating a customer account.

### Approach

* When impersonating a customer on a paid plan, allow downgrading of a user's plan to any lower tier.
  * The account downgrade should not go into effect until their paid period has expired at the higher tier. If a user pays for a year of Bronze, they should receive 100% of that paid year (even if they downgrade after 6 months).

/cc @csotomango @jeremy_

Story points: 4.0
Ability to perform sales-assisted purchases

### Background

Currently, the only way to easily purchase a subscription on GitLab.com is to have a user who is a member of the group login to customers.gitlab.com and provide their credit card information. Customers.gitlab.com is then responsible for making API calls to Zuora, Salesforce and GitLab.com to update billing information.

Sales can, however, be processed via purchase order, either directly with GitLab sales or via partner resellers. This is currently a manual process that involves impersonation of a valid user on customers.gitlab.com.

### Proposal

1. After the order is processed and paid, the user should be sent an email explaining what they need to do:
  * The email should contain a link to set their password on customers.gitlab.com
  * The user then needs to choose the group to apply their payment to
  * If possible, the email should contain screenshots with an example

Story points: 3.0
Trials for GitLab.com plans

## Background 

We need to allow our users and salespeople to trial GitLab.com plans for 30 days.

An initial simple solution is to allow a trial activation without a credit card.

## Proposal

1. Allow users to visit GitLab.com plan pages (https://gitlab.com/profile/billings or https://gitlab.com/groups/GROUPNAME/-/billings) and activate a trial.
2. A user should have the option of starting a 30-day Gold trial.
3. On clicking on the trial CTA, a form similar to the free trial form (https://about.gitlab.com/free-trial/) should be displayed to capture lead information, which is pushed to SF.
4. On submitting the form, the trial is activated. A user should be redirected to the billing page and see a banner notifying them that they're on a Gold trial, and when this trial expires. This banner should persist until the trial expires.
5. After 30 days, the trial is deactivated. The trial option should no longer be presented on the billing page, and a user should not be able to obtain another trial for a user or group that's had a trial before.

During the trial, users should receive a nurture campaign similar to our existing campaign for self-managed trials.

A user should also be able to upgrade their account to a paid account during the trial. 

## Open questions

* Are we doing trials at each subscription level?

No. The trial is for Gold only.

* Are we allowing trials for individuals, groups, or both?

Both. Accounts should get 1 trial, which can be applied to a personal namespace or a group.

* Should we change `pricing` and consider a separate flow for a new, unregistered user?

Yes, in a separate issue. This should only apply to existing users. 

* How does nurture messaging from Marketo and Outreach fit in?

TBD.

* How will the new form interface with SFDC?

We should push these leads to SFDC in the same way we do in https://about.gitlab.com/free-trial/, in the new free trial form. We should note that these leads are for .com.

Story points: 4.0
Exclude Vue entrypoints from Jest coverage

### Problem

The entry points files are [exempt from testing](https://docs.gitlab.com/ee/development/fe_guide/performance.html#important-considerations) (e.g. `app/frontend/javascripts/navigation/index.js`).

To keep our Jest coverage more realistic, we need to exclude those files from the coverage report, to reduce noise and unnecessary checking on which files we need to cover with tests.


### Proposal

Add an array of files we need to exclude to jest config to keep everything ignored contained in one place.

### Result

Better and more accurate frontend test coverage.

### Next steps (if any)

Story points: 1.0
Add client API code to PUT/POST subscriptions, with and without credit card

<!-- 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/

-->

Since Zuora is communicating back to us via a webhook, we need to listen to an event callback.

It'd be great to do this with an EventBus. But we have infrastructure in place to listen for event callbacks; so let's use those for now.

There's currently a [global client side event listener](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/assets/javascripts/zuora_subscription_event_listeners.js) that does this. However this will make a page redirect on failures and success. We want Vue to be in control of this.

Story points: 2.0
Zuora component



As part of https://gitlab.com/gitlab-org/customers-gitlab-com/issues/957 we need a Zuora Vue component.

We should take inspiration from https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/subscriptions/new/components/checkout/zuora.vue and retrofit it to our needs.

* Render iframe based on event; based on a prop
* Show loading state
* Allow for retrying on error

Story points: 2.0
CI Minutes container fix

<!---

UI Polish Issue for the Portal

Please add to the Customer Portal Beautification epic: https://gitlab.com/groups/gitlab-org/-/epics/2653

--->

### Problem

On the `/plans` page the purchase CI Minutes component header is not rendering correctly.

| Current | Proposal |
| ------ | ------ |
| ![image](/uploads/37074db91bb824b647d5c0ed65c900e6/image.png) | ![image](/uploads/1b7d3b13cfc70b54aa2637ed0bd14915/image.png) |

<!---
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
Display banner warning when a customer will incur an add-on charge

## Summary

When we implement [Quarterly Self-Managed Seat Reconciliation & Billing](https://gitlab.com/groups/gitlab-org/-/epics/2747), users will not be aware of the need to load a new license unless we alert them.

### Implementation

1. Starting at "quarterly event' - 7 days, do a daily check to see if the customer will require an add-on
1. Where yes, expose a banner in the instance UI (not portal) to admins only 
1. The banner should contain the following information:
     1. Link to docs page re: quarterly user reconciliation
     1. Importance of applying the updated license when it is received
     1. How to contact us for help
     1. The banner should be dismissible
     1. If the admin blocks enough users to get back under their subscription seat count, then the banner should be removed
1. Display a second banner after the quarterly seat reconciliation has been processed (and the new license is available)
     1. This banner should **not** be dismissible
     1. The banner should be removed upon applying the license
          Options:
          1. Any new license
          1. A license which has more users than previous count

We should not display this message to air-gapped, closed network, or prior to us starting to actually process these charges. 

### Test Cases

For each of the scenarios in the [test cases](https://docs.google.com/spreadsheets/d/1S7hF0yb4C8Kjwu_nRC41M6aBCDwSWn0GxI1A2G4NMBA/edit?usp=sharing), check the behavior of the banner against the desired behavior.

Story points: 3.0
Show a summarize of Seats for Self-Managed and GitLab.com subscriptions

<!-- 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 initial designs in https://gitlab.com/gitlab-org/customers-gitlab-com/issues/679 show a summation of seats for subscriptions.

![Screenshot_2020-02-28_at_10.46.22](/uploads/ba344778a417a79a9f56928235eaee3c/Screenshot_2020-02-28_at_10.46.22.png)

However this data isn't currently available from the backend: https://gitlab.com/gitlab-org/customers-gitlab-com/issues/1126 and making these calculations in the UI is error-prone; the worst thing we can do is show incorrect data.

### Proposal

Once #1126 has been implemented, add Seats data to `SubscriptionDetails.vue`

Story points: 1.0
Spike: exposing webpacker images to HAML views

Looks like we need to put a `require.context('../images', true)` in `application.js` to expose to Rails views.

[As the documentation states here](https://github.com/rails/webpacker/blob/master/docs/assets.md#link-in-your-rails-views)

We need to be sure that only the paths are exposed, and images do not effect bundle size.

Story points: 1.0
A successful sign-in should redirect to "Manage Purchases" 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

Currently, when a user successfully signs into the portal they are automatically taken to the https://customers.gitlab.com/plans page. 

### Proposal

If the user has an active product we should redirect them automatically to the `Manage Purchases` page.

Story points: 2.0
Danger reminder to update the DB ERD

The following discussion from !1078 should be addressed:

- [ ] @vitallium started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1078#note_295841721):  (+1 comment)

    > It would be nice to have a rule for the Danger bot that will be triggered by when the following conditions met:
    > * `db/migrate` or `db/schema.rb` contains changes;
    > * **and** `doc/db_erd.png` wasn't updated.

Also, look into automating the generation of the DB diagram by using https://github.com/voormedia/rails-erd or something similar.  Using LucidChart requires access to an account which most of us don't have.

Story points: 0.0
Remove feature flag from Sign in / Register pages under pajamas


This is a follow-up to the original issue #682.

After the feature flag has been enabled on production for about 2 weeks without issues, we need to graduate the sign in & register pages from being served behind a feature flag to being a first-class code served directly to users.

I'm expecting the pages to be approved and the feature flag enabled by 2020-03-06, so this issue should be looked at around 2020-03-23.

Story points: 1.0
API endpoint design & implementation: Subscription information

<!-- 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

While working on https://gitlab.com/gitlab-org/customers-gitlab-com/issues/679 we want to show purchases and seats in the UI.

This becomes a problem when a subscription

* Self-Managed and has a true-up 
* GitLab.com and users have been added to the group

Since this data isn't exposed by the backend, we'd need to make these calculations in the UI. Previously this wasn't a problem since the UI listed individual purchases, and did not add the total up.

### Proposal

Design and implement a `/subscriptions` endpoint with a clear contract of what data is available.
Possibly this could be done with graphql: https://gitlab.com/gitlab-org/customers-gitlab-com/issues/889 but that's a stretch-goal.

Alternatively [`subscription_presenter`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/presenters/subscription_presenter.rb) can be augmented with the required information.

In any case, this is calculating seats purchased and seats used; so it's a non-trivial product effect here.

### Result

We can trust that data in the UI accurately reflects the correct data

Story points: 5.0
Navigating to new subscription as anonymous user throws 500 error

<!---
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

Navigating to new subscription as anonymous user throws 500 error, e.g. https://customers.stg.gitlab.com/subscriptions/new?plan_id=2c92c0f9699eca030169a2f1f117045f&subscription_id=A-S00006613&transaction=ci_minutes

**NOTE:** This doesn't happen on production. On production it redirects you to `https://customers.gitlab.com/plans`

### Steps to reproduce

1. Try to open [this URL](https://customers.stg.gitlab.com/subscriptions/new?plan_id=2c92c0f9699eca030169a2f1f117045f&subscription_id=A-S00006613&transaction=ci_minutes) as anonymouse user.

### What is the current *bug* behavior?

Application throws 500 error.

### What is the expected *correct* behavior?

It should show a screen with sign in to GitLab.com

### Relevant logs and/or screenshots

### Workarounds

(Ways to get around the issue)

### Reported examples

1. https://sentry.gitlab.net/gitlab/customersstggitlabcom/issues/1365901/?query=is:unresolved
1. 
1. 

<!---
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
Consolidate on a strategy for handling free plans in Customer Portal and GitLab Core

Opening this issue on the background of [this comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1062#note_293550541)

> the plans handling in Gitlab.com and in customers.gitlab.com is a bit confusing including `null` plans. I think we're fine with the current MR's scope. But I feel like we need a bigger overhaul going forward across the two applications.

It becomes awkward to handle free plans, since we're marking the absence of information (`null`) as a Free Plan.

A `null` plan can also happen if a bug happens, so it might be risky to fall back to Free Plan like this.

---

### TODO

Find a strategy for handling free plans across GitLab core and Customer Portal.

* Could be actively marking Free Plans (serialize Free Plan as a product)
* Could be embracing `null` == Free Plan in the Customer Portal at the data layer.

Story points: 2.0
Create a DB Schema Diagram for customers-gitlab-com

### Problem
We do not have database schema diagrams documented for customers-gitlab-com.  These are very useful for engineers or otherwise to help visualize the relationships of the DB models.

### Proposal
Use a tool to generate the schema diagram using the [`db/schema.rb` file](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/0134cfb125f6b264c82e728f49a0a44cb0299804/db/schema.rb#L211) from the project.  

Once generated, [@j.carey suggested](https://gitlab.com/gitlab-org/customers-gitlab-com/issues/1011#note_293615743) we make the diagram available in the handbook on [the Business Systems Portal page](https://about.gitlab.com/handbook/business-ops/business_systems/portal) or a subpage.

### Result
Better documentation for the Customers Portal.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Follow-up from "Preserve default plans order in plans finder"

The following discussion from !1073 should be addressed:

- [ ] @vitallium started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1073#note_294224173):  (+1 comment)

    > Sort found plans by given `plan_ids` to keep the required order: `Free`, `Bronze`, `Silver` and `Gold`.

Story points: 1.0
Display correct response from Update and Delete Zuora actions

### Summary

When updating the payment on the "Payment Methods" page, if the error responded back from Zuora the same error is shown in the string format instead of bulleted points like perviously. 

This happens only when Zuora is using the REST API.

### Steps to reproduce

1. Login and go to Payments Method page.
2. Make sure you have atleast one payment method present
3. Edit the payment and set the Expiration Date last month or before that.
4. Press Update

### What is the current *bug* behavior?

Error is displayed as String and not the expected message on top of page. 

`Body: [{"Errors"=>[{"Code"=>"INVALID_VALUE", "Message"=>"Expiration date must be a future date."}], "Success"=>false}]`

![Screenshot_2020-02-25_at_16.00.44](/uploads/bdf3de4560ffe33ac7965370c680ddb3/Screenshot_2020-02-25_at_16.00.44.png)

### What is the expected *correct* behavior?

The error string should display

`Expiration date must be a future date.`

### Relevant logs and/or screenshots


### Workarounds

(Ways to get around the issue)

Story points: 2.0
Zuora REST API - payment methods are nested in .remote

<!-- 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

After turning on Zuora REST API, payment methods are nested in a `.remote` property.

This has an effect on Views that are querying payment methods and might well be causing some bugs that have not surfaced yet.

https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/views/subscriptions/new_extra_ci_minutes_plan.html.haml#L61

| `zuora_rest_api` off | `zuora_rest_api` on |
| ------ | ------ |
| ![Screenshot_2020-02-21_at_14.40.48](/uploads/5f4d2abaa3c5d69ca073d63da50163d9/Screenshot_2020-02-21_at_14.40.48.png) | ![Screenshot_2020-02-21_at_14.41.15](/uploads/2015bfe0ed4eb6a954c8f4fcc926ed84/Screenshot_2020-02-21_at_14.41.15.png) |

### Proposal

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Graduate `pajamas_nav_bar` 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/

-->

The Pajamas Nav Bar has been live for a while without incident.

We should clean up after ourselves :)

* Remove instances of `pajamas_nav_bar`
* Remove HAML implementation of nav bar
* Remove HAML specific styles
* Remove specs that test `pajamas_nav_bar`
* Remove feature flag from https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags

Story points: 1.0
Web Directs not Sending MRR or Deal Length Data

<!-- 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

For the Calculation of iACV in Salesforce, Opportunities need to have the following fields filled out to be 100% accurate.

MRR1__c = The MRR of the related Zuora Amendment.
Start_Date__c = the Start Date of the related Zuora Amendment.
Opportunity_Term_New__c = the term length in months (Initial Term or Renewal Term based on type)

### Proposal

Please add in these fields when you call `CreateSalesforceOpportunityService` here: https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/controllers/subscriptions_controller.rb#L226

### Result

Web Direct opportunities will have these fields populated on creation in SFDC by the portal. We will be able to fully depreciate the tangle of SFDC triggers that were not completing the job as written and were effectively "Guessing" the value of these fields.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Follow-up from "Check Zuora API response and return parsed response body"

The following discussion from !1052 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1052#note_291160337):  (+3 comments)

    > I suspect we might need to do the same thing in [app/jobs/zuora/actions/amend.rb](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/66678eb7ce0cc05105cb526ad44fbe3dc4e63189/app/jobs/zuora/actions/amend.rb#L13).  It might be worth checking the FE folks on what they are expecting there.

Story points: 1.0
Delete non-gitlab.com customers from customers.stg.gitlab.com

The following discussion from !1051 should be addressed:

- [ ] @shreyasagarwal started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1051#note_291030121):  (+8 comments)

    > Is there anyway we do not have this change and we delete all the customers on staging with non gitlab.com email IDs.
    > 
    > Is there a reason we are leaving them in the system ?

The general consensus from the thread was to delete all customers from https://customers.stg.gitlab.com that do no have an email address ending in `@gitlab.com`.  When working on this task, considerations should be taken to ensure related associations are wiped from the database as well as to not leave orphaned records.

Also, once we've removed non-gitlab.com customer accounts from stg, we can revert most of the code changes from !1051.      The main piece we want to keep going forward is https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1051/diffs#fc4baf9840b8a1ebe46afd7dce3b9656c1c51c47_163_164 which prevents new non-gitlab.com registrations in stg.

Story points: 2.0