giseldo/neodataset huggingface dataset:
Self-instance with a valid premium license is using the free plan name

<!---
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

Self-managed instance with a license shows `free` as their `actual_plan` object, instead of the `default` plan object.

### Steps to reproduce

Unknown currently. I'm only aware [that the customer that has been affected](https://gitlab.zendesk.com/agent/tickets/196781) (internal link) has had the instance for a very long time (~2+ years).

### What is the current *bug* behavior?

Performing any changes to the `default` plan object does not work when raising application limits.

### What is the expected *correct* behavior?

Performing changes to the `default` plan object should work when raising application limits.

### Relevant logs and/or screenshots

```
irb(main):001:0> project = Project.find_by_full_path("group/project")
=> #<Project id:1234 group/project>>
irb(main):002:0> pp project.actual_plan_name
"free"
```

The `free` plan is returned for all projects and groups, newly created, or existing ones. Expected was the `default` plan.

```
irb(main):003:0> pp Gitlab.com? 
false 
```

### Workarounds

(Ways to get around the issue)

Application limits can be updated on the `free` plan object instead of the `default` one.

### Reported examples

1. https://gitlab.zendesk.com/agent/tickets/196781 (internal link)

<!---
Please add both severity and priority level according to: https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#severity-labels
--->

Story points: 3.0
[FE] Breakdown: Improve provisioning and onboarding of new sales-assisted GitLab.com subscribers

This ~frontend issue (for https://gitlab.com/groups/gitlab-org/-/epics/5012) will be used to track breakdown work. As a result, new FE issues will be created.  

## Design

[See UX issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2040/)

Story points: 3.0
Check if param can be omitted from subscriptions#update request

While testing something with subscriptions, I noticed that a param called `subscription` is sent with the `subscriptions#update` request. That parameter is being logged as unpermitted and I don't see any usage of it. So we should omit it from the request if it's not used.

First investigations can't point to an exact place where this param gets set though. So this needs further investigation.

**Rails log example:**

```
Started PUT "/subscriptions/A-S00038066" for 95.88.20.212 at 2020-06-18 13:25:06 +0200
 Parameters: {"subscription_id"=>"A-S00038066", "gl_namespace_name"=>"Kesha Heller", "gl_namespace_id"=>2, "preview"=>false, "payment_method_id"=>"2c92c0f9725046a0017256792f035e2f", "new_product_id"=>"2c92c0f8725e55d70172613f547f0b59", "new_product_quantity"=>1, "id"=>"A-S00038066", "subscription"=>{"subscription_id"=>"A-S00038066", "gl_namespace_name"=>"Kesha Heller", "gl_namespace_id"=>2, "preview"=>false, "payment_method_id"=>"2c92c0f9725046a0017256792f035e2f", "new_product_id"=>"2c92c0f8725e55d70172613f547f0b59", "new_product_quantity"=>1}}
  Customer Load (0.3ms)  SELECT  "customers".* FROM "customers" WHERE "customers"."id" = $1 ORDER BY "customers"."id" ASC LIMIT $2  [["id", 1], ["LIMIT", 1]]
  ↳ app/controllers/concerns/unleash_helper.rb:33
  Feature::FlipperGate Load (0.4ms)  SELECT "feature_gates".* FROM "feature_gates" WHERE "feature_gates"."feature_key" = $1  [["feature_key", "compliance_check"]]
  ↳ lib/feature.rb:52
Unpermitted parameter: :subscription
```

Story points: 2.0
Hard-Coded Secrets in Application Source Code - NCC Group finding

<!-- 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 following issue was identified during a contracted pentest by the NCC Group. The test was held June 1-11, 2020.

### Problem

There has been a long history of source code disclosure vulnerabilities in web and application servers. Any of these in conjunction with hard-coded secrets in an application’s source could result in their compromise. Additionally, improper server configuration could result in these files being readable by external users. Finally, code is often stored in code repositories with loose access controls, creating another point of potential compromise.

Here is a redacted snippet of hard-coded secrets:
```ruby
request:
    method: post
    uri: https://test.salesforce.com/services/oauth2/token
    body:
      string: grant_type=password&client_id=[REDACTED]&client_secret=[REDACTED]&u
    sername=[REDACTED]&password=[REDACTED]
    ...
  response:
...
string: '{"access_token":"<ACCESS_TOKEN>","instance_url":"https://cs63.sale sforce.com","id":"https://test.salesforce.com/id/00D6C0000004d0KUAQ/005610000 024BDwAAM","token_type":"Bearer","issued_at":"1589895566673","signature":"[RE DACTED]"}'
```

It appears that these secrets are used mostly in development or staging environments, thus lowering the severity.

The following file locations are affected:
* README.md:78
* README.md:148
* config/secrets.yml.example:59
* db/seeds.rb:18
* spec/fixtures/vcr_cassettes/Change_namespace_of_existing_subscription/change_group_of_active_subscription/successfully_change_namespace_for_subscription.yml:600
* spec/fixtures/vcr_cassettes/zuora_ee_plan_fetch.yml:88

### Proposal

Sensitive data should not be stored directly in source, but should instead be referenced from configuration files that exist outside of the application’s root. When checking code into a repository, use example files or stubs which are overwritten when the application is deployed.

All secrets that have been checked into the source code repositories should be considered compromised, and changed.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Do not render "Change linked namespace" for CI only 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/

-->

Rather lengthy discussion here: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1470#note_358179305

This button is functionally broken (not provisioning) when used for CI minutes purchases. So let's not push our users to do this.

Story points: 2.0
Graduate Payment Methods page from feature flag

### Problem

The [`pajamas_payment_methods`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/3/edit) feature flag has been turn on for production for more than 2 months.

I discovered that the style of `.btn-link` class is overriding what it should like in Pajama's design system, and the only place it's being used in is the old payment methods page.


### Proposal

Graduating payment methods from feature flags.

### Steps

- [x] Remove instances of `pajamas_payment_methods`
- [x] Remove old HAML implementation of payment methods pages 
- [x] Remove old HAML specific styles (most notably `.btn-link` in `components.scss`)
- [x] Remove specs that test payment methods pages without feature flag
- [x] Delete `pajamas_payment_methods` feature flag in https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags
- [x] Clean up `paymentCallback` in `app/assets/javascripts/payment_methods.js`
- [x] Replace `payment_methods/*` partials with `pajamas/payment_methods/*` 

### Result

Consistent styles with Pajama's and less deprecated code to worry about.

### Next steps (if any)

Schedule the issue to be worked on.

Story points: 3.0
Sales-assisted .com deals sold for less seats than the current active user count shouldn't disassociate the subscription and downgrade the namespace to free

### Problem
An issue was reported on 2020-06-10 by Sales that a .com customer who had purchased a renewal for a user count less than the currently active user count was inadvertently downgraded to free. 

Based on the investigation, it appears that since the new subscription was for less than the currently active user count, the portal did not know what to do and it caused the namespace to become unlinked from both the previous and new subscription and downgraded them to free. 


### Proposal
Determine the best way to handle this scenario - some options: 

- Allow the namespace to be associated to the new subscription, although they are already over their user count. Co-terms will ultimately capture this lost revenue 
- Charge/invoice the card/customer for the difference 
- Provide some kind of messaging to the Salesperson associated with the renewal so they can take action 


### Result
Happy customers, less errors 


### Next steps (if any)

### How will we measure success?

Story points: 5.0
Cannot change plan on trial via admin

When trying to change trial for the group, threw the error below: https://customers.gitlab.com/admin/customer/178872/list_gitlab_namespaces

From bronze to silver

Sentry Issue: [CUSTOMERSGITLABCOM-3G6](https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1632227/?referrer=gitlab_integration)

```
RuntimeError: Error updating namespace 8011668 with params {:plan=>"silver", :shared_runners_minutes_limit=>10000, :trial_ends_on=>Thu, 25 Jun 2020}: "{\"message\":\"500 Internal Server Error\"}"
  app/services/gitlab/namespace/update_service.rb:35:in `update_namespace'
    raise "Error updating namespace #{@namespace_id} with params #{@attrs.inspect}: #{response.body.inspect}"
  app/services/gitlab/namespace/update_service.rb:16:in `execute'
    { success: true } if update_namespace
  lib/rails_admin/update_gitlab_namespace_plan.rb:60:in `update_plan'
    result = Gitlab::Namespace::UpdateService.new(params[:gitlab_namespace_id], gitlab_params).execute
  lib/rails_admin/update_gitlab_namespace_plan.rb:89:in `block (2 levels) in <class:UpdateGitlabNamespacePlan>'
    result = update_plan
  app/middleware/basic_health_check.rb:20:in `call'
    return @app.call(env) unless env['PATH_INFO'] == HEALTH_PATH
...
(88 additional frame(s) were not displayed)

RuntimeError: Error updating namespace 8011668 with params {:plan=>"silver", :shared_runners_minutes_limit=>10000, :trial_ends_on=>Thu, 25 Jun 2020}: "{\"message\":\"500 Internal Server Error\"}"
```

Story points: 2.0
Investigate and fix intermittent failures in renewal spec

Job [#586387342](https://gitlab.com/gitlab-org/customers-gitlab-com/-/jobs/586387342) failed for 4e4b442fb5061725e43bce28d9b24c6dd38450ce:


We're seeing the feature spec `./spec/features/existing_customers/renewal_spec.rb` fail every once in a while.

After the fact it's pretty difficult to figure out what went wrong.

We need to identify what's the cause of this flakiness.

* Race condition in spec?
* Non-deterministic behaviour?
* Is the spec correct but the `AmendSubscriptionService` is flaky?
* Is VCR not matching HTTP requests?

### Proposal

Maybe it makes sense to put in a number of log statements in the `AmendSubscriptionService` to get a better idea of where in the flow this breaks.
We can start by adding a logger("Amend Start") at the beginning and logger("Amend Ended Successfully")  to see if it’s the feature spec or the service that’s failing.

Story points: 1.0
Adding more user in subscription does not generate a working license

<!---
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

When customer add more users in subscription in customer portal, a new license is generated. Customer portal will generate a working license the for the updated license. However, if customer add more users later on during the same license period, all the new license will have the `Previous users count` of the `Users count` at the beginning of license term and `True-up` of the first Add more users of the license.

### Steps to reproduce

1. Purchase License term: 2020-05-01 - 2021-05-01 and upload to the system. 
    - Users count originally purchase: `50`


2. Add more user `7` to the license for the first time 2020-05-30 and upload to the system:
   - New Users count: `57`
   - Previous users count: `50`
   - True-up: `7` 


3. Add more user `10` to the license for the second time 2020-06-02 and upload to the system:
   - New `Users count`: `67`
   - Previous users count: `50`
   - True-up: `7`


4. Add more user `20` to the license for the third time 2020-06-05 and upload to the system:
   - New `Users count`: `87`
   - Previous users count: `50`
   - True-up: `7`

This would cause error when uploading `#3` and `#4` because they are not referencing the license currently on the system.

### What is the current *bug* behavior?

New license after adding more users to license multiple time keep referencing the license at the beginning of the license term.

### What is the expected *correct* behavior?

Add more users to license multiple time should correctly referencing the latest license on the system.

### Workarounds

Manually generate a working license

### Reported examples

1. https://gitlab.zendesk.com/agent/tickets/159073
1. https://gitlab.zendesk.com/agent/tickets/160766
1. 

<!---
Please add both severity and priority level according to: https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#severity-labels
--->

Story points: 2.0
NoMethodError/sidekiq undefined method `match' for #<Rack::Session::SessionId:0x000000000b50f5e0>

<!-- 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

Admins are unable to access Sidekiq's [admin panel](https://customers.gitlab.com/sidekiq)

[Link to Sentry error](https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1639321/?query=is%3Aunresolved)

### Proposal

Investigate the root of the issue and fix it.

As a side note, looks like the ability to create an issue from Sentry is not properly configured (It used to work).

### Result

We will be able to see some unexpected errors raised by Sidekiq.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Follow-up from "Introduce service to close salesforce opportunity"

The following discussion from !1463 should be addressed:

- [ ] @jameslopez started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1463#note_354153731): 

    > hmm we should probably grab `strong_memoize` from GitLab :thinking:

Since we are already adding something new from GitLab, we can also add a cop to encourage its usage as suggestion in [this comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1490#note_355475434).

Story points: 1.0
Customers cannot create account by Signing in from GitLab.com

<!---
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

Sign in via GitLab.com to register is not working on [customers portal](https://customers.gitlab.com/customers/sign_in) if customer click on `Buy more CI minutes` on GitLab.com through either group or personal `Usage quotas` page. 

### Steps to reproduce

1. Have a new account on GitLab.com
1. Go to a group/personal `Usage quotas` page
1. Click on `Buy more CI minutes` → you'll be redirected to https://customers.gitlab.com/buy_pipeline_minutes
1. Click on `Sign in to GitLab.com` → presented with `Please complete the required fields.` message without a registration form (see screenshot below)

### What is the current *bug* behavior?

Users cannot register on [customers portal](https://customers.gitlab.com/customers/sign_in) when redirected from the `Buy more CI minutes` button on `Usage quotas` page

### What is the expected *correct* behavior?

Users is presented with a form to register on [customers portal](https://customers.gitlab.com/customers/sign_in). 

Clicking through `Manage` or `Upgrade` in billing page works normally. 

### Relevant logs and/or screenshots

![image](/uploads/791db4316edca23cba35598639ba3acd/image.png)

### Workarounds

One of the following:

- Register and Sign into [customers portal](https://customers.gitlab.com/customers/sign_in) and [change linked account](https://docs.gitlab.com/ee/subscriptions/#change-the-linked-account) afterward
- Click on `Manage` button in the billing page instead
  - Group namespace → Settings → Billing
  - Personal namespace → Profile icon at the top right → Settings → Billing

### Reported examples

1. https://gitlab.zendesk.com/agent/tickets/158273
1. https://forum.gitlab.com/t/cant-purchase-additional-ci-minutes-please-complete-the-required-fields-but-there-are-no-fields/35161
1. https://gitlab.zendesk.com/agent/tickets/162646
1. https://gitlab.zendesk.com/agent/tickets/162733

<!---
Please add both severity and priority level according to: https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#severity-labels
--->

Story points: 2.0
Possibilty to purchase Ultimate - 1 Year (EDU or OSS)

**[HackerOne report #882848](https://hackerone.com/reports/882848)** by `steppe` on 2020-05-26, assigned to @cmaxim:

Hi,

Any user can purchase Ultimate - 1 Year (EDU or OSS) which is for educational institutions or open source projects.I have found here https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/860 list of Gitlab plan id and found  Ultimate - 1 Year which is  free and purchased.

Steps to reproduce:

Login in to your account https://customers.gitlab.com/  
And go to  https://customers.gitlab.com/subscriptions/new?plan_id=2c92a0fd63afe3fd0163d87aecee230a&transaction=create_subscription

Best,  
[@]steppe

## Impact

Attacker can bypass GitLab for Education Program Requirements.

Story points: 2.0
Faraday::Error::ClientErrorSidekiq/CreateSalesforceOpportunityWorker

REF: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1475#note_352103341

### Problem

Sentry details: https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1626298/?query=is%3Aunresolved

Possible reasons from SFDC forums: https://developer.salesforce.com/forums/?id=906F00000008m69IAA

### Proposal

Retry the Opp creation in case it is not automatically created by SFDC.

### Result

Opp will not be missing.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Pajamas Update: Self-Managed "New Subscription" Page

It's being managed under [`pajamas_new_subscription`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/43/edit) feature flag.

### Problem

In order to match Pajama's design that we follow we should migrate the `New Self-Managed Subscription` page.

#### 1st step

| EE | GL.com  |
| ------ | ------ |
| ![image](/uploads/81e845f91a0c42b809503f711265b6b4/image.png) | ![image](/uploads/e913c0a8de21ebe4c12c20509fc65955/image.png)

#### 2nd (and final) step

| EE | GL.com |
| ------ | ------ |
| ![image](/uploads/4f1d6e5fcf799b62a90a52ec0be209df/image.png) | ![image](/uploads/58cdedd73d6ddc5ca6b0050768131cd1/image.png) |

### Proposal

![](/uploads/8fd9712e79f7b9b890863495f101ee55/GitLab.com_-_Buy_subscription__1_.png)

This will give us unified UX when the customer sits on a single page to complete the checkout process across the application.

Story points: 5.0
Update Ruby to 2.6.6

## Proposal
The main repo [will update Ruby](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33253) from 2.6.5 to 2.6.6 soon.

To be in sync we should update it too.

[Ruby 2.6.6 includes two security fixes.](https://www.ruby-lang.org/en/news/2020/03/31/ruby-2-6-6-released/) This is a safe update.

### Related [cookbook-customers-gitlab-com](https://gitlab.com/gitlab-cookbooks/cookbook-customers-gitlab-com) MRs:
* [Bump customers.stg ruby version to 2.6.6](https://gitlab.com/gitlab-cookbooks/cookbook-customers-gitlab-com/-/merge_requests/98)
* [Bump customers (prod) ruby version to 2.6.6](https://gitlab.com/gitlab-cookbooks/cookbook-customers-gitlab-com/-/merge_requests/99)

Story points: 2.0
Block portal access for existing reseller customers

### Problem
With #1373, Customers created via reseller subscriptions will be blocked from portal access.  However, we still need to block existing reseller customers.

### Proposal
Create a temporary rake task to set `login_activated = false` for all existing reseller customers.

### Result
Once the `block_reseller_customer` feature goes live, we can run this rake task in production.

Story points: 1.0
Remove the `block_reseller_customer` feature flag

### Problem
Once the `block_reseller_customer` feature flag has been on for a while and the features are stable, the legacy will need to be removed.

### Proposal
Once we've vetted the feature, we should remove `block_reseller_customer` feature flag checks from the code and remove the legacy code.  Also, remove the temporary rake task, `reseller_customers:deactivate_login`, introduced in !1464.

After the MR merges and deployed into production, we can safely remove the feature flag from https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags.

### Result
A cleaner code base.

Story points: 1.0
Clean-up: Pajamas Change Namespace page

We enabled the feature flag in #1406, this is a scheduled issue to clean up the old code that's related to change namespace page if there're no issues reported.

I'll schedule this after 6 weeks rather than 3 weeks since it's not a common page to be used by our customers, 6 weeks would be a more suitable time to get any report or feedback about it.

Story points: 2.0
Username is capitalized unnecessary on the account details 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

@gtsiolis reported that it might be unnecessary to capitalize the username on the account details page.

![image](/uploads/c0889103dbf7c2f1c122df680f322495/image.png)

Story points: 1.0