giseldo/neodataset huggingface dataset:
Procurement | Add separate OSS and EDU SKUs

# SKU Request Summary

We currently have a single SKU for EDU/OSS. Now that our programs are expanding, we need to differentiate those in order to accurately track metrics for each of our programs. It will also help us automate some parts of the process as per this issue around automating renewal titles: https://gitlab.com/gitlab-com/sales-team/field-operations/sales-operations/-/issues/1596

This is a request to create two separate SKUs: 
 * EDU
 * OSS

[Note on a requirement from the data team. ](https://gitlab.com/gitlab-com/sales-team/field-operations/sales-operations/-/issues/1400#note_429775874)

cc/ @c_hupy 

## 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.

1. [ ] SKU Names:
     * `EDU` 
     * `OSS`
1. [ ] SKU Code/ID:
1. [ ] **Zuora Plan Name: `enter plan name`**
1. [ ] **Zuora Plan ID: `enter plan ID`**
1. [ ] **Service type: `subscription`** -- need to double check
1. [ ] Does this need to be purchase-able via the customers portal? `No` -- users should not be able to renew on their own.
1. [ ] Does this service renew? `Yes` -- but via a manual process. Customers must email opensource@gitlab.com or education@gitlab.com
     * [ ] If yes, what is the renewal cadence? `annually`
1. [ ] Should an email be sent indicating the subscription is coming to an end?: `Yes`
1. [ ] **Is there a unit of measure, if so what?** ` Yes | No`  `Users | Qty | other`
1. [ ] Does this service provision anything? `Gold or Ultimate for 1 year`
     * [ ] If yes, please describe in detail what should be provisioned including the systems affected:
1. [ ] How soon do you need this SKU ? Timeline: ASAP, no hard deadline
1. [ ] Who in Sales-Ops approved this request: @username -- Discussion happening with @tav_scott and @jrabbits on: https://gitlab.com/gitlab-com/sales-team/field-operations/sales-operations/-/issues/1596 
1. [ ] Link to originating Finance issue: https://gitlab.com/gitlab-com/Finance-Division/finance/-/issues/3368
1. [ ] Apply the appropriate `BTG Priority` label to this issue.

Story points: 1.0
BE: Check for `Seats currently in use` when seats are added for GL.com

We are implementing [GitLab.com users should be able to purchase additional users without adding members](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1098), which allows users to add seats to their subscription as they go. The functionality is limited to updating the subscription and we do not check their current usage.

For this iteration, we should check the `Seats currently in use` count on gitlab.com. 

With this check, we are trying to encourage the customer to pay for their current usage, instead of just adding the seats they think they need. The customer is not obliged or guided to settle their usage during their subscription period, so this check is an opportunity to settle their true usage of seats. 

Because there is no automatic trueup charge on gitlab.com today (December 2020), we forfeit any seat usage money above their paid seats if the customer does not take any action to add and pay for seats. By checking for their current usage, there is a better chance that those seats will be accounted for.

**Happy path:**
1. Given the user has a subscription 
1. And the subscription is linked to the group namespace
1. When the user selects the `Add more seats` button on their subscription card
1. Then a check for the `Seats currently in use` count on gitlab.com will be triggered
1. The user should be prompted to purchase a minimum number of seats to cover their current use

#### Example

1. Current subscription seat quantity = `10`
1. Current seats in use = `15`
1. When user selects `Add more seats`, the default the minimum `Add additional seats` quantity should be `5`
1. The user should not be able to enter less than `5` additional seats and be able to checkout

----

Considerations for the check failing:
- the group and subscription are no longer linked because the group has been deleted
- the group and subscription are no longer linked because the gitlab.com user no longer has Owner access to the group

### 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 -->

This may require tests that mock the response from GitLab.com returning the "Seats currently in use" properly, as well as tests that check to ensure that the BE code handles both valid and invalid responses from GL.com.

Story points: 1.0
Prefill "Add additional seats" input field with unpaid seats number for GL.com

## Summary

As part of the flow for [adding additional seats for gitlab.com subscriptions](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1098), we should prefill the input field for adding additional seats with the difference between seats in use and seats in subscription, and prevent the user from inputting a number less than their seats owed.

| Scenario | Image |
| --- | --- |
|_I'm a customer with 20 seats in my subscription. I currently have 30 seats in use. When I click `Add more seats`, the number `10` will be prefilled into the additional seats field. The user will be able to increase this amount, but not put in a smaller quantity._ | ![Screenshot_2020-11-27_at_14.07.41](/uploads/d28210e54e4ea2b5e5cc49aba87b2395/Screenshot_2020-11-27_at_14.07.41.png)|

## Proposal

To make this clear to the user, we'll add this copy as description text to the field (not sure if the form field component we use in CDot puts the description text above or below the field itself, but either is fine):

`This number must be 10 (your owed seats) or more.`

----

Considerations for possible errors:
- the group and subscription are no longer linked because the group has been deleted
- the group and subscription are no longer linked because the gitlab.com user no longer has Owner access to the group

If the check fails, should we error out or should we allow them to update the subscription, without the connection to gitlab.com?

Story points: 2.0
Add GraphQL NPM Packages to Customers Portal

The following NPM packages need to be added to support graphQL

- [apollo-client](https://www.npmjs.com/package/apollo-client)
- [apollo-cache-inmemory](https://www.npmjs.com/package/apollo-cache-inmemory)
- [vue-apollo](https://www.npmjs.com/package/vue-apollo)
- [jest-transform-graphql](https://www.npmjs.com/package/jest-transform-graphql)

Story points: 1.0
Replace newSubscription with purchaseSubscription

The following discussion from !1941 should be addressed:

- [ ] @dbodicherla started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1941#note_410733506):  (+3 comments)

    > **question:** We seem to be doing a very similar thing within the `createOrUpdateSubscription` method. Do we plan to update that method eventually or are these two different code flows?

    > So after some digging, I found out that changing namespace and addon transactions use the `createOrUpdateSubscription` method which hits the same endpoint as `newSubscription` and I believe the payloads look same as well.

### Update

After a chat with @rhardarson, he told me that we should be used `purchaseSubscription` instead of `newSubscription`.

Using `newSubscription` does not wait for the new credit card to be stored and processed before continue the request to purchase the subscription.

Another interesting thing he mentioned:

> When purchasing a subscription for an account without any previous purchases (e.g. CI minutes) we'll be hitting the endpoint using `PUT` while we'll use `POST` for purchasing a subscription without any previous purchases.

Story points: 2.0
Be explicit in plan order when upgrading 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/

-->

### Problem

We're iterating over available plans to upgrade to. However we're not forcing any order.

This makes for a discrepancy between environments

| Order in production | Order in development and on staging |
| ------ | ------ |
| ![](https://gitlab.com/gitlab-org/customers-gitlab-com/uploads/5b75d901a6cb2581106dffac67aad176/Screenshot_2020-09-07_at_10.24.49.png) | ![](https://gitlab.com/gitlab-org/customers-gitlab-com/uploads/32437d3ed5479e134702beb8ab62243a/Screenshot_2020-09-09_at_07.38.37.png) |


### Proposal

We should be explicit on the order of the plans. Let's make a decision and enforce it with code.

Story points: 2.0
Sentry capture for certain user actions is malformed

### Summary
User actions like add seats and change namespace wires malformed message to Sentry (check the screenshot)

### Steps to reproduce
No real steps but check the `Extra steps` section in the Sentry issue https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1774487/?query=is%3Aunresolved%20user%3A129432

### What is the current *bug* behavior?

(What actually happens)

### What is the expected *correct* behavior?

(What you should see instead)

### Relevant logs and/or screenshots
![image](/uploads/c3061188c63cc88f22e96363836244d5/image.png)

### Workarounds

(Ways to get around the issue)

### Reported examples

1.
1.
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
Follow-up: change admin history table dates format

This is a follow-up to https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1009#note_410094661

### Problem

The admin views are too congested.


### Proposal

@timnoah [said in the main issue's MR](https://gitlab.com/gitlab-org/customers-gitlab-com/merge_requests/858#note_269208798):

> As this is quite a congested table to relieve some of the pressure on wrapping headers could we change the date formatting on **created at** and **updated at** to `MM DD, YYYY hh:mm` Example, **Dec 20, 2019 15:34**?

@aalakkad said: 

> I'm not sure how easy it is to do that in rails_admin, for a quick search I found [a way](https://stackoverflow.com/a/32631342) to configure the date format, but I can't be sure if it has any implications for other parts of the system.

An update to the List of Customers view was made in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1009, this follow-up issue is to make a similar change in the History view.

Story points: 2.0
Spike: Investigate using OriginalId for Zuora Subscriptions

### Problem

In Zuora, Subscriptions ID change throughout the life of the subscription as amendments are made.  We used to track subscriptions in the Customer Portal primarily using subscription IDs but changed to preferring the subscription name as the ID would change.  We've discovered an attribute called `OriginalId` which is advertised an immutable id for the life of the subscription.  This idea was raised as part of [this discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1926#note_410082430).

More information in the [Zuora Docs](https://knowledgecenter.zuora.com/Billing/Subscriptions/Subscriptions/A_Subscription_Introduction).

### Proposal

We should look into using this `OriginalId` to track subscriptions in the Portal instead of using subscription name or id.  If this is indeed a fixed ID, it would simplify logic in our system that does lookup by name or id.

If it looks like it will work as we expect, create an epic or issues to outline a transition plan to using the new `OriginalId` attribute

Story points: 2.0
Follow-up from Web Direct Opportunities Need Quote and Product Data

## Summary

As a follow-up from work related to #911 , we need to make the following adjustments:

1. [x] Add Country and State to Salesforce Contacts created during checkout. This is required for Zuora and should use the same logic we asked for when creating accounts.
     - Location: https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/services/create_salesforce_contact_service.rb#L21
     - Logic used at Account Level: https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/services/create_salesforce_account_service.rb#L61
1. [x] Set Quantity of seats in Quote Rate Plan Charge equal to the Quantity of the Order. We had set it to 1 for testing. Lets expand it to the full value.
     - Location: https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/services/salesforce/create_quote_rate_plan_charge_service.rb#L71
1. [x] Set additional fields on Quote with on hand subscription Data.
     - Location: https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/services/salesforce/create_quote_service.rb#L45
     - Please set `zqu__Hidden_Subscription_Name__c` to the Zuora Subscription Name Please set `zqu__ZuoraSubscriptionID__c` to the Zuora Subscription ID (Current ID, NOT Original ID)
1. [x] Append "Type" data down to more objects based on the Amendment Type of the Order or Opportunity Type of the Opportunity created (those are all ready tied together, use which ever is easiest). See the following Chart.

|  | zqu__SubscriptionType__c | zqu__Type__c | zqu__AmendmentType__c |
|--|--------------------------|--------------|-----------------------|
| Opportunity Type | Quote | Quote Amendment | Quote Rate Plan |
| -------------------------- | -------------------- | ----------------------- | ----------------- |
| New Business | New Subscription | NewProduct | NewProduct |
| Add-On Business | Amend Subscription | UpdateProduct | UpdateProduct |
| Renewal | Renew Subscription | Renewal | Renewal |

Story points: 2.0
Investigate missing props in subscriptions list component

### Problem

I noticed in `subscription_list.vue` we're using `subscription` component with 3 missing props.

![Screen_Shot_2020-09-04_at_19.00.23](/uploads/be218db5d0196cd1e12c646713b2c78a/Screen_Shot_2020-09-04_at_19.00.23.png)

### Proposal

We should either add the missing props or update the `subscription` component props to be optional.

### Result

Consistent code base and fewer potential errors in the future.

### Next steps (if any)

Schedule for development

### How will we measure success?

Story points: 2.0
Refactor plans setup with keys(POC)

The following discussion from !1893 should be addressed:

- [ ] @dstull started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1893#note_406260952):  (+3 comments)

    > **thought (non-blocking):** 
    > 
    > This is starting to feel like it doesn't scale too well as we keep adding to it.
    > 
    > A possible alternative would be to add a table to store all of these `product_rate_plan_id` along with a `type` column to the table and leverage that to determine the actual plan zuora is sending back - by changing the way we store this data for retrieval, we could simplify things here a bit.
    > 
    > For instance:
    > 
    > Adding a table with `product_rate_plan_id` as `id` and `type` and `year`(1, 2, 3 or 5 if needed).  We could then have STI models where we have `StarterRatePlan`, `UltimateRatePlan`, etc... with a `RatePlan` model that base off of this one - we could also create multiple tables if wanted instead of STI and have a similar concept.
    > 
    > 
    > We then would be able simplify the case statement you have below - probably change the concept a bit more here by leveraging something like `RatePlan.find_by(id: product_rate_plan_id).type`, where type would be `starter`, `premium`, etc
    > 
    > food for thought as an alternative here...could likely also achieve similar code simplification perhaps be a slight restructure of the plans in the `application.yml` and then leverage includes and other enumerable tools.

Story points: 3.0
Follow-up from "Add UI for adding seats to a dotcom subscription"

The following discussion from !1830 should be addressed:

In a review comment for https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1830#note_406673174 it was brought up that the partial names that are rendered in the `subscriptions#edit` action can be misleading. Therefore renaming them would make their purpose clearer when reading them.

Let's rename these two partials in `app/views/subscriptions/`:

* `edit_ee_subscription` -> `add_more_seats`
* `edit_gitlab_com_subscription` -> `change_linked_namespace`

Story points: 1.0
Upgrade PG to v12 (or latest version matching GitLab)

### Problem

In a [recent Slack conversation](https://gitlab.slack.com/archives/CMJ8JR0RH/p1599142834248400), the idea of upgrading the PG version for CI was raised.  However, it would not be compatible with staging and production.  In fact, staging and production (v9.5) are already out of sync with CI (v10).

### Proposal

We should upgrade PG to at least v12 (or the latest version GitLab is using) and ensure all environments and all documentation are updated accordingly.

### Result
More modern version of PG with consistency across environments.

Story points: 2.0
Follow-up from "Disable sync to GitLab for self-managed subs"

The following discussion from !1894 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1894#note_406268457): 

    > **Suggestion (non-blocking):** In a future iteration, we could probably break this out into a separate method to reduce the amount of conditionals and nesting in this method.  It's very minor but might help with readability.

Move code regarding syncing the plan to GitLab in the `Gitlab::HostedPlans::UpgradeSubscriptionPlanService` to an extra method.

Story points: 1.0
Align migration helper dir structure with GitLab's

The following discussion from !1879 should be addressed:

- [ ] @dstull started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1879#note_404886055): 

    > we should try and move this and the migration helper code under a dir structure that more closely mirrors where we need to sync it from for ease of updating - `spec/lib/gitlab/database/migrations_helper_spec.rb` and `lib/gitlab/database/migrations_helper.rb`. - I'll spawn a follow up as well once MR is reviewed a bit.

Story points: 1.0
Add "Max Seats Used" to the Customers Portal Admin view

## Summary

Currently we display `Seats currently in use` for SaaS subscriptions in the Customers Portal admin view on the `GitLab Groups` page. Sales needs to view the `Max Seats Used` as well. 

Let's add this to the view next to the `Seats Currently in Use` column.

![max](/uploads/66c79aaead68d251a78039d69b85bfde/max.png)

Story points: 3.0
Create test plan for Web Direct Opportunities Need Quote and Product Data

## Summary

As https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1379 and https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1380 have closed, we need to test the integration prior to shipping to production.

[These action](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/911#note_406203237) are the next steps to test in order to gain approval for deploying to production:

* [ ] Clone [customers.gitlab.com](https://gitlab.com/gitlab-org/customers-gitlab-com)
* [ ] Work with @vshumilo and @cwiesner to get Ruby and the IRB working with customers, please tell us if there is existing documentation
* [ ] Point your local environment at our Sandbox, using your creds (so we can tell our tests apart from others)
* [ ] Put together a test script of the IRB commands you are firing and then checking the results in Salesforce sandbox.
* [ ] **Stretch Goal:** Be able to do a complete purchase via the Portal App running locally and verify results.

Noting that @jpetr will be the lead from the SFDC side.

Story points: 2.0
Refactor CreateSalesforceLeadService code paths to be more declarative

Do not trigger off of merge 2 times.  We know when we call this class what 'type' we are, but then we try to 'figure it out' again inside the class.

The following discussion from !1879 should be addressed:

- [ ] @dstull started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1879#note_404893174):  (+3 comments)

    > I marked this one as a `todo` because I see why it is needed in the current condition of this class - However, I think this could be improved from the code side.
    > 
    > For instance, this seems to be called only a handful of places and could be broken up into 2-3 classes instead of one and each called from the outside correctly - that would greatly reduce the switching/conditional logic in the current class and therefore simplify the tests and eventually make this logic unneeded....
    > 
    > I'll generate a follow up issue once this has passed through reviews a bit more.

Story points: 2.0
Discussion: Why do we reset the subscription start/end date when we downgrade someone to free?

# Overview
As part of the .com downgrade effort, we have a banner that is intended to display if the customer is past their subscription end date AND on a free plan. 

During testing we realized that the downgrade code initiated through Zuora as well as the Customers Portal reset the subscription start date to the date of the downgrade and clears out the end date. 


We would like to understand why this is the case and if there would be any unforeseen consequences if we were to change it. 

Please discuss. 

CC @amandarueda @chris_baus @jameslopez @pcalder @jejacks0n @jayswain

Story points: 1.0
Add CI mins product details section in subscription-v2 component

<!-- 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/

-->
### Proposal
Similar to https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5379, create a new section to show CI minutes product details.  
![image](/uploads/0fc3203cf90b9c8068a518b04fb61f01/image.png)

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result

### Next steps (if any)

### How will we measure success?

Design: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3916

Story points: 2.0