giseldo/neodataset huggingface dataset:
Add structured tracking events for sending of self-managed trial licenses

## Problem

We do not currently have a structured tracking event available to understand when a trial license key has been sent to a user, which means we cannot understand the completion rates of the full end-to-end flow for self-managed trials. 

More information in this thread: https://gitlab.com/groups/gitlab-org/-/epics/7612#note_852942467

## Proposal

1. Add a structured tracking event for when the trial license is sent. 
1. Consider adding a separate structured tracking event for when a non-trial license is sent (if it doesn't exist)  

> So we'd just need some way to know that the license key email was sent and to whom (hashed email perhaps?).

> I'm not sure how the standard paid license key email is generated and sent (or if it is still even an option as we transition to Cloud Licensing), but if it is then I'd suspect the code is in a similar area and could probably be instrumented as part of a pay flow instrumentation. (This again assumes that there are still self-managed license key emails being created and sent and not exclusively cloud licensing).

## How will we measure success?

If we can understand in Sisense if a trial license has been sent.

## Potential Structure of Event


| Description | Category | Action | Label | Product Section | Product Group | Distributions | Tiers | Notes |
| ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ |  ------ |
| Backend Structured Event to record when the trial email for Self-Managed is sent to the User | `default` | `click_button`| `push_sm_trial_email` | `Dev` | `Devops:Growth` | ce, ee | trial |Please ensure a grain exists that we can join upon reliably. Ideally both `gsc_pseudonymized_user_id` and `instance_id` |

Story points: 5.0
[Change Management] Warning message about label misusage

### Problem

Engineers may pick issues when the label ~"workflow::ready for development" is not set, or any ~"UX Product Design" is set so the UX is still worked on.

Related to https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1294

### Proposal

Given our [product workflow](https://about.gitlab.com/handbook/product-development-flow), make sure that when an MR is opened, the expected labels are set in the corresponding issue. If they are not, warn in Danger about it.

We should also warn, depending on the issue labels, whether a UX (or other type of) review is required.

Story points: 5.0
The ActivateService sets activated_at timestamp even if activation fails

### Problem

@vshumilo [identified here](https://gitlab.slack.com/archives/CL7SX4N86/p1645454361851859?thread_ts=1645430143.560179&cid=CL7SX4N86) the `CloudActivations::ActivateService` still sets the `activated_at` timestamp even if the service ultimately fails which leads to misleading data.  The activation in this case ([Sentry error](https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/3201934/?referrer=slack)) failed because the `current_subscription` was not found for the `cloud_activation` record ([code](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/dded5fcb0654a9af94b78c3153b4acadb1e5e60d/app/services/cloud_activations/activate_service.rb#L51)).  This was likely because the customer was attempting to activate a future-effective subscription that had no current term.  This specific case should be addressed by https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3980, however this is just an illustration for how an error in activation still leads to incorrectly marking the instance as being activation in the CustomersDot database.

This is likely not a big concern, at least right now, but it's also not great that the instance is marked as activated in the CustomersDot DB when the activation failed.  It's not a big impact because this value will get updated when they activate again later, but it would be better to have valid data.

### Proposal

The `CloudActivations::ActivateService` should probably be wrapped in a transaction to rollback changes if a failure occurs in the service.  This would mean the `activated_at` timestamp would not be saved if the activation failed for any reason.

Story points: 3.0
[Community Programs] Incorrect text for SaaS flow in purchase modal on checkout 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

As mentioned in this [note](https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/408#note_848542868), the copy in the purchase modal in Community programs checkout page is currently the "self manged" copy, there's [different copy for the SaaS modal](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2677/designs/User_flow.png).
| Current | Expected |
|---------|----------|
| ![Screen_Shot_2022-02-18_at_4.10.33_PM](https://gitlab.com/gitlab-org/fulfillment-meta/uploads/3be6a87bcd5c0e43c54e5f9cd1f82e5d/Screen_Shot_2022-02-18_at_4.10.33_PM.png) | ![Screen_Shot_2022-02-18_at_4.19.08_PM](https://gitlab.com/gitlab-org/fulfillment-meta/uploads/b4aeaea7bede1908a0606d0c90c263c9/Screen_Shot_2022-02-18_at_4.19.08_PM.png) |

### Proposal

Change copy as per [the copy for SaaS flow](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2677/designs/User_flow.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?

Related to https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/408

Story points: 2.0
[Community Programs] SaaS - Incorrect text and extra space in checkout page

Note that for self-managed this should still say **License**

As raised in this [note](https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/408#note_848542868), 
1. Need to change the word "license" to "subscription"
2. Remove extra space before period.

Refer to screenshot for details.

![image](/uploads/f0d25e27671192c21303c7b32007aff9/image.png)

Related to fulfillment-meta#408.

Story points: 2.0
Trueup shows validation error if set to 0

## Summary

On SM renewal page the customer is asked to enter the "Active users" and also the True-up value for the old subscription. We are using the [purchase_subscription_details.vue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/master/app/frontend/javascripts/purchase/components/purchase_subscription_details.vue) to display the Active users and also the True-up information on the frontend. 

Due to the validation to not allow users to enter value less than 0 during the purchase/renewal of users the same validation also got invoked for True-up box. See the screenshot below. This does not allow the users to renew the subscription with 0 true up quantity. The True-up count box becomes red and an error is seen below it "Users over license quantity is not a valid number"

## Steps to reproduce

1. Go to renew page of a SM subscription.
1. Update the trueup value to greater than 0
1. Now set the trueup value to 0
1. Error - "Users over license quantity is not a valid number" is displayed under the box

## What is the current *bug* behavior?

Validation error - "Users over license quantity is not a valid number" is displayed under the true up box if value is updated to 0

## What is the expected *correct* behavior?

It should allow customer to set value to 0

![Screenshot_2022-02-19_at_01.18.18](/uploads/b8ecedda285042ebe9908f843de7b8e4/Screenshot_2022-02-19_at_01.18.18.png)

Story points: 2.0
Trueup is negative if reconciliation user count is less than subscription quantity

## Problem

If the reconciliation max users count value reported is less than the subscriptions total quantity then during renewal the trueup value is shown to be negative. 

On [renewal page](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/master/app/views/subscriptions/renew.html.haml) we do the following calculations

```ruby
user_count = reconciliation_active ? @subscription.latest_reconciliation&.user_count : @subscription.user_count
current_user_count = user_count || product.quantity
users_over_license = current_user_count - product.quantity
```

If the active users count of an SM license has always been less than the license subscriptions quantity then `users_over_license` is set as negative. 

EX :- A subscription was brought for 10 users

* SeatLinkData with 8 users were reported anytime during the whole year
* then user_count = 8
* current_user_count = 8
* users_over_license = 8 - 10 = -2

The users_over_license is used to setup the trueup quantity on the renew page. 

As seen in the screenshot below the trueup value is set as -2 

## Steps to reproduce

1. Buy a license with 10 users starting last year.
1. Create a reconciliation entry for the order with user_count as 8
1. Go to Manage Subscription and then press Renew for the subscription
1. The renew page will show the trueup value as -2

## What is the current *bug* behavior?

The trueup value shown is -2

## What is the expected *correct* behavior?

The trueup value should be shown as 0

## Relevant logs and/or screenshots

![Screenshot_2022-02-19_at_01.18.01](/uploads/68c56aa4e65258764886dd922fd60848/Screenshot_2022-02-19_at_01.18.01.png)

Story points: 1.0
Follow-up from "Camelize names of fields to nullify for update"

The following discussion from !4302 should be addressed:

- [ ] @lulalala started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4302#note_845788236):  (+1 comment)

    > **question:**
    > 
    > Why do we pass `type: "Subscription"` here? It seems `type` is used to determine whether lower camelCase should be used or not.
    > 
    > Also does [IronBank's deep_camelise](https://github.com/zendesk/iron_bank/blob/ef39c2b58f618f202d02492b121a8f187c1ae55b/lib/iron_bank/actions/update.rb#L19) not cover this nested hash?

Story points: 1.0
Replace asdf-yarn with global installation via npm

<!-- 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

Right now we install yarn via `asdf-yarn` plugin but:

- this method is deprecated for Yarn 2/3. In order to make our transition to Yarn 2/2 more smooth we should migrate away from installing Yarn directly with `asdf` and reply on NPM.
- make impossible to install default global NPM packages with `.default-npm-packages`.
- `asdf-yarn` does not play well with globally installed packages via `yarn global add`.

### Proposal

Remove `asdf-yarn` in favor of `npm install -g yarn`.

<!-- 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?

Story points: 1.0
Support Amendment and Order callouts

### Problem

Related to https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3926 and https://gitlab.com/gitlab-com/business-technology/enterprise-apps/financeops/finance-systems/-/issues/579 and https://gitlab.com/gitlab-com/business-technology/enterprise-apps/financeops/finance-systems/-/issues/590

With Orders Harmonization, both the Subscribe and Amend API (used by CDot) and the Orders API (utilized by Zuora CPQ and the Zuora UI) can be utilized concurrently. Previous to this latest release, however, both order and amendment notifications were triggered for any subscription creation or amendment created through the Subscribe and Amend APIs. As a result, as part of the Orders Harmonization project, we refactored CustomersDot to continue to utilize the Subscribe and Amend API when creating or modifying subscriptions, but to only receive an `Order Processed` callout. Once the `Order Processed` callout was received by CDot, we were able to query for the Order Details, such as Order Actions and associated Rate Plans / Rate Plan Charges.

With this release, Zuora has changed the default behavior, which is intended to prevent duplicate (Amend and Order) notifications from firing:

> We have now changed the default notification behavior in the tenants with Orders Harmonization enabled to the following:
>
> Only amendment notifications are triggered for amendments that are created through the Subscribe and Amend APIs. Only order notifications are triggered for order actions that are created through the “Create an order” operation. As of Zuora Release 2022.01.R3, any new customers onboard on Orders Harmonization will have the new default notification behavior in their tenants.

### Proposal

Rather than downgrading Zuora to get back to the previous callout behavior, we want to update CDot to accommodate the new behavior.  To do this, we must enable both Amendment and Order Notifications. This would allow CustomersDot to continue to utilize the Subscribe and Amend API when creating or amending subscriptions. 

The `ZuoraCalloutWorker` has [logic that was created to prevent processing duplicate callouts](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/1ea64ad9fda6231056b46518c5d3ef3393157295/app/workers/zuora_callback_worker.rb#L54).  We should remove this logic as now we shouldn't have to worry about duplicates (in Zuora Central Sandbox).  

**Notes** 
- @jesssalcido is enabling the amendment callouts in Zuora Central Sandbox now.
- We should upgrade Zuora API Sandbox to the same release version as Central Sandbox to avoid duplicates in this environment.  I think we can live with this discrepancy in development until this environment is updated.  @jesssalcido is working with Zuora now to get this upgraded.
- Until this issue is address, deploys to [CDot production will continue to be blocked](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3995) as this flow needs to be fixed for QA pipelines to pass.

/cc @gitlab-com/business-technology/enterprise-apps/zuora-architects

Story points: 1.0
[SaaS, Introductory email] - send email to all group owners

## Description

As part of https://gitlab.com/groups/gitlab-org/-/epics/7229, we will be sending few mails 1 day after a subscription has been purchased or renewed.

In https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4000 we went with [de-scoped list of users to send to](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3998#note_841620195) but that doesn't [solve the problem](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3998#note_841620209)

We should send an email to **all group Owners** (not just the group Owner who purchased the subscription), because all group Owners should be aware of the overage behaviour. 

## Implementation plan

|  |  |
| ------ | ------ |
| create mailers | https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3999 |
| MVC identify CustomersDot emails to send to | https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4000 |
| send introductory email 1 day after purchase |https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4007 |
| send introductory email 1 day after renewal | https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4008 | 
| query GitLab.com for group owners emails and send | :point_left: you are here |

## Tasks

Replace [MVC solution](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4000) of customers to send to with **group Owners of namespace**

Story points: 5.0
[SaaS, Introductory email] - send email 1 day after renewal

## Description

As part of https://gitlab.com/groups/gitlab-org/-/epics/7229, we will be sending few mails 1 day after a subscription has been purchased or renewed.

Using the mailer introduced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3999 and the selector introduced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4000 to send an email 1 day after a subscription has been renewed to make them aware of how users are counted and how overages are handled.

## Implementation plan

|  |  |
| ------ | ------ |
| create mailers | https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3999 |
| MVC identify CustomersDot emails to send to | https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4000 |
| send introductory email 1 day after purchase |https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4007 |
| send introductory email 1 day after renewal | :point_left: you are here | 
| query GitLab.com for group owners emails and send | https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4009 |

## Tasks

Queue [email](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3999) to send 1 day after renewal

Story points: 2.0
[SaaS, Introductory email] - send email 1 day after purchase (namespace link)

## Description
As part of https://gitlab.com/groups/gitlab-org/-/epics/7229, we will be sending few mails 1 day after a GL.com subscription has been purchased or renewed.

Using the mailer introduced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3999 and the selector introduced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4000 to send an email 1 day after a subscription has been [linked to a namespace](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4005#note_843627137) (purchased) to make them aware of how users are counted and how overages are handled.

_PS - The mailer needs to be sent 1 day after the namespace_id has been set. The future requirements are to fetch [all the group owners](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4009) and that would be only possible if the namespace_id has been set._

## Implementation plan

|  |  |
| ------ | ------ |
| create mailers | https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3999 |
| MVC identify CustomersDot emails to send to | https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4000 |
| send introductory email 1 day after purchase |:point_left: you are here |
| send introductory email 1 day after renewal | https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4008|
| query GitLab.com for group owners emails and send | https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4009 |

## Background 

* https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4005#note_843627137
* https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4005#note_843627118

Story points: 3.0
[Introductory email] - MVC Identify CustomersDot emails to send to

## Description

As part of https://gitlab.com/groups/gitlab-org/-/epics/7229, we will be sending few mails 1 day after a subscription has been purchased or renewed.

Currently, we [have a method](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/master/app/models/customer.rb#L89) within the customers model which fetches all the customers based on `zuora_account_id`. The method is a [instance method](http://www.cs.ecu.edu/karl/3200/fall15/Notes/Java/Class/method.html). 

We need a method which when called with parameter `zuora_account_id` and returns all customers matching the same `zuora_account_id`. 

## Implementation plan

|  |  |
| ------ | ------ |
| create mailers | https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3999 |
| MVC identify CustomersDot emails to send to | :point_left: you are here |
| send introductory email 1 day after purchase |https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4007 |
| send introductory email 1 day after renewal | https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4008 | 
| query GitLab.com for group owners emails and send | https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4009 |


### Proposal

Create a [scope](https://www.rubyguides.com/2019/10/scopes-in-ruby-on-rails/) within Customer model which takes `zuora_account_id` and returns list of matching customers.

Story points: 1.0
500 error when purchasing CI minutes

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label in relevant trackers:

- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=bug
- https://gitlab.com/gitlab-org/customers-gitlab-com/issues?label_name%5B%5D=bug

and verify the issue you're about to submit isn't a duplicate.

Do not include confidential information!
--->

# Bug

## Summary

Customers are reporting 500 Error when purchasing CI minutes from GitLab. 

An example of the Sentry error event is:

- https://sentry.gitlab.net/gitlab/gitlabcom-clientside/issues/3188813/events/67125403/
- "HTTP status code: 500"
- Time: Feb 10, 2022 1:49:06 PM UTC

## Steps to reproduce

(How one can reproduce the issue - this is very important)

## 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



## Workarounds

(Ways to get around the issue)

## Reported examples

1. https://gitlab.zendesk.com/agent/tickets/267889 - https://sentry.gitlab.net/gitlab/gitlabcom-clientside/issues/3188813/events/67128388/
1. https://gitlab.zendesk.com/agent/tickets/267771 - https://sentry.gitlab.net/gitlab/gitlabcom-clientside/issues/3188813/events/67125403/
1. https://gitlab.zendesk.com/agent/tickets/268022 - https://sentry.gitlab.net/gitlab/gitlabcom-clientside/issues/3188813/events/67130149/

<!---
Please add both severity and priority level according to: https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#severity-labels
--->

Story points: 1.0
Resume / cancel subscription buttons from home page are non-functional

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label in relevant trackers:

- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=bug
- https://gitlab.com/gitlab-org/customers-gitlab-com/issues?label_name%5B%5D=bug

and verify the issue you're about to submit isn't a duplicate.

Do not include confidential information!
--->

# Bug

## Summary

Renewing and cancelling from Customers Portal home page doesn't resume / cancel a subscription.

**Cause**: [`SubscriptionCards`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/3855-unify-root-and-subscription-pages/app/assets/javascripts/dispatcher.js#L13) which makes the call to update the subscription is only executed for `/subscriptions` and `/subscriptions/<subscription-id>` pages but not from home page.

## Steps to reproduce

1. Visit Customers Portal with an account that has subscriptions
1. Click on `Resume subscription` or `Cancel subscription` for a subscription

## What is the current *bug* behavior?

The subscription is not resumed / cancelled and no corresponding API calls.

## What is the expected *correct* behavior?

The subscription should be resumed / cancelled as per the customers action.

## Relevant logs and/or screenshots

![Screen_Shot_2022-02-09_at_10.25.51_PM](/uploads/ad37c0a873d645892b63d661a35a8f87/Screen_Shot_2022-02-09_at_10.25.51_PM.png)

## Workarounds

Customer can still resume or cancel a subscription by going into `/subscriptions` page.

## Reported examples


<!---
Please add both severity and priority level according to: https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#severity-labels
--->

Story points: 1.0