giseldo/neodataset huggingface dataset:
Remove :stop_eula_requests feature flag

Once the [new EULA process](https://gitlab.com/gitlab-org/gitlab/-/issues/224712) is live and [the `:stop_eula_requests` feature flag](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/63/edit) is turned on in production, we should be free to remove the flag and the associated EULA requests code.  The flag was simply created in order to more easily time the roll out in conjunction with the new EULA process.  I think once the flag has been enabled for a day or so it should be safe to remove.

For reference, the feature flag was introduced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1855.  Additional code related to this feature flag was introduced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1857.

We will also need to remove the following related code as well:
  - https://gitlab.com/gitlab-org/customers-gitlab-com/blob/0d06456d94f06cc46671776e0f9df622cefc3a02/lib/rails_admin/resend_eula.rb#L6
  - https://gitlab.com/gitlab-org/customers-gitlab-com/blob/154152723d1f0a9af846573222eda73082368ffb/config/initializers/rails_admin.rb#L4
  - https://gitlab.com/gitlab-org/customers-gitlab-com/blob/62170a0d134d3758c307f2803c8c3dac663c1796/config/locales/en.yml#L25

Also, there are references to files to be removed as part of this issue in .rubocop_todo.yml that will no longer be needed (e.g. https://gitlab.com/gitlab-org/customers-gitlab-com/blob/154152723d1f0a9af846573222eda73082368ffb/.rubocop_todo.yml#L727).

Story points: 1.0
Cleanup for subscriptions with deleted group/namespace

Original issue: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1273

This should be done after the work for https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1879 is completed.

### Problem
Subscriptions that are linked to deleted GitLab groups/namespaces cause errors in the Customers Portal due to the a fetch request to GitLab for that group/namespace.

### Proposal
With the work in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1879 this scenario is being prevented. So after the work for https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1879  is completed, the existing inconsistencies because of that problem should be resolved. 

These are two possible solutions:
- update existing subscriptions that are linked to deleted groups/namespaces to set the attributes `gl_namespace_id` and `gl_namespace_name` to nil
- make Customers Portal's code fail-safe by not trying to fetch data when the group/namespace can't be found (e.g. in `GitLab::Namespace::UpdatePlanInfoService` which gets called on namespace change)

### Result
No errors due to inconsistencies that were caused by subscriptions linked to deleted groups/namespaces.

### Next steps (if any)


### How will we measure success?
No errors due to inconsistencies that were caused by subscriptions linked to deleted groups/namespaces.

Story points: 2.0
BE: Prevent deletion of groups/namespaces when they have a subscription

Original issue: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1273

### Problem
The deletion of groups/namespaces with linked subscriptions are creating inconsistencies between GitLab and the Customers Portal. The linked group/namespace can't be fetched on the Customers Portal side on update like changing namespace and results in an error (500).

### Proposal
Prevent groups/namespaces from being deleted when they have a subscription. A group/namespace has to be disassociated from any linked subscriptions before deletion.

It should also be checked what happens to a subscription when a group gets transferred. The current assumption is that the subscription does not change.

### Design

[See UX issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1923)

### Result
Keep data between GitLab and Customers portal in sync.

### Next steps (if any)
- Disable the `Delete group` button when deleting a group
- Add an info text about disassociating any subscriptions first
- Prevent deletion in the backend

### How will we measure success?
No error on the Customers Portal side because of deleted groups/namespaces in subscriptions.

Story points: 2.0
Customer cannot add new card during renewal/new purchase


### Summary

When customer try to renew a subscription using a new credit card, the purchase will give an error if the customer is trying to use a different card that's not stored on their account.

### Steps to reproduce

1. Have a self-managed subscription
1. Select Renew button
1. During checkout, choose `Add new credit card` option
1. Add credit card details ([stripe test credit cards](https://stripe.com/docs/testing#cards))
1. See the purchase error

### Error
![Issue_1877](/uploads/f7d864149828a89009fd3d283e3a1b80/Issue_1877.gif)

### What is the current *bug* behavior?

Customer cannot pay with a different than the existing one(s?)

### What is the expected *correct* behavior?

Customer should be able to successfully purchase with different card than the default one.

### Relevant logs and/or screenshots

These look like  SOAP-related errors
- [Sentry errors](https://sentry.gitlab.net/gitlab/customersgitlabcom/?query=is%3Aunresolved+user%3A120855): 
- https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1773339/?query=is%3Aunresolved%20user%3A120855
- https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1768435/?query=is%3Aunresolved%20user%3A120855
- https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1181887/?query=is%3Aunresolved%20user%3A120855

### Workarounds

Instruction for customer:

1.  Sign in to [customers portal](https://customers.gitlab.com/customers/sign_in)
2.  Navigate to `My account` → `Payment methods`
3.  Click on `Add new payment method` → Fill in all the information
4.  Edit the new card, fill in the information and make sure that the `Make default payment method` box is checked → click `Save changes`
5.  Try to renew again



### Reported examples

1. https://gitlab.zendesk.com/agent/tickets/169982
- Zuora account: https://www.zuora.com/apps/CustomerAccount.do?method=view&id=2c92a0fe6d151c5b016d161751fb0dca
- No prior refunds: https://gitlab.my.salesforce.com/0014M00001jCFVz?srPos=0&srKp=001

1. https://gitlab.zendesk.com/agent/tickets/169925
- Zuora account: https://www.zuora.com/apps/CustomerAccount.do?method=view&id=2c92a0086d4dcd5a016d62ea6f807df1
- No prior refunds: https://gitlab.my.salesforce.com/0014M00001jCq6h?srPos=0&srKp=003

<!---
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
Cap percentageUsed at 0% and on 100% if return value is out of range

### Problem

With the following data:

| now          | start date   | end date     |
| ------------ | ------------ | ------------ |
| `2018-04-02` | `2018-05-02` | `2019-05-02` |


The percentage used should be: `0%`, but the current implementation is returning `-8%`

---

With the following data:

| now          | start date   | end date     |
| ------------ | ------------ | ------------ |
| `2020-04-02` | `2018-05-02` | `2019-05-02` |

The percentage used should be: `100%`, but the current implementation will return something like `240%`

### How to reproduce

Renew a subscription 2+ times then go to "add more seats" page (the pajama's page) and see the percentage.

Example of the issue:

![](https://gitlab.com/gitlab-org/customers-gitlab-com/uploads/430e7f340829449e9344fd0217eb5fa0/Screenshot_2020-08-24_at_11.31.54_AM.png)


### Proposal

We need to cap `percentageUsed` to:

- `0%` if the `start date` is in the future.
- `100%` if the `end date` is in the past.

### Result

We will have realistic percentages and we can unblock shipping #1808.

### Next steps (if any)

Adding this issue to %"13.4" since it's blocking other issues in the milestone.

Story points: 2.0
Remove SOAP matches from VCR spec matcher

<!-- 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/

-->

Once we've stopped using SOAP endpoints we need to clean up SOAP usages in the test suite: 

- [x] Remove [`method_with_soap_support`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/63fb053af4231ec3005b90abd240a4cf837db063/spec/support/vcr.rb#L45) 
- [x] Remove [`SoapMatcher`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/1576acf0ccfcd349e1496a737b8af7613ca8322e/spec/support/vcr/soap_matcher.rb)
- [x] Remove [this part](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/86a674fc14aa21d81488b5583d57aac5e87de785/spec/support/vcr/custom_request_matcher.rb#L16-17) of `CustomRequestMatcher` that uses `SoapMatcher`.

Story points: 1.0
Self-Service Upgrades for Self-Managed

Original issue https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/107

This is the issue for the ~backend part.

### Problem
A user should be able to self-serve upgrade a paid self-managed subscription to a higher tier.

### Proposal
This workflow already exists for upgrading a .com subscription, so try reusing that logic as much as possible.

When upgrading an existing paid self-managed subscription to a higher tier:
* Prorate total price at the new rate for the remaining time, e.g. when upgrading a Starter subscription bought 4 months ago, only pay for the remaining 8 months for the new tier
* Create amendment with the same end date as the original subscription (syncs to Zuora)
* Generate new license key
* Send new license key to user
* Deprecate old license key
* Make sure this process works if it was triggered from Zuora directly instead of the Customers Portal (https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/353#note_120015198)

Story points: 3.0
Clarify that the customers portal is a separate platform

### Problem

When GitLab.com users purchase products or go to manage their subscription from within GitLab.com, they often don't realize that they were taken to a separate website. 
- Users are often confused by "Sign in with GitLab" because they believe they are still on GitLab.com and are already signed it. 
- For first time users, the customers portal registration step is confusing because users have trouble understanding why they are being asked to register again (not realizing they are on a separate website).

The root of these issues comes down to the fact that users don't notice that they are being sent to a separate website when they are redirected to the customers portal.

### Proposal

Our long term vision is to move all purchasing/subscription management out of the portal and into GitLab.com for SaaS customers. 

But in the short term, we can make the customers portal a better experience by being clearer about the fact that it is a website separate from GitLab.com and telling the user why that is.

### Design

[Figma](https://www.figma.com/file/hFQB3yZJTD7ZZlBNBNH2hw/Clarify-that-the-customers-portal-is-a-separate-platform?node-id=0%3A1)

**Important:** The implemented designs differ from the Figma designs and the designs attached as a result of some discussions. To iterate faster we decided not to modify the Figma file nor the attached designs. Here are the differences:
- Main h1 heading sits on its own row, just like in theGitLab signup page ([relevant discussion here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1865#note_416996380))
- Typography is the same as GitLab.com signup page; only notable exception is the paragraph, which will have the Pajamas h2 styles ([relevant discussion here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1865#note_417714030))
- The text in the paragraph changes to `The Customers Portal is a standalone site for managing payment and license information` ([relevant discussion here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1984#note_420799169))

### How to test?

#### Sign-in view
1. Go to https://customers.stg.gitlab.com/ and make sure you're signed out
1. Click **Sign In** in the top-right of the nav bar

#### Sign in w/GitLab view
1. Go to https://customers.stg.gitlab.com/ and make sure you're signed out
2. Click **Buy Now** for any of the plans
3. In the modal, choose the GitLab.com plan

### Follow-up Issue
https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2005

Story points: 2.0
Remove the :seat_link feature flag

### Problem
As [discussed here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1802#note_401767545), the `:seat_link` feature flag has been in use for quite some time without being turned off.  Seat link information has been persisted as expected for a while so this feature was successful.

### Proposal
Remove the `:seat_link` feature flag from the code base and remove the entry from [the feature flags management list](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags).

### Result

Story points: 1.0
Graduate pajamas_error_messages feature flag

We introduced a new look for showing error messages in #1021 under [`pajamas_error_messages`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/57/edit) feature flag.

It has been enabled on production since 10-04-2020, without any issue so far.

We need to graduate this change from the feature flag.

### Next steps (if any)

Schedule

### How will we measure success?

Story points: 1.0
Refactor AmendSubscriptionService#calculate_quantity

[Original discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1826#note_399344899) (+5 comments) from !1826.

The `AmendSubscriptionService#calculate_quantity` method is quite complex in its logic and should be evaluated to be refactored to something easier. A few possibilities were discussed [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1826#note_399344899).

Before refactoring, we should make sure that the method is 100% covered by specs, so that we are not missing a possible scenario from this method.

Story points: 2.0
Sync danger with GitLab updates

Noticed during https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1838 that there were some recent updates like the warning on 50 character commit limit (removal) and assignment for feature specs that hasn't been sync'd to this application yet.

We should do that along with a bit of restructure to match the GitLab danger implementation for easier updating.

Note: This will include the timezone details on reviewers


/cc @pcalder

Story points: 2.0
Follow-up from "Fix broken string concatenation"

Add test coverage for this route/path on eula_requests


The following discussion from !1818 should be addressed:

- [ ] @rdavila started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1818#note_398389379):  (+4 comments)

    > @dstull can you please review?

Story points: 1.0
Clean-up: graduate Pajama's add more seats page from feature flag

With #954 we introduced a new design for adding more seats page.

On 2020-08-21 we turned [`pajamas_add_seats`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/13/edit) feature flag on for production environment.

We should graduate this page from the feature flag after 2 milestones if there's nothing being reported.

Story points: 2.0
Unable to purchase CI minutes when subscription has been refunded before

### Summary

Customer is unable to purchase additional CI minutes, currently they're on a bronze plan and while trying to purchase additional CI minutes - the portal shows `Unknown error occurred` at checkout

### Steps to reproduce

1. Have a subscription
1. Try to purchase additional CI minutes 
1. see the purchase error

### Relevant logs and/or screenshots

https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1430650/?referrer=gitlab_plugin

```
malformed error

{
error: Not Found, 
status: 404
}

```

![Screenshot_2020-08-27_at_8.23.03_AM](/uploads/c6cd1ec4abe2a399ba45abf1a8c511c9/Screenshot_2020-08-27_at_8.23.03_AM.png)
**Zendesk Ticket**: [Ticket #168992](https://gitlab.zendesk.com/agent/tickets/168992)

SE issue: https://gitlab.com/gitlab-com/support/internal-requests/-/issues/2939 (Internal)

Examples:
1. Customer: https://customers.gitlab.com/admin/customer/131019/edit | Ticket: https://gitlab.zendesk.com/agent/tickets/169015

Story points: 2.0
Clean-up: graduate Pajama's renew subscription page from feature flag

With #955 we introduced a new design for renew subscription page.

On 2020-08-21 we turned [`pajamas_purchases_renew_subscription`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/59/edit) feature flag on for production environment.

We should graduate this page from the feature flag after 2 milestones if there's nothing being reported.

## Next action

- [x] Schedule the issue for development.
- [x] Create MR !2133 to clean up the code
- [x] Turn the feature flag off
- [x] Make sure nothing is broken
- [x] Delete the [feature flag](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/20/edit)

Story points: 2.0
Update renewal flow screenshots

## Summary

As a result of [this change](https://gitlab.com/gitlab-org/gitlab/-/issues/233823) we will need to update the screenshots in the self-managed renewal flow created in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/955 to display  `Billable users` instead of `Active Users`.


## Updated screenshots

| Users over license | Billable users |
| ------ | ------ |
| ![1](/uploads/05032489c20d42cfa8d5be1932a35b47/1.png) | ![2](/uploads/8da0a45b38d987d43136ef6cded46cb1/2.png) |

Story points: 1.0
Remove DB tables for Eula and EulaRequest

### Problem

As mentioned in [the epic](https://gitlab.com/groups/gitlab-org/-/epics/4225), we no longer require the manual EULA process. After a period of time (TBD), we will no longer need to preserve the data for existing EULAs or EULA Requests.

### Proposal

Once we've removed references to the models `Eula` and `EulaRequest` (as part of [this issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1842)), we should remove the tables from the database.

**Important Note: This issue is blocked until the new terms have been live for at least 90 days (e.g. 90 days after [the `stop_eula_requests` feature flag was enabled](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1882)).  [That occurred on 2020-10-13](https://gitlab.slack.com/archives/CMJ8JR0RH/p1602599797469400).  The exact date is TBD. See [this issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1602) for more information.**

Story points: 1.0
Document process of investigating "applying discounts to renewals"

### Problem

We will be on-boarding two new engineers to the Business Integration team. A significant part of on-boarding is understanding the complexity of the data model and code abstractions. 

### Proposal

Use the issue of [applying previous discounts to renewals](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/790) as an vehicle to examine the code and data model of the customer portal

### Result
Start documenting the data model for the Customer's Portal.

### How will we measure success?

Story points: 3.0
Remove references of Eula and EulaRequest models

### Problem

As mentioned in [the epic](https://gitlab.com/groups/gitlab-org/-/epics/4225), we no longer require the manual EULA process. After a period of time (TBD), we will no longer need to preserve the data for existing EULAs or EULA Requests.

### Proposal

Remove references to the `Eula` and `EulaRequest` models.

Here is a list of code that could be removed:
- https://gitlab.com/gitlab-org/customers-gitlab-com/blob/7e111a908a465b5e6b8101647b203cef2e79dbff/app/models/eula_request.rb
- https://gitlab.com/gitlab-org/customers-gitlab-com/blob/ee5aedd2d4a3ca662c95371aba3ef07d2808b8f8/app/models/eula.rb
- https://gitlab.com/gitlab-org/customers-gitlab-com/blob/0b900c33fe4dec8ce9b2d78ce050cd18dd83fdfc/app/models/customer.rb#L35
- Factories for Eula and EulaRequest.
- Use different table name [here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/39de54a16787d2d3e3a79f0ce187e09b3a272253/spec/lib/database/migrations_helper_spec.rb#L169)
- References to files to be removed as part of this issue from .rubocop_todo.yml (e.g. https://gitlab.com/gitlab-org/customers-gitlab-com/blob/154152723d1f0a9af846573222eda73082368ffb/.rubocop_todo.yml#L13)

**Important Note: This issue is blocked until the new terms have been live for at least 90 days (e.g. 90 days after [the `stop_eula_requests` feature flag was enabled](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1882)).  [That occurred on 2020-10-13](https://gitlab.slack.com/archives/CMJ8JR0RH/p1602599797469400).  We may decide to keep this data around for a while longer.  The exact date is TBD.  See [this issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1602) for more information.**

Story points: 2.0
Remove code allowing customers to accept EULAs

### Problem

As mentioned in [the epic](https://gitlab.com/groups/gitlab-org/-/epics/4225), we no longer require the manual EULA process. As a result, customers no longer need to accept EULAs.

### Proposal

We should remove all the code that allows customers to accept EULAs.  However, we still want to keep the data for existing EULAs for period of time (exact time TBD) so we don't want to remove models and DB tables.

Here is some related code to be sure to remove:
- https://gitlab.com/gitlab-org/customers-gitlab-com/blob/02d90dd9d3d776b0d9f5e25c9127f4b219342d85/app/models/subscription.rb#L133
- https://gitlab.com/gitlab-org/customers-gitlab-com/blob/0769075bb7cb91ba6871d074de30b07ce8001298/app/presenters/subscription_presenter.rb#L72
- https://gitlab.com/gitlab-org/customers-gitlab-com/blob/b82fc68107f4a6a6f8b23191fa19aea9749dbafc/app/helpers/eula_requests_helper.rb#L3
- https://gitlab.com/gitlab-org/customers-gitlab-com/blob/a0caa37649a5701a805b6c82caa458852d542438/app/controllers/eula_requests_controller.rb
- https://gitlab.com/gitlab-org/customers-gitlab-com/blob/7c57f22ba9073f86ed1b428681d5430715ef6633/app/assets/stylesheets/pages.scss#L3
- https://gitlab.com/gitlab-org/customers-gitlab-com/blob/e2cab1a1d9e4f09bd4c2b14093a83a3bf44f4f02/app/views/eula_requests/show.html.haml
- https://gitlab.com/gitlab-org/customers-gitlab-com/blob/d789b8c7493cade57c6dd69ec2edb31651625131/config/routes.rb#L35
- References (e.g. `eulaRequestPath`) in https://gitlab.com/gitlab-org/customers-gitlab-com/blob/9ac7fb080d7096d77d7737fff8f44e36c41e6f52/app/frontend/javascripts/subscription/components/subscription_buttons.vue
- References (e.g. `eulaReuqestPath`) in https://gitlab.com/gitlab-org/customers-gitlab-com/blob/d7d5757677ee8060adb05f52b99230954fb52952/app/frontend/javascripts/subscription/components/subscription.vue#L70

**Important Note: This issue is blocked until the new terms have been live for at least 90 days (e.g. 90 days after [the `stop_eula_requests` feature flag was enabled](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1882)).  [That occurred on 2020-10-13](https://gitlab.slack.com/archives/CMJ8JR0RH/p1602599797469400).  The exact date is TBD.**

Story points: 3.0