giseldo/neodataset huggingface dataset:
Find licenses using subscription name

### Problem
We currently lookup licenses for the "Download License" feature from the license-app using 4 attributes (`email`, `plan_code`, `users_count`, and `expires_at`).  This link between the two systems seems a bit flimsy.

### Proposal
On the license app, add a new column to store the `subscription name`. We may need to create a script that contacts the Zuora API and obtains the `subscription name` based on the `subscription id` that we've stored on the license app. Once this is ready on the license app, we can just find by the `subscription name` instead of using all the 4 fields listed above.

This was [originally proposed](https://gitlab.com/gitlab-org/customers-gitlab-com/issues/281#note_188242848) by Rubén in #281.  This issue also relates to #636.

### Result
A cleaner link between the subscription in the customers-app and the license in the license-app.

### Next steps (if any)
Once this is in place, the customers-app can request a license to be created if it does not yet exist in the license-app.

### How will we measure success?

Story points: 3.0
Zuora error messages fail to show up in 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
Users are reporting that our Zuora payment gate is failing, and failing without a meaningful error message.

This is blocking users at a crucial step in their flow.
### Proposal
Find steps to reproduce.
- Browser
- OS
- Any browser plugins that can conflict

Add additional logging to Zuora iframe if possible.

### Result
Root cause of error is identified and fixed.
Future errors are logged

Story points: 1.0
Adding Zuora and Salesforce IDs to another user breaks upgrade

## Summary

When a user requests access to manage the subscription in the customers portal in addition to or instead of another user, we (in support) will copy/remove the Zuora and SFDC ids from the Edit page in the customers portal from the existing user and add to the requesting user (after they fulfill security criteria).

When we do this, the subscription of the additional/new user appears without being linked in the Manage Purchase page. 

* Not only does this cause confusion to the user, but the `upgrade` button is no longer present in the customers portal as a result
* When the user attempts to upgrade via the button within GitLab.com group>billing page, they are not able to due to [this issue](https://gitlab.com/gitlab-org/customers-gitlab-com/issues/652)

Is there a workaround to add/change the customers portal contact for a subscription without causing these issues?

![Edit_Page](/uploads/8c4e19c878beecb72886563ab2e18d8b/Edit_Page.png)
![Manage_Purchase_Page](/uploads/4daf97572c8012bceb3239e45375552b/Manage_Purchase_Page.png)
![GitLab.com_Billing_Page](/uploads/1724008d6e045bfbc7d3c34fe76d4c6c/GitLab.com_Billing_Page.png)

## Related support tickets

I'm sure there's more, but recording the latest one. Users asking for us to allow another account to manage the subscription but we can't due to this bug.

1. https://gitlab.zendesk.com/agent/tickets/133949

Story points: 2.0
Linking a subscription group to a GitLab.com namespace does not work properly

### Problem

Still unknown if it's a bug in 100% of the cases, but we've seem problems when trying to link the subscription group to a GitLab.com namespace. 

Workflow: https://www.loom.com/share/a007a39876904b0e9f3234cd704ad67a

We need to investigate further and see if it's not happening to all users.

Story points: 3.0
Redirect to /subscriptions when the found subscription is not upgradable

### Problem

When an user is coming from the upgrade button in GitLab.com, it's possible that the subscription is not upgradable given the Group is not linked with the customers portal. Today we present a 404 in this scenario.

Workflow video: https://www.loom.com/share/3da777d3578043bb8fd376ad14dd2895

### Solution

When the subscription found is not upgradable, redirect the user to `/subscriptions` with a simple message that the subscription doesn't seem to be upgradable (and to check if the subscription is properly linked).

Story points: 1.0
Better Error Handling in `Client::LicenseApp`

### Problem
The `Client::LicenseApp` class makes requests using `HTTParty` but does not handle any error cases.  This means the places that use this class are responsible for handling errors like `Errno::ECONNREFUSED` which likely has some duplication between those implementations.  [This came up during a discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/431#note_209327087) of MR !431.

### Proposal
Add error handling to the `Client::LicenseApp` class.

### Result
Reduce duplication of error handling and make the calling code a little simpler.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Admin user  management

### Problem

There doesn't appear to be a way to manage admin users through the Admin UI.  It would be nice to be able to add, remove, or update admin accounts without accessing the backend.

### Proposal

Add a new tab to the Admin console for management of Admins.  This would include the standard CRUD capabilities.

### Result

Easier admin user management.

### Next steps (if any)

Story points: 1.0
422 Unprocessable Entity when trying to "Download License"

### Problem

When attempting to download a license for this customer (see ticket for details), site throws a 422 error:

```
Failed to load resource: the server responded with a status of 422 (Unprocessable Entity)
application-42fcbdb6886a54697837ec01fe8e95bda6b41bab8bde374ee31416b090a9df47.js:9 Uncaught TypeError: this.showMessage is not a function
    at Object.<anonymous> (application-42fcbdb6886a54697837ec01fe8e95bda6b41bab8bde374ee31416b090a9df47.js:9)
    at u (application-42fcbdb6886a54697837ec01fe8e95bda6b41bab8bde374ee31416b090a9df47.js:2)
    at Object.fireWith [as rejectWith] (application-42fcbdb6886a54697837ec01fe8e95bda6b41bab8bde374ee31416b090a9df47.js:2)
    at i (application-42fcbdb6886a54697837ec01fe8e95bda6b41bab8bde374ee31416b090a9df47.js:3)
    at XMLHttpRequest.n (application-42fcbdb6886a54697837ec01fe8e95bda6b41bab8bde374ee31416b090a9df47.js:3)
```

Note: filing this now in case we get other reports

Got around this by triggering an email re-send of the licence via the licence app

Tickets reporting this:

- https://gitlab.zendesk.com/agent/tickets/129975
- insert here

Story points: 1.0
Prefer `Date.current` & `Time.current` over `Date.today` & `Time.now`

### Problem
In various places in the app code, there are references to `Date.today` and `Time.now` which works but isn't as accurate as `Date.current` and `Time.current` which uses Rails timezone configuration (UTC in our case) instead of using the system configured time.  This could vary by installation, causing some tests to fail locally on one system but pass on another causing confusion and inconsistency.  [See this for more information](https://thoughtbot.com/blog/its-about-time-zones).

### Proposal
Change instances of:
- `Date.today` to `Date.current`
- `Time.now` to `Time.current`

Things like `10.hours.ago` and `5.days.from_now` [should already be using `Time.current`](https://github.com/rails/rails/blob/v4.2.6/activesupport/lib/active_support/duration.rb#L108).

### Result
This should result in cleaner and more consistent code base, as well as making tests more accurate.

### Next steps (if any)

Story points: 2.0
Export existing VAT ID to Zuora

The following discussion from !371 should be addressed:

- [ ] @asubramanian1 started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/371#note_194568197):  (+2 comments)

    > @csotomango This applies only to new accounts.
    > 
    > In case you need it to be applied for existing accounts, let me know. Happy to create a script to push them to Zuora.

We are syncing the Vat ID to Zuora with the change in https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/371.

Although this would update for new records - we need to add a rake task to sync data for existing records.

cc: @csotomango

Story points: 1.0
Prevent GitLab.com features from affecting Self-Managed customers

<!-- 
Please remove /confidential from the bottom if this issue can be made public.

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 are integrating more tightly the customer portal into GitLab EE, and it means that more GitLab.com only code will end up there, potentially increasing the leakage to self-manage.

This is a corrective action from the RCA: https://gitlab.com/gitlab-org/fulfillment-meta/issues/34

### Proposal

A few ideas could be:

1. Add a Danger warning when touching specific SaaS code
1. Add a checkbox in the MR to make sure we double-check we are guarding against this
1. Abstract and extract specific code so it is easier to put a high-level check or some sort of gateway to check for `.com?`
1. Extract this code into a Gem, engine, or different service, easier to include/exclude depending on being a `.com?` feature
1. Keep this code in the customer's app, focusing on a transparent transition to the customer (from `.com?` to the customer portal, they will appear the same).

### Result

More safety towards this kind of bugs, or total prevention

### Next steps (if any)

Gather more ideas and agree on one or more in order to prevent the leakage situation


cc @rdavila @stanhu @dennis

Story points: 5.0
Follow-up from "Increase helpers test coverage" - Deprecate plan_quantity_label and gitlab_com_plan_name

The following discussion from !373 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/373#note_190486793):  (+1 comment)

    > I ended up writing tests for this method (`plan_quantity_label`) but I never found it referenced anywhere.  I was wondering if we should just remove it.  Same question for the method below, `gitlab_com_plan_name`.

Story points: 1.0
Customer Portal: change copy from downgrade to upgrade

Working Group for Licensing and Transaction To Do:

Change the copy in the customer portal from:

*Need to downgrade?  Please contact us and we can assist.*

To:

*Looking to Upgrade?
Ready to add more support or more DevOps features? See our [pricing page](https://about.gitlab.com/pricing/) for details on our package options.  Then, contact us and we can assist in your upgrade. 
Need to downgrade?  Please [contact us](https://about.gitlab.com/sales/) and we can assist.*

The pricing page link should open in a new tab.

Current: 
![Screen_Shot_2019-07-12_at_11.42.59_AM](/uploads/4e6502fc935d110d5dd91be73edc8e4b/Screen_Shot_2019-07-12_at_11.42.59_AM.png)

Story points: 1.0
Follow-up from "Remove countries that are embargoed"

The following discussion from !369 should be addressed:

- [ ] @jameslopez started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/369#note_188659091):  (+1 comment)

    > Thanks @asubramanian1 - LGTM, left some nitpicks. 
    > 
    > [My initial idea](https://gitlab.com/gitlab-org/customers-gitlab-com/issues/554#note_186932864) was to have a table with this and add it to `RailsAdmin`, so it can be easily modified. However, since this is a bit urgent, your changes make sense :rocket:

Story points: 2.0
Integration with SFDC is broken due to invalid credentials

### Problem

Salesforce credentials used by the subscription portal has been updated without notice to the Fulfillment team:

```
irb(main):001:0> Salesforce::LeadsFinder.find_by(Email: 'ruben@gitlab.com')
Restforce::AuthenticationError: invalid_grant: authentication failure
	from /home/gitlab-customers/customers-gitlab-com/vendor/bundle/ruby/2.3.0/gems/restforce-2.2.1/lib/restforce/middleware/authentication.rb:28:in `authenticate!'
	from /home/gitlab-customers/customers-gitlab-com/vendor/bundle/ruby/2.3.0/gems/restforce-2.2.1/lib/restforce/middleware/authentication.rb:15:in `rescue in call'
	from /home/gitlab-customers/customers-gitlab-com/vendor/bundle/ruby/2.3.0/gems/restforce-2.2.1/lib/restforce/middleware/authentication.rb:13:in `call'
	from /home/gitlab-customers/customers-gitlab-com/vendor/bundle/ruby/2.3.0/gems/faraday_middleware-0.10.0/lib/faraday_middleware/request/encode_json.rb:23:in `call'
```

Username being used is `sfdcadmins@gitlab.com`

### Proposal

Share the new credentials and inform the Fulfillment team the next time they're going to be updated so the integration keeps working.

### Result

Generation of Leads and Opportunities will always work fine. 

### Next steps (if any)

Inform the Production team about the new credentials so they can be updated in the Chef vault.

Story points: 1.0
User Settings Billing Page Improvement - Avatar and Username

### Proposal

* The top illustration to include the users Avatar at the largest size. This is to help closer link the current active Subscription with the users custom namespace.
* Include the username in the reference copy. 

**[Design Specs](https://gitlab-org.gitlab.io/gitlab-design/hosted/tim/cg%23545-user-settings-billing-page-improvement-avatar-spec-previews/)**

![4._User_Settings_-_Proposal_MVC_2x](/uploads/151eda17a2994cba3b27aba899a033eb/4._User_Settings_-_Proposal_MVC_2x.png)

Story points: 1.0
Increase lib test coverage 2/2

<!-- 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

Libraries with low or no test coverage:

```
lib/client/gitlab_app.rb	42.86 %
lib/zuora/coupon.rb	44.12 %
lib/world.rb	45.45 %
lib/salesforce/leads_finder.rb	50.0 %
lib/feature.rb	56.1 %
lib/rails_admin/list_gitlab_namespaces.rb	57.14 %
lib/client/promotion_code_app.rb	58.82 %
lib/null_request_store.rb	62.5 %
lib/safe_request_store.rb	63.64 %
lib/rails_admin/resend_eula.rb	66.67 %
lib/rate_plan_helper.rb	66.67 %
lib/health_check/db_check.rb	70.0 %
```

### Proposal

Increase the test coverage of these classes, ideally up to 70%

### Result

### Next steps (if any)

Story points: 3.0
Increase lib test coverage 1/2

<!-- 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

Libraries with low or no test coverage:

```
lib/rails_admin/update_gitlab_namespace_plan.rb	16.98 %
lib/database/migrations_helper.rb	25.76 %
lib/zuora/digital_signature.rb	30.77 %
lib/validators/subscription_validator.rb	36.67 %
lib/health_check/response.rb	38.46 %
lib/subscription_params_generator.rb	38.46 %
lib/custom_error_handler.rb	40.0 %
lib/health_check/base.rb	40.0 %
```

### Proposal

Increase the test coverage of these files, ideally up to 70%

### Result

### Next steps (if any)

Story points: 3.0
Increase helpers test coverage

<!-- 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

Helpers with low or no test coverage:

```
app/helpers/instance_review_helper.rb	20.0 %
app/helpers/payment_methods_helper.rb	28.57 %
app/helpers/eula_requests_helper.rb	50.0 %
app/helpers/plans_helper.rb	50.0 %
app/helpers/appearances_helper.rb	66.67 %
app/helpers/navigation_helper.rb	67.65 %
```

### Proposal

Increase the test coverage of these helpers, ideally up to 70%

### Result

### Next steps (if any)

Story points: 3.0
Increase mailers test coverage

<!-- 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

Mailers with low or no test coverage:

```
app/mailers/recurly_migration_mailer.rb	0.0 %
app/mailers/admin_mailer.rb	36.84 %
app/mailers/customer_mailer.rb	39.39 %
vendor/ruby/2.3.0/gems/devise-3.5.6/app/mailers/devise/mailer.rb	64.29 % (?)
```

### Proposal

Increase the test coverage of these mailers, ideally up to 70%

### Result

### Next steps (if any)

Story points: 2.0
Increase models test coverage

<!-- 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

Models with low or no test coverage:

```
app/models/payment_form/ach.rb	0.0 %
app/models/payment_method.rb	0.0 %
app/models/receipt.rb	0.0 %
app/models/subscription.rb	43.3 %
app/models/concerns/gitlab_com_helpers.rb	50.0 %
app/models/amend_generator.rb	51.16 %
app/models/eula_request.rb	52.5 %
app/models/order.rb	58.97 %
app/models/product.rb	60.0 %
app/models/eula.rb	62.5 %
app/models/trial_user.rb	70.59 %
```

### Proposal

Increase the test coverage of these models, ideally up to 70%

### Result

### Next steps (if any)

Story points: 3.0
Increase controllers test coverage

<!-- 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

Controllers with low or no test coverage:

```
app/controllers/ngrok_controller.rb	0.0 %
app/controllers/orders_controller.rb	0.0 %
app/controllers/payment_methods_controller.rb	0.0 %
app/controllers/receipts_controller.rb	0.0 %
app/controllers/zuora_callbacks_controller.rb	0.0 %
app/controllers/registrations_controller.rb	60.0 %
app/controllers/subscriptions_controller.rb	62.67 %
app/controllers/health_controller.rb	72.73 %
```

SimpleCov also shows these:

```
vendor/ruby/2.3.0/gems/devise-3.5.6/app/controllers/devise/registrations_controller.rb	43.24 % 
vendor/ruby/2.3.0/gems/devise-3.5.6/app/controllers/devise/omniauth_callbacks_controller.rb	50.0 %
vendor/ruby/2.3.0/gems/devise-3.5.6/app/controllers/devise/confirmations_controller.rb	56.0 %
vendor/ruby/2.3.0/gems/devise-3.5.6/app/controllers/devise/sessions_controller.rb	57.78 %
vendor/ruby/2.3.0/gems/devise-3.5.6/app/controllers/devise_controller.rb	73.75 %
```

Unsure if that's an issue with SimpleCov/CI reporting this erroneously.


### Proposal

Increase the test coverage of these controllers, ideally up to 70%

### Result

### Next steps (if any)

Story points: 5.0
Update Ruby to latest 2.6

### Problem

* Security issues
* Reduced speed
* Catching up with GitLab CE/EE development
* Development alignment with other GitLab repos

### Proposal

Update Ruby to `2.6`

To be done after https://gitlab.com/gitlab-org/customers-gitlab-com/issues/496

### Result

### Next steps (if any)

Test on staging

Story points: 2.0
Content spoof on https://customers.gitlab.com

**[HackerOne report #448781](https://hackerone.com/reports/448781)** by gopinath6 on 2018-11-22:

&gt; NOTE! Thanks for submitting a report! Please replace *all* the [square] sections below with the pertinent details. Remember, the more detail you provide, the easier it is for us to triage and respond quickly, so be sure to take your time filling out the report!

**Summary:** 
Content spoof on https://customers.gitlab.com

**Description:** 
An attacker modifies content to make it contain something other than what the original content producer intended while keeping the apparent source of the content unchanged. Upon visiting this link the user would believe the content being displayed as legitimate

In the below url error message is not sanitized, user input messages are reflected back to user 

## Steps To Reproduce:

In browser go to 
https://customers.gitlab.com/subscriptions/error?msg=Right%20now,%20we%20are%20facing%20issue.Please%20send%20USD%20to%20this%20btc%20address%202d3dff34455345ffee


## Supporting Material/References:

  * List any additional material (e.g. screenshots, logs, etc.)

## Impact

In this example the falsified content is directly reflected back on the same page. This presents the user with a modified page under the context of the trusted domain.
Attacker  can make user  to send btc to his address of any other spoof message.

## Attachments
**Warning:** Attachments received through HackerOne, please exercise caution!
* [spoof.PNG](https://h1.sec.gitlab.net/a/448781/379310/spoof.PNG)

Story points: 2.0
Check if the Lead has been converted before updating it

If the user has requested previously a license and the lead has been converted, if he requests again a license when we update the Lead, it will throw an error.

https://sentry.gitlap.com/gitlab/customersgitlabcom/issues/180957/

```
Faraday::ClientError: CANNOT_UPDATE_CONVERTED_LEAD: cannot reference converted lead
  app/services/create_salesforce_lead_service.rb:43:in `update_lead'
    SalesforceClient.update!('Lead', params)
  app/services/create_salesforce_lead_service.rb:32:in `create_or_update'
    update_lead(params.merge(Id: existing_id))
  app/services/create_salesforce_lead_service.rb:23:in `create_or_update_lead'
    create_or_update(from_params)
  app/services/create_salesforce_lead_service.rb:8:in `execute'
    lead_id = create_or_update_lead
  app/controllers/trials_controller.rb:39:in `create_salesforce_lead'
    CreateSalesforceLeadService.new.execute(trial_user_params)
...
(104 additional frame(s) were not displayed)

Faraday::ClientError: CANNOT_UPDATE_CONVERTED_LEAD: cannot reference converted lead
```

Story points: 2.0