giseldo/neodataset huggingface dataset:
[UX] Community subscriptions should be able to self-checkout renewals

This is the UX design issue for https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2746

### Designs

- See design section
- [Figma link](https://www.figma.com/file/bEv8vTbhUUEfnDL8dXbevE/Community-Programs-Self-Checkout?node-id=206%3A1579)
     - Use Figma to get the design specs you need! (Sizing, spacing, color, copy, etc) You don't need any special access, just sign up for a free account and click the link above.

Story points: 3.0
[FE] Breakdown: Community subscriptions should be able to self-checkout renewals

## Summary 

In https://gitlab.com/groups/gitlab-org/-/epics/5068 we are building self-service checkout of new community program subscription. We now need to build a renewal flow for these subscribers.

The general process flow described in the parent epic is the same for new and renewal subscriptions however when the user enters CustomersDot, they will need to select a `Renew` cta.

## Development plan
* Build landing page for CE renewal https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3601
  * add a new route `/subscriptions/community_program/renew`
  * re-use templates that we build for CE subscription `community_subscription_landing_page.vue`
* Update the CE subscription cards on `/subscriptions` page
  * Add info banner for renewal alert that would show up 3 month before before expiration https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3574
  * enable renew buttons with correct path https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3575
* Build a renewal page for CE
  * add a new route `/subscriptions/community_program/renew/A-SXXXXXX` with basic titles https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3576
  * add purchase description https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3577
    * mind that we need two different versions of it: for SaaS and for SelfManaged
    * for SelfManaged version add a collapsible element with a hint from [subscription_renew.vue](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/a8d38ed9bd91be182e6288ff341a0c736713788f/app/frontend/javascripts/subscription/components/subscription_renew.vue#L337). We already have this element glued in the `subscripton_renew` component so it is a good time to extract it and use in two places
  * add customer information [component](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/76db4040e6294daa2da5ae813f667c54d34781a5/app/frontend/javascripts/subscription/components/customer_information.vue) https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3578
  * add coupon input [component](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/fa85e92d41afbdd97d324d6a4a37f0cba16529e5/app/frontend/javascripts/subscription/components/coupon_code_input.vue) https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3602
  * add purchase confirmation [component](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/f86054a4cb83d5536a2f5093830b4b47d7a55ff0/app/frontend/javascripts/purchase/components/purchase_confirmation_card.vue) https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3603
  * show success message if transaction is successful [modal](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/75adc85589a351f9aa523a4ca2f1bd46e7c3d09a/app/frontend/javascripts/purchase/components/purchase_success_modal.vue) https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3604
    * We would also need two version here for SaaS and for Selfmanaged

#### Design
See [design issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2747/)

Story points: 3.0
Refactor RSpec::Parameterized::TableSyntax inclusions

<!-- 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 currently require `rspec-parameterized` [here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/6e5df55d8add9945f2c9348263511d1c30098362/spec/spec_helper.rb#L6), which means we don't need to require it inline in specs when not using the table syntax, e.g.

```ruby
using RSpec::Parameterized::TableSyntax
```

So we should consider refactoring existing uses of the above (or removing the global require)

Affected spec files at time of writing:

- spec/services/gitlab/hosted_plans/purchased_add_ons/storage_service_spec.rb

This is a follow-up from the discussion here: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2791#note_514334639

Story points: 1.0
Remove deprecated tasks from package.json

Remove the following deprecated tasks from `package.json`:

```
"eslint": "echo 'Please use yarn lint:eslint instead' && exit 1",
"eslint-fix": "echo 'Please use yarn lint:eslint:fix instead' && exit 1",
"eslint-staged": "echo 'Please use yarn lint:eslint:staged instead' && exit 1",
"eslint-staged-fix": "echo 'Please use yarn lint:eslint:staged:fix instead' && exit 1",
"eslint-report": "echo 'Please use yarn lint:eslint:report instead' && exit 1",
"markdownlint": "echo 'Please use yarn lint:markdown instead' && exit 1",
"markdownlint-staged": "echo 'Please use yarn lint:markdown:staged instead' && exit 1",
"markdownlint-staged-fix": "echo 'Please use yarn lint:markdown:staged:fix instead' && exit 1",
"stylelint": "echo 'Please use yarn lint:stylelint instead' && exit 1",
```

Story points: 1.0
Confirm migration happens as expected

<!-- 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 saw https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2714 miss a migration on staging leading to [this internal thread](https://gitlab.slack.com/archives/CMJ8JR0RH/p1613493001291300)

We managed to resolve the migration, however the cause of the failure is unknown, and https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2714 is scheduled to deploy to production in ~1.5 hours.

Since the missed migration didn't cause any breaking issues, we do not see a reason to block the deploy. However we want to keep an eye on this.

Story points: 1.0
EoA: User cap message not displaying for the Add Seats flow

## Summary

In the EoA Bronze/Starter project we implemented a screening to prevent customers from taking advantage of the discounted offers for more than 25 users via CustomersDot and instead, send them to sales.

Although [the backend is preventing this](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2668#note_506408261) for the Add Seats purchase flow, the frontend is not displaying the proper "You have exceed the 25 seat .... Contact sales..." message which we display in the upgrade and renewal flows. Instead, we are showing an unhelpful "unknown error" message.

Story points: 2.0
Security Essentials Training SKU

# SKU Request Summary

<!---
Provide a brief description of what this SKU will be used for.
--->



## SKU Requirements

In order to expedite your request, please complete all of the following information.
Any questions about this template or this request can be directed to @amandarueda in the comments of this issue.

* [x] SKU Name: GitLab Security Essentials Training - Remote
* [x] SKU Code/ID: See Production/API Sandbox export
* [x] Zuora Plan Name: [See Production/API Sandbox export](https://docs.google.com/spreadsheets/d/1_fCY2Vswd6i1sgJpXe5OQIrv7GSKIejCPVic1ZyhWeA/edit?usp=sharing)
* [x] Zuora Plan ID: [See Production/API Sandbox export](https://docs.google.com/spreadsheets/d/1_fCY2Vswd6i1sgJpXe5OQIrv7GSKIejCPVic1ZyhWeA/edit?usp=sharing)
* [x] Service type: `add-on`
* [x] Does this need to be purchase-able via CustomersDot? `No`
* [x] Does this service renew? `No`
     * [ ] If yes, what is the renewal cadence? `monthly | annually | other`
* [x] Should an email be sent indicating the subscription is coming to an end?: `No`
* [x] Is there a unit of measure, if so what? `Yes  Education Service`
* [x] Does this service provision anything? `No`
     * [ ] If yes, please describe in detail what should be provisioned including the systems affected:
* [x] How soon do you need this SKU ? Timeline:ASAP
* [x] Who in Sales-Ops approved this request: @dhong  
* [x] Link to originating Finance issue: https://gitlab.com/gitlab-com/Finance-Division/finance/-/issues/3589
* [ ] Apply the appropriate `BTG Priority` label to this issue.

Story points: 2.0
[CI Minutes] Migrate purchase subscription steps to GraphQL

Migrate the existing [subscription checkout](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/subscriptions/new/components/checkout/) to use the GraphQL based `step.vue`, `step_header.vue`, `step_summary.vue`, and `progress_bar` components and the GraphQL based `Subscriptions::CreateService.new(...)`

Story points: 2.0
[CI Minutes] Migrate purchase subscription details to GraphQL

Migrate the existing [`subscription_details.vue`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/subscriptions/new/components/checkout/subscription_details.vue) and [`summary_details.vue`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/subscriptions/new/components/order_summary/summary_details.vue) to use GraphQL.

Story points: 2.0
Custom PS Education Services SKU

# SKU Request Summary

<!---
Provide a brief description of what this SKU will be used for.
--->



## SKU Requirements

In order to expedite your request, please complete all of the following information.
Any questions about this template or this request can be directed to @amandarueda in the comments of this issue.

* [x] SKU Name:  Custom PS Education Services
* [x] SKU Code/ID:  See Production/API Sandbox export
* [x] Zuora Plan Name:  [See Production/API Sandbox export](https://docs.google.com/spreadsheets/d/1hFp2LnIN1a1nCJ9sjuSeqa0IGqn19pXIuVS83M6KciY/edit?usp=sharing)
* [x] Zuora Plan ID:  [See Production/API Sandbox export](https://docs.google.com/spreadsheets/d/1hFp2LnIN1a1nCJ9sjuSeqa0IGqn19pXIuVS83M6KciY/edit?usp=sharing)
* [x] Service type: `add-on`
* [x] Does this need to be purchase-able via CustomersDot? `No`
* [x] Does this service renew? `No`
     * [ ] If yes, what is the renewal cadence? `monthly | annually | other`
* [x] Should an email be sent indicating the subscription is coming to an end?: `No`
* [x] Is there a unit of measure, if so what? `Yes`  `Education Service`
* [x] Does this service provision anything? `other`
     * [ ] If yes, please describe in detail what should be provisioned including the systems affected:
* [x] How soon do you need this SKU ? Timeline:  ASAP
* [x] Who in Sales-Ops approved this request: @c.yoshida 
* [x] Link to originating Finance issue:  https://gitlab.com/gitlab-com/Finance-Division/finance/-/issues/3428
* [ ] Apply the appropriate `BTG Priority` label to this issue.

[Customer PS Education Services](https://docs.google.com/spreadsheets/d/1hFp2LnIN1a1nCJ9sjuSeqa0IGqn19pXIuVS83M6KciY/edit?usp=sharing)

Story points: 2.0
Invalid user input during purchase should not raise Sentry errors

### Problem

We've seen some Sentry errors (shown below) which were triggered from invalid user input like entering an invalid quantity during a EoA upgrade at renewal.  These types of errors are displayed on the page in order for the user to fix the problem on their own.  They don't represent an error in the code that needs to be addressed so we should not raise these types of errors in Sentry, which adds extra noise.

1. [You have exceeded the 25 seat allowance for this offer](https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/2486996/?referrer=slack)
2. [Enter a number of active users greater than or equal to your current number of active users (12)](https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/2487120/?referrer=slack)

[Slack thread](https://gitlab.slack.com/archives/CL7SX4N86/p1613068673149300?thread_ts=1613065859.148000&cid=CL7SX4N86) (internal) for context.

### Proposal

These errors are handled in [the `AmendSubscriptionService#execute` method](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/e390ecbe3fde96d1747056b9bd3f05c88958aac9/app/services/amend_subscription_service.rb#L35).  Some errors (`PaymentMethodUpdateError`, `NotUpgradableError`, `NotDowngradableError`, `MaxAdditionalSeatsExceededError`) are rescued without logging an error to Sentry.  

The first error above (`MaxAdditionalSeatsExceededError`; [raised here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/eaedf03b86463244a458f9bf1d63c3fe9424d0ea/app/services/amendment_base_service.rb#L262)) should be handled this way without logging in Sentry but it must be somehow.  This might be coming from the frontend as errors are raised [from here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/e3560a9d6787bf155672380f7b3a9da5ff00928b/app/frontend/javascripts/subscription/components/upgrade_subscription_app.vue#L238) as well.

The second error ([raised here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/e390ecbe3fde96d1747056b9bd3f05c88958aac9/app/services/amend_subscription_service.rb#L245) is logged to Sentry because it's raised as a `RenewalError` which [rescued here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/e390ecbe3fde96d1747056b9bd3f05c88958aac9/app/services/amend_subscription_service.rb#L36) and logged to Sentry.

### Result

Less noise in the #s_fulfillment_status Slack channel.

Story points: 2.0
Follow-up from "Drop :drop_custom_encoding feature flag"

The following discussion from !2765 should be addressed:

- [ ] @cwiesner started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2765#note_506200531): 

    > **nitpick:** This method serves as an alias only now. We should remove it and use `name` directly for its usages. I'm okay with addressing this in a follow-up as well.

Story points: 1.0
Remove custom eager loading in PlansFinder is possible

### Problem

In the `PlansFinder` currently, plans are eager loaded during [app initialization](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/13b85a3f5e28800634da970972c3bc5313b2d37c/config/application.rb#L72).  This is done as an optimization to reduce the number of requests to Zuora to fetch common products from the catalog.  However, now that we are using [IronBank's local products cache feature](https://github.com/zendesk/iron_bank#local-records) (with a slight [customization to store in the db](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/45f5dedbb4fa803d19827472214ea0b5b0ce1861/lib/gem_extensions/iron_bank/local_records.rb#L6) instead of filesystem), we might not need this eager-loading mechanism anymore.

Removing eager loading would have some nice benefits:
- Removes complexity in the app loading logic.
- Removes a few [class variables](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/aa13252af0a6e69a58c8ac2bc645afaf36d7b12c/app/models/plans_finder.rb#L12) from our codebase which in general should be avoided.
- Removes the [eager-loading step](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/fe13e488edc07ced567e0b64d6b560b83b2ccf0d/spec/support/eager_load_plan_finder.rb#L10) from Rspec configuration.  This would be a huge benefit because `plans_finder` has its own VCR cassette for this eager loading that frequently causes merge conflicts since it is a very commonly updated file.  Fixing this should improve our velocity and generally the engineers quality of life.

### Proposal

Remove the `PlansFinder` eager-loading logic and make sure nothing breaks.  The `PlansFinder.find` method could be updated to find a Product Rate Plan directly using IronBank (e.g. `Zuora::ProductRatePlan.find`) rather than looping over `eager_loaded_plans`.  The key difference here is we would build the `Plan` object on the fly instead of returning a `Plan` object that was [built during start up](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/aa13252af0a6e69a58c8ac2bc645afaf36d7b12c/app/models/plans_finder.rb#L31).

We should take benchmarks of important features before and after this change to make sure there is no negative impact.  Here are some ideas of things to benchmark:
- Loading the Rails app.
- Loading the Plans page.
- Loading the Manage subscriptions page.
- Making a subscription purchase.

### Result

A simpler codebase that hopefully isn't any less performant but easier to maintain.

Story points: 5.0
FE: Prevent deletion of groups/namespaces when they have a subscription

This is the ~frontend issue for: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1879

Designs https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1923/designs/Group___Settings___General.png

* Propagate if group has a subscription attached to the view
* Display inline alert from design if subscription is attached
* Make `Remove group` button disabled

Story points: 3.0
subscription should only allow to transfer to namespaces not currently associated with a paid plan

`change linked namespace` allows selecting some namespace that already purchased services. This is a bug.

### Problem

slack discussion https://gitlab.slack.com/archives/CMJ8JR0RH/p1612432937066900

TLDR: When a namespace has a free trial and then purchased a paid plan, it will have this issue.

The problem is: in `app/helpers/gitlab_plans_helper.rb`, it uses `namespace.trial_ends_on.nil?` to determine whether a subscription is `in trial`. This is not safe.

**Snapshot (some namespace with paid subscriptions like g300, is allowing to link to another subscription, which is wrong)** ![Screenshot_from_2021-02-08_09-46-05](https://gitlab.com/gitlab-org/customers-gitlab-com/uploads/1f399fa44f70f1edd5fda900fed8efe6/Screenshot_from_2021-02-08_09-46-05.png)

### Proposal

TLDR: uses `!namespace.trial` to replace `namespace.trial_ends_on.nil?` in `app/helpers/gitlab_plans_helper.rb`

**More details explained below**

The information we saved for trial subscription:

* trial_starts_on
* trial
* trial_ends_on.

It is not safe to use `trial_ends_on` to determine whether a subscription is `in trial`. Because when a trial finished, `trial_ends_on` value is not cleared.

Scenarios related to `trial subscription`:

1. in active trial: `trial = true`, `trial_starts_on <= today`, `trial_ends_on >= today`
1. trial expired: `trial = true`, `trial_starts_on <= today`, `trial_ends_on < today`
1. trial terminated due to a paid subscription purchased: `trial = false`, `trial_starts_on <= today`, `trial_ends_on has value ( it >= date when trial was terminated; but while time flies, it will < today eventually)`
1. trial expired, and then a paid subscription purchased: `trial = false`, `trial_starts_on <= today`, `trial_ends_on < today`

From the above-listed scenarios:

* if a namespace's latest subscription is `trial`, it has `trial = true`, no matter the trial expired or not
* if a namespace's latest subscription is a paid subscription, it has `trial = false`

**NOTE**: today, even when a namespace's trial expired, we still show it as `Trial` in GUI, though the Gold features are disabled since we checked `trial_ends_on` in the logic.

From another perspective, in our code logic, as of today, there are 3 types namespaces:

* free : not link to a subscription, no matter trial subscription or paid subscription
* trial : link to trial subscription(it can be active or expired), but not link to a paid subscription
* paid subscription : link to a paid subscription

So if a namespace is linked to a subscription, we can use `trial` to determine it is trial subscripton or paid subscription.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Testing/Feedback from mapping of Zuora invoice to Salesforce CPQ Items

<!-- 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 purpose of this issue is to gather the feedback resulting from testing the changes implemented for https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2097.

Sync session scheduled for Feb 4.

Story points: 1.0
Remove ExpireTrialCronJob worker class

The following discussion from !2303 should be addressed:

- [ ] @krasio started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2303#note_467690103):  (+4 comments)

    > Probably over defensive but just in case there are such jobs in the queue during deployment.

Story points: 1.0
Updates to "Cancelled" label

## Summary

In https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2637 we implemented a label to draw attention to the customer that the subscription is set to cancel. 

This issue is an iteration of that implementation to:

1. Change the `Cancelled` label to include a humanized date as suggested in [this comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2637#note_500615444)
1. Change the `Cancelled` label for expired subscriptions (where subscription end date is in the past) to read `Expired`

Story points: 1.0