giseldo/neodataset huggingface dataset:
Spike: Identify what would occur if we didn't clear start/end dates

## Summary

In [this research issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1907), Corinna identified [where we reset subscription start/end dates in GitLab.com](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1907#note_408555499). The retention team would like us to stop clearing out the subscription dates.

This issue has been created to identify if making such a change will have any negative downstream process affects.

Story points: 1.0
Investigate Quarterly Co-terms from License Sync data

### Problem

With the Cloud License Sync epic, we will be gathering license information from self-managed instances, similar to how we gather Seat Link data.  Both will be gathered on a routine basis (daily) and contain information on max historical user count and license key.  Given that there is this duplication, we should be able to retire Seat Link eventually in favor of License Sync.

We don't have all the specifics worked out yet but we feel confident that we can get quarterly co-terms working with license sync. Basically the idea would be to use the data from the license sync requests to feed the Reconciliation model, instead of using the seat link requests. It's a pretty simple concept from that standpoint, but there are still some details to be worked out such as:

* Ensure the license sync data contains the data points that are required by Reconciliation (e.g. report date, license start date, license end date, max historical user count)
* For seat link requests, the request received on day X contains data from day X-1. For license sync requests, I'm not sure it necessarily has to be that way, but there are good ways to keep with that same method. A day offset gives the rake task the opportunity to capture the user count information from HistoricalData after it has a chance to retry if necessary.
* Figure out the handoff for which data input feeds the reconciliations (seat link vs license sync). Maybe both would be fine as it should be the same data, but that needs some thought.
* Seat Link has been on for a while (introduced in an earlier version of GL) and by default SM instances opted in.  For License Sync, this has to be activated so we might not be gather as much data through this method, at least to begin with.  Determine if the business is okay with this. The handoff discussed int the above bullet point might inform this decision too.

### Proposal

This issue is dedicated to sorting out some of these details and adding it to the proposal document to be added in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2100.

Story points: 3.0
New SKUs for RevPro Implementation

# SKU Request Summary

As part of Revpro implementation, we are creating a range of new SKUs, the details are available in this [finance issue](https://gitlab.com/gitlab-com/Finance-Division/finance/-/issues/3367)


## SKU Requirements

Details of the new SKUs are available [here](https://docs.google.com/spreadsheets/d/1WK2K6pE7QPGmZJrOOZ8dgJ2bOhY4130XpaBhBNR381I/edit#gid=0)

Story points: 3.0
Identify idempotency issues on gitlab.com provisioning job retries

In https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1440 we found a few cases where we retry jobs when an error occurs in the gitlab.com provisioning process. 

* https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/services/gitlab/namespace/update_plan_info_service.rb#L30
* https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/services/gitlab/namespace/update_plan_info_service.rb#L46
* https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/services/gitlab/namespace/update_plan_info_service.rb#L92
* ...

Nothing jumped out at me that I think would cause an issue on retries but I'm also not sure that the retries actually help anything. It's possible we are just polluting the retry queue with jobs that failed and will never succeed. We should verify:

1. We are not causing idempotency issues when we retry.
2. Retries have the potential to succeed instead of just continuing to error.

### Problem

### Proposal

### Result

### Next steps (if any)

### How will we measure success?

Story points: 3.0
Retry gitlab.com api calls when provisioning

In https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1440 we discovered that we don't retry calls when an gitlab api call fails during provisioning. Instead, we swallow the error, return `{ success: false }` and don't do anything with the result. 

* https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/services/gitlab/namespace/update_service.rb#L17
* https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/services/gitlab/subscription/update_service.rb#L26
* ...

Rather than restart the whole job on cases when the api fails, I think it would probably be best to keep the retries synchronous so we don't cause any idempotency issues.

For example

```ruby
def update_namespace
  tries = 0 
  max_tries = 3
  begin
    response = Client::GitlabApp.put(...)
    raise unless response.success?
  retry
    unless tries > max_tries
      log_error
      sleep(5) # some time for the api to recover
      retry
    end
  end
end
```

### Problem

### Proposal

### Result

### Next steps (if any)

### How will we measure success?

Story points: 3.0
Add test coverage for renewals at list price

# Background

In https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2057, we added the ability to use the list price instead of the original discounted price when performing renewals.  However, as mentioned in the discussion below, it was difficult to add test coverage for this case because it required creating some test objects in Zuora (products, rate plan charges, etc) rather than mocking. This is because the [`amend_subscription_service_spec.rb`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/755f660e602579136967dd818dc9049e782c2eaa/spec/services/amend_subscription_service_spec.rb) and [`renew_subscriptions_pajamas_spec.rb`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/a8eea433e2c8d5a2ae9cc8f4c94711ee22d62f7c/spec/features/renew_subscriptions_pajamas_spec.rb) use VCR.

# Proposal

Ensure proper test coverage for renewals in scenarios that should use list price and discounted price.

## Follow-up from Discussion

The following discussion from !2057 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2057#note_429012271):  (+2 comments)

    > **Question:** Should we add some additional tests to cover these new cases?  I see the change [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2057/diffs#bc237849f35c4d92a46f1ea439edb1da0b5d2b13_199_199) but it's not clear to me that it's testing the renewal case. I was thinking it might be good to have a scenario where the `main_product.renewal_price` actually uses the latest product catalog price (e.g. where [this line](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/49bb3d9b1311700c7d8ffdcdc5085e28c5424af3/app/models/product.rb#L38) is true).  We might want to add a similar test case in `spec/features/renew_subscriptions_pajamas_spec.rb` as well.
    > 
    > WDYT?

Story points: 2.0
Community Programs Self-Checkout - Extract customer's information component

### Problem

We have got a hard-coded piece of code to render customer's information, that is being used in 2 pages, [usage example](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/e5f349b7cbcdc2ceeaa35d699fc851df42c19eaf/app/frontend/javascripts/subscription/components/new_ee_subscription_form.vue#L194-209).

Original discussion https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2003#note_428777133.

### Proposal

We have an opportunity to extract a component that is being used in `new_ee_subscription_form.vue` and `new_gitlab_subscription_form.vue` where we show a customer's information.

The new component would accept a `customer` parameter and output a rendered information.

### Result

Cleaner and consistent code

### Next steps (if any)

Schedule

Story points: 2.0
Invalid quantity error not showing during CI purchase when user has an active subscription or add-on purchase

<!-- 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

If a user has an active subscription, or has CI minutes packs as add-ons, when the user purchases more CI minutes, error message will not show with an invalid quantity. Purchase will go through with '0' on manage purchase page :point_down: 

**No error message shows**

![image](/uploads/675f9cc40b2ace1472ddb07c295571d7/image.png)

**Purchase go through**
![ci](/uploads/9a3254401ce7eae932f73a0b00018a67/ci.gif)

**Purchase quantity shows 0**
![image](/uploads/49ca50e041616fb97d4c68e5592b3357/image.png)

### Proposal

**Expected behavior**
![image](/uploads/4b0d420f38d512337c4fe21ccbb75d1e/image.png)

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Remove ability to resend EULA from admin panel

### Problem

As mentioned in [the epic](https://gitlab.com/groups/gitlab-org/-/epics/4225), we no longer require the manual EULA process. As part of this work, we should not need to resend EULA request email from the Admin panel.

This was first attempted as part of https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1836, but we realized that we needed to keep this functionality around a bit longer as we sunset customers on the legacy EULA process.  We should tackle this in a future milestone similar to when we start work on https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1841.  In that issue, we determined we should start the work 90 days after the existing Eula process was turned off (2020-10-13).  Exact date TBD.

### Proposal

Remove the components related to resending EULAs via the admin panel.

Here's a patch that outlines what should be changed: [resend_eula.patch](/uploads/3dfc04a50e3d23eefbfebc9d7a7db069/resend_eula.patch)

Story points: 1.0
Document and describe columns in the DB (and perhaps add a Danger check)

We should start describing the fields we have in the CustomersDot DB and probably follow the guidelines of https://gitlab.com/gitlab-org/database-team/team-tasks/-/issues/88

It might be best to add another reminder similar to the DB ERD one to Danger so we can ping the engineer every time the DB is updated.

Related to https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1128#note_424516562 and https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1128#note_424541144

Story points: 3.0
Do not show sign in / sign up error on the sign in 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

When a user is not signed into the Customers Portal, they get redirected to the sign in / register page and are shown a scary-looking red alert at the top telling them to sign in or sign up for the customers portal to continue. This is jarring to the user and makes them feel like they've made an error, even though they are just on the signin/signup step of the flow.

![browser_screen__57_](/uploads/2029d2734005af8217513b70bc91c7a9/browser_screen__57_.png)

### Proposal

Remove the error message about needing to sign in / sign up. The sign in / registration page is already pretty straightforward and the user doesn't need additional instructions.

Story points: 2.0
Further refactor customers creation

The following discussion from !2021 should be addressed:

- [ ] @shreyasagarwal started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2021#note_423635493):  (+1 comment)

    > @dstull Can we please use `self.where` ... I probably never had a habit of reading it without a Customer.where or self.where and makes me cringe a bit. Just a personal preference, if you leave it then I would try hard to get use to it :smile:

Story points: 2.0
Improve self-managed purchase success modal

<!-- 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

When a customer has just purchased a self-managed subscription, the success modal gives them no actionable steps about what to do next to get their license or upload it to their instance.

![Screenshot_2020-10-05_at_10.14.27](/uploads/5de5bff344e1f99bc5e069f06b23b785/Screenshot_2020-10-05_at_10.14.27.png)

### Proposal

- Add copy on the purchase success modal to tell the user to check their email for the license file and instructions on how to apply it or download it from the manage purchases page. 
- Change the button to "Get license file" and have it link to the manage purchases page.

Story points: 3.0
Improve copy on email confirmation step

## Problem

Webstore registration requires email confirmation, but the screen asking the user to confirm their email emphasizes resending the confirmation email, not the the main action of checking your email to click the confirmation link. 

It also doesn't tell user why confirmation is required (because we send the license to that email and we need to make sure it's right).

![browser_screen__9__1](/uploads/dd7ed617f0e91e9fc6fcb6850805d519/browser_screen__9__1.png)

## Proposal

- Move the info that's currently hidden in the alert down into the main body. 
- Add a value prop for the user to tell them why confirming their email is important (something like "We need you to confirm your email so that we send your license to the right place.") 
- Give less emphasis to "Resend confirmation instructions" and more emphasis to the action that they really need to take which is "Check your email."

### Availability & Testing

<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.

What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?

Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change

See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning -->

> Add a value prop for the user to tell them why confirming their email is important

Any associated Vue changes should also be accompanied by frontend Jest test changes to test the new prop, or any other modifications.

Story points: 3.0
Stub Salesforce calls in testing

The following discussion from !1998 should be addressed:

- [ ] @dstull started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1998#note_420627415):  (+3 comments)

    > what is perplexing here is not why this is needed now - but why it wasn't needed before, as every test under this context needs it.

Story points: 1.0
Move cron job into jobs area

The following discussion from !2012 should be addressed:

- [ ] @dstull started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2012#note_419823396):  (+1 comment)

    > The name(no worker suffixed) and placement of this class and the one that is called in the perform is suspicious.
    > 
    > I see it is really a [cronjob](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/9cb507bd42ed3f31b760ed8c35d7b80087cef67a/config/sidekiq.yml#L11), so perhaps it should move under `app/jobs` and be refactored a bit?
    > 
    > note: will spawn issue if feedback confirms this

Story points: 2.0
Upstream spec schema migration before settings

The following discussion from !2000 should be addressed:

- [ ] @shreyasagarwal started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2000#note_418608156):  (+2 comments)

    > @dstull Can we replace `:each` with `:example`. RSpec wants to deprecate the use of 'each' and 'all' in later versions and the new ones which came from 3.0 are these ones listed here https://relishapp.com/rspec/rspec-core/v/3-9/docs/hooks/before-and-after-hooks

Story points: 1.0
Danger suggests backend review for frontend changes

### Problem

With aligning Danger to the GitLab updates (https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1974), some changes trigger the wrong review as the fallback review category is triggered. For [example](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2010#note_419750732) changes in `app/frontend` fell back to a backend review since it wasn't explicitly checked for frontend anymore.

### Proposal
Add some categories back to trigger a frontend review.

### Result
Danger suggests the correct review category.

Story points: 1.0
Align overcommit.yml with GitLab

### Problem
While reviewing https://gitlab.com/gitlab-org/license-gitlab-com/-/merge_requests/212, I looked at the `.overcommit.yml.example` for [GitLab](https://gitlab.com/gitlab-org/gitlab/blob/master/.overcommit.yml.example) and the [Subscriptions App](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/.overcommit.yml.example). The Subscriptions App's file is much smaller, so we should check if we should add a few checks that are in place for GitLab here as well. For example, in the last few months we added a lot more docs, so it might make sense to add checks like `MarkdownLint` and `Vale` to hold the Subscriptions App to the same standard as GitLab.

### Proposal
Compare `.overcommit.yml.example` of GitLab and Subscriptions App and update the latter one with useful checks.

### Result
Aligning overcommit checks with GitLab and have the same standard in those checks.

Story points: 1.0
[UX] Improve provisioning and onboarding of new sales-assisted GitLab.com subscribers - MVC

This is the UX design issue for https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2272

Video walkthrough of current flow: https://youtu.be/Wex_YD37Dkk


### Designs
SSOT
- See design section
- [Figma link](https://www.figma.com/file/MIQZb8jhi5gA33yFbaREou/Improve-provisioning-and-onboarding-of-new-sales-assisted-SaaS-subscribers?node-id=23%3A2943)

- [Walkthrough video](https://www.loom.com/share/dc875e6e39e64c20b48cb07fd9a9d8a1) - Some edits were made to designs after this video was made.

Story points: 3.0
Follow-up: Allow creating new group in new GitLab purchase page

### Problem


We need to allow the user to create a new group while they're in "New GitLab Subscription" and assign the new subscription to that group.

A follow-up to #1970.

### Proposal

Use the following design for the new GitLab.com subscription page

![](https://gitlab.com/gitlab-org/customers-gitlab-com/uploads/9e3428a617b31972d66f521917c42fce/GitLab.com_-_Buy_subscription.png)

Story points: 3.0
SaaS upgrade flow should charge for users over license

## Summary

When a SaaS customer with user overages upgrades their tier, we don't charge seats over their current subscribed amount. This causes issues at renewal for sales.


## Proposal

When the customer enters the Upgrade purchase flow, we should dynamically update the `seats` field with the greater of the `Seats currently in use` or `Seats in subscription`. Today the value defaults to the prior `subscription` Seats in subscription` quantity.

### Availability & Testing

<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.

What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?

Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change

See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning -->

> dynamically update the `seats` field with the greater of the `Seats currently in use` or `Seats in subscription`

This will require tests to ensure that one value takes precedence over the other, as well as a front-end test that ensures that the value is rendered in the field as expected.

Story points: 2.0