giseldo/neodataset huggingface dataset:
Fix contact support link in error messages

### Problem

The `contact support` link in the error message is not properly formatted

![screenshot-2022-06-13-09_37](/uploads/0a6ec28775c1a3f8ea118b4865910893/screenshot-2022-06-13-09_37.png)

Check all cases where we use errors from our [constants.js](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/1b7dadd279cb16ad0c26a9ee4127951cea9ded35/app/frontend/javascripts/constants.js) and make sure to add `sprintf` to every ussage.

Story points: 1.0
Handle true ups for community program subscriptions

### Problem

GitLab does not prevent customers from exceeding their seat count. For paying customers with legacy licenses (community programs also uses legacy licenses), we ask them to pay for overages when they renew for the next year, a process called true-ups. However, since community programs licenses are free, there's really no need to ask them to pay for or report any overages, since any true-ups charges would be for $0 anyway.

### Proposal

Since the licenses for customers who are on 14.0 or earlier will error when they try to add them to the instance for missing true-up quantity, we should add a `very large number` of true-ups to every license for community program subscriptions so it works for both.

We should make sure this works for customers irrespective of the version they are on.

[Instructions to setup SM instance](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4397#note_991005945)

[Error message that should happen without the fix for testing purposes](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4397#note_991043970)

> After a subscription is renewed then a new license is generated for the SM customer. The renewed license contains information like new user quantity being renewed, starts_at, expires_at etc. It also contains the trueup_quantity information. The trueup_quantity is then pulled from the renewed license within the SM instance and verified with the last year's extra active user count. If the trueup quantity is less than the last year's users difference then an error is displayed on the SM instance.
>
> You have applied a True-up for #{trueup_qty} #{"user".pluralize(trueup_qty)}"]
but you need one for #{expected_trueup_qty} #{"user".pluralize(expected_trueup_qty)}."
Please contact sales at https://about.gitlab.com/sales/"


### Applicable SKUs

`ULTIMATE_SM_EDU_1_YEAR` and `ULTIMATE_SM_OSS_1_YEAR`

#### Post merge into `main`

It would be great to add the test scenarios under [True-ups section](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4182#11-true-ups-assignee-) in gitlab-org/customers-gitlab-com#4182+ and add screenshots once the fix is live so all the test scenarios are captured in the issue

#### Reference links

Original discussion: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2747/designs/Renewal_flow___Link_directly_into_renewal.png#note_627443393

Further discussion: https://gitlab.com/gitlab-org/gitlab/-/issues/363439#note_968411902

Story points: 5.0
[Code cleanup] Cleanup Zuora::Helpers::Subscription

<!-- 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

This module was temporarily added to hold common methods in subscription workflow. The module can be dropped once the migration to Orders API is complete.

### Proposal

<!-- 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
Ramp ID from Zuora GET Subscription API

### Problem

In https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4303, we implemented a solution to get Ramp ID for a subscription using the https://www.zuora.com/developer/api-reference/#operation/GET_RampsBySubscriptionKey Zuora API endpoint.  This was necessary because Ramp ID was not available through the existing Zuora API endpoint that CustomersDot uses to get other Subscription data, https://www.zuora.com/developer/api-reference/#operation/Object_GETSubscription.  

Using https://www.zuora.com/developer/api-reference/#operation/GET_RampsBySubscriptionKey works as a short-term solution, but isn't ideal because it requires an additional Zuora request to fetch Ramp ID.

### Proposal

Zuora has agreed to adding Ramp ID to the https://www.zuora.com/developer/api-reference/#operation/Object_GETSubscription API soon (potentially in late June).  When it becomes available, we can remove some of the logic introduced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4303, including the extra request to https://www.zuora.com/developer/api-reference/#operation/GET_RampsBySubscriptionKey.

Story points: 2.0
Flash notice missing upon successfully cancel subscription

<!-- 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 noticed a new e2e test failure in pipeline after new `cancellation_modal` implementation. 

The flash notice [`You have successfully unsubscribed from your GitLab plan`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/app/viewers/transaction_viewer.rb#L38) no longer presents after cancellation is confirmed

### Proposal

<!-- 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: 2.0
Number of users field should default to empty in purchase flow

# Feature Proposal

## Problem to solve

The number of users field in the new purchase flow defaults to `1`. [This has caused users](https://gitlab.com/gitlab-com/marketing/community-relations/community-operations/community-operations/-/issues/155#note_976584791) to accidentally purchase subscriptions for 1 user, because they do not change the default.

![Screen_Shot_2022-06-08_at_5.12.27_PM](/uploads/4e4006d335a098292345d7a93b0acefb/Screen_Shot_2022-06-08_at_5.12.27_PM.png)

----

![1654807686986](/uploads/7eaad789b4481c9eaaddc7592bd23c76/1654807686986.png)

### Flows affected

* New self-managed standard subscription purchase
* New self-managed community program subscription purchase

## Proposal

For the new subscription purchase flow and community programs new subscription flow, the default for the number of users field should be empty (and it should be a required field for the customer to purchase a subscription). This will force the customer to proactively enter a number instead of passively accepting our default of `1`.

Story points: 3.0
Default active users to current billable member count at renewal

# Bug

## Summary

The input field for number of users during renewal process for community program SaaS subscriptions should default to current billable members count. 

## Steps to reproduce

Create a SaaS Community Program subscription due for renewal. Add more billable users to the group associated with the subscription so the original purchase quantity is less than the current billable members count.

## What is the current *bug* behavior?

The input field for number of users on renewal screen defaults to the number of seats in the previous year's subscription.

## What is the expected *correct* behavior?

It should be defaulted to current billable member count.

## Relevant logs and/or screenshots

![Screen_Shot_2022-06-07_at_3.27.24_PM](/uploads/4f8ac7b95c60413577464f7b3ee8689e/Screen_Shot_2022-06-07_at_3.27.24_PM.png)

![Screen_Shot_2022-06-07_at_3.30.34_PM](/uploads/db848aed03acc2e7c8ed17e321751d6a/Screen_Shot_2022-06-07_at_3.30.34_PM.png)

![Screen_Shot_2022-06-07_at_3.30.52_PM](/uploads/7928cb62298ed7386fa7157623fcbc50/Screen_Shot_2022-06-07_at_3.30.52_PM.png)

Story points: 1.0
Service to generate custom attributes for Orders API (CreateSubscription)

<!-- 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

Create a service that returns custom attributes required while creating a subscription. It will be used in [`OrderManagerService`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4314) when creating a new subscription using Order's API.

It represents the `orderLineItems[:customFields]` param in [Orders API](https://www.zuora.com/developer/api-reference/#operation/POST_Order).

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Create a service: `Zuora::Orders::CustomFields::CreateSubscription` that implements `#execute` method. It should return a has of custom attributes required when [creating a new subscription](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/6de4998feb23012df7cb7ee8a83874a7aaf49dfa/app/services/subscribe_service.rb#L276). Re use this service is `SubscribeService` to avoid duplication of code.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Frontend validation against emoji customers info during edit

### Problem

Customers are able to set emoji in their names in CustomersDot accounts. When we try to make a subscription purchase, we take the `bill_to_contact` details from the Customer record in the CustomersDot app. This results [in the following error from Zuora:](https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/3267234/events/76539035/)

```ruby
Body: [{"Success"=>false, "Errors"=>[{"Code"=>"UNKNOWN_ERROR", "Message"=>"Operation failed due to an unknown error."}]}]
```

<img src="/uploads/97e77d6dcc65d008dc0e8d5144c528c4/CleanShot_2022-05-09_at_15.05.09.png" width='500px' />

### Steps to reproduce

1. Login to your CustomersDot via GitLab
1. Navigate to `/customers/edit`
1. Update the details adding an emoji to the First Name
1. Click on `Save changes`
1. There is an error message

|||
|-|-|
|![Screenshot_2022-06-03_at_07.01.48](/uploads/c4a22d73f1480e7c1814eb02d486cf5c/Screenshot_2022-06-03_at_07.01.48.png)|![Screenshot_2022-06-03_at_07.02.00](/uploads/d42d73d28c45180c2cfb6bb85b8be9e5/Screenshot_2022-06-03_at_07.02.00.png)|

### Proposal

The presence of emojis should be validated before submission. We can leverage the `emoji-regex` module (the same as gitlab-org/customers-gitlab-com#4274).

The fields to validate against the presence of emoji are:

- first_name
- last_name
- city
- zip_code (postal_code)
- company

|Description|MR|
|-|-|
| Introduce validation directive | gitlab-org/customers-gitlab-com!5006 |
| Prevent submission on customer edit if emoji are present| gitlab-org/customers-gitlab-com!5017|
| Add/update feature tests | _tbd_ |

Story points: 3.0
Remove cancellation_modal HAML file

<!-- 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
After https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4352+ is merged, we can remove the old [cancellation modal HAML file](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/51e415d434b177b787900402d8d90d7b9f7e12b8/app/views/subscriptions/_cancellation_modal.html.haml). Additionally, we should change from using the GL utility classes in our CSS file to in the component (discussion [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4799#note_960393274))

Also remove the border around the "To help improve our product..." area (request [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4035#note_973054549))

Additionally, we can remove the cancellation_modal FF.

Story points: 1.0
Provide an update of customers-gitlab-com to customers-gitlab-cn with latest changes for May '22

Refer to the documentation inhttps://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/doc/security/distribution.md and the previous attempts below to remove or randomize secrets to provide an updated CustomersDot for the JiHu team.

**Tasks Overview**

* [x] Pull the latest from https://gitlab.com/gitlab-org/customers-gitlab-com repository
* [x] In a new branch, replace any sensitive production keys from code and documentation.
* [ ] Review changes with peers and maintainers
* [ ] Submit MR to customers-gitlab-cn with files in the scrubbed branch with the history removed as a single commit.

## Previous Attempts

* #160
* #184
* #198

Story points: 1.0
Track subscription management events on BE

This is a ~backend part of the Customer Portal subscription management tracking. The click tracking is implemented in the https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3690

* Collection tool: Snowplow
* Release behind the feature flag (separate from https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3689): `tracking_subscription_management`

List of transactions to track:

* `Add more seats` - track full transaction
* `Upgrade` - track full transaction
* `Renew` - track full transaction
* `Buy more CI minutes`/Buy more storage\` - track full transaction
* `Change linked namespace` - track full transaction
* `Cancel` - is already tracked

| Transaction | Event action | Link |
| ------ | ------ | ------ |
| Renew subscription | 'renew_subscription_saas'/'renew_subscription_sm' | /subscriptions/<SUBSCRIPTION_ID>/renew |
| Upgrade subscription | 'upgrade_subscription_saas'/'upgrade_subscription_sm' | /subscriptions/<SUBSCRIPTION_ID>/upgrade/new |
| Add more seats to a subscription | 'add_seats_saas'/'add_seats_sm' | /subscriptions/<SUBSCRIPTION_ID>/edit?transaction=extra_seats |
| Buy CI minutes (SaaS only) | 'buy_ci_minutes' | /subscriptions/new?plan_id=2c92c0f9699eca030169a2f1f117045f&subscription_id=<SUBSCRIPTION_ID>&transaction=ci_minutes |
| Buy storage (SaaS only) | 'buy_storage_plan' | /subscriptions/new?plan_id=2c92c0f8725e55d70172613f547f0b59&subscription_id=<SUBSCRIPTION_ID>&transaction=storage |
| Change linked namespace (SaaS only) | 'change_namespace' | /subscriptions/<SUBSCRIPTION_ID>/edit?transaction=change_gitlab_group |

Story points: 2.0
Create class to get and put gitlab_subscription request

### Problem

We are making [GET and PUT calls](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/app/services/check_order_in_sync_service.rb#L129) to API "/api/v4/namespaces/<namespace_id>/gitlab_subscriptions" and are using admin_token for authentication. 

As of now, we do not have a class or a module which can help in making the API call to GL.com `gitlab_subscriptions` from CustomersDot for a namespace.  

### Proposal

Create a class which would abstract the API call to `gitlab_subscriptions` for a namespace_id provided as a parameter. The class can make 3 calls, GET, POST and PUT to `/api/v4/namespaces/<namespace_id>/gitlab_subscriptions`.

### Next steps (if any)

Replace the GET, PUT and POST call to `gitlab_subscriptions` with the new class created.

Story points: 2.0
User received "Managing users in your subscription" email when taking out trial

<!---
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

User receive email `Managing users in your subscription` after taking out a trial on GitLab.com.

This might have to something to do with https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/app/mailers/reconciliation_introductory_mailer.rb

## 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

(Paste any relevant logs - please use code blocks (```) to format console output,
logs, and code as it's tough to read otherwise.)

**EMAIL**

```
Subject: [GitLab Transactions] Managing users in your subscription
Body:
Dear <User Name>,

Thank you for purchasing a GitLab.com subscription! As you get started, we want to make sure you understand some important billing information.

Your subscription cost is based on the maximum number of users enabled during the billing period. If you reach the maximum number of users in your subscription, you can continue to add users and GitLab bills you for the overage. These bills occur every quarter.

For more information about quarterly reconciliation, see https://docs.gitlab.com/ee/subscriptions/quarterly_reconciliation.html

If you have any questions about this process, please contact https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=360000071293. We are happy to assist.

Thank you again for your purchase!

GitLab Billing Team
```

## Workarounds

(Ways to get around the issue)

## Reported examples

1. https://gitlab.zendesk.com/agent/tickets/292626, [SFDC](https://gitlab.my.salesforce.com/00T8X00005fHRFR?fId=0D58X0000A6KEl1&s1oid=00D61000000JNOF&s1nid=000000000000000&emkind=chatterCommentNotification&s1uid=0054M000003VUza&emtm=1653452401008&fromEmail=1&s1ext=0)
1. https://gitlab.zendesk.com/agent/tickets/296897
1. https://gitlab.zendesk.com/agent/tickets/300565
1. https://gitlab.zendesk.com/agent/tickets/300966
1. https://gitlab.zendesk.com/agent/tickets/302027 (OSS program)
2. https://gitlab.zendesk.com/agent/tickets/302269
3. https://gitlab.zendesk.com/agent/tickets/302287

<!---
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
Set maintenance automatically if GitLab is down

### Problem

When GitLab.com is down, while we get notified, maintenance mode has to be set manually to avoid any errors from our side.

### Proposal

Similar to https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4228+ we could automatically set maintenance mode if GitLab.com is down (for long enough)

We could replicate (and refactor) the same logic we use to do this with Zuora right now.

Story points: 3.0
Send PROVISIONED status to Platypus order status endpoint

### Background

Arrowsphere would like to know when an order has been successfully provisioned.  It was decided that CustomersDot could sent an order status request to Platypus after an Arrowsphere order has been "provisioned".  The Platypus order status endpoint is being built in https://gitlab.com/gitlab-com/business-technology/enterprise-apps/integrations/platypus/-/issues/226.  For MVC, "provisioned" simply means the license or activation code email has been sent from CustomersDot.

### Proposal

Send the order status request to Platypus after a successful delivery of the license or activation code email as part of processing the subscription/order Zuora callout.  This could be added [here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/f730068274d6d4a60615571539243c0c32bef935/app/workers/zuora_callback_worker.rb#L63) in the `ZuoraCallbackWorker` if the result was successful.

You can find details about the order status endpoint in https://gitlab.com/gitlab-com/business-technology/enterprise-apps/integrations/platypus/-/issues/226.

Story points: 2.0
Remove orders_harmonization feature flag

### Background

Orders Harmonization was enabled in Zuora Production on 2022-05-20.  More information available in https://gitlab.com/gitlab-com/business-technology/enterprise-apps/intake/-/issues/616.

As part of that enablement, the `orders_harmonization` feature flag was enabled in CustomersDot production.  The rollout issue has all the steps that were involved: https://gitlab.com/gitlab-org/gitlab/-/issues/345026.

### Proposal

Now that [the `orders_harmonization` feature flag](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/104/edit) has been enabled and stable for a few days, we should be safe to promote the feature flag code and remove the feature flag conditionals.  We can update [the rollout issue](https://gitlab.com/gitlab-org/gitlab/-/issues/345026#release-the-feature) once this is complete.

Story points: 1.0
Add Change linked namespace specific tracking

### Problem

Currently we are tracking clicks on subscription card buttons. This shows a general interest on features but doesn't reflect that user wants to actually do this action.

### Proposal

Update the existing tracking for subscription card buttons and add tracking to the actual pages.

Attention: some tracking **is already implemented**, we would just need to update the event labels & actions.

#### Change linked namespace

For all the tracking events set `event_label` as `change_namespace` (as this is only possible for SaaS)

| FE/BE | Page | Description | Event category | Event action |
| ------ | ------ | ------ |  ------ | ------ |
|FE| `/subscriptions/` | ![Screenshot_2022-11-15_at_21.52.22](/uploads/b35cf5e85e12b5adba68e12f7fc59d20/Screenshot_2022-11-15_at_21.52.22.png) <br> User clicks `Change linked namespace` button <br>  | Webstore | `click_card` |
|FE| `subscriptions/A-S000XXX/edit?transaction=change_gitlab_group` | ![Screenshot_2022-11-15_at_21.53.19](/uploads/259228b6486cdee55f971efab5b69ed1/Screenshot_2022-11-15_at_21.53.19.png) <br> User clicks `Confirm changes` button <br>  | Webstore | `click_change` |
|BE| - | Transaction is successful  | SubscriptionsController | `transaction_successful` |
|BE| - | Transaction has failed  | SubscriptionsController | `transaction_failed` |

### Next steps (if any)

After the issue is done please let `@nraisinghani` know because we need to update the values in the related dashboard.

Story points: 2.0