giseldo/neodataset huggingface dataset:
Update Unified Email template for SCL

<!-- 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
It's been discovered that the unified email template ([text version](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/b0767104a78c6e573e93b55fbbf105c5d0d8b1b3/app/views/unified_license_mailer/license_information_email.text.erb#L30-31) and [html version](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/b0767104a78c6e573e93b55fbbf105c5d0d8b1b3/app/views/unified_license_mailer/license_information_email.html.haml#L51-52)) currently still has text that is no longer relevant after the launch of strict cloud licensing, specifically directing customers to download their license from the Customers Portal, where it is no longer available.

This can result in a confusing customer experience.



### Proposal
Update the email template text as stated below.

**Current Template:**

```erb
### Unable to use the activation code?

If you have an offline or air gapped environment, or you're unable to upgrade to 14.1 and later, you cannot use the activation code.

* If you purchased directly from GitLab, download your license from the Customers Portal.
  <%= subscriptions_url %>
* If you purchased from a reseller, submit a support ticket to receive your license.
  https://support.gitlab.com/hc/en-us/requests/new

```

**Proposed Template:**

```
### Offline or air gapped instance?

If you have an offline or air gapped environment, you must use an offline license file or key. To request an offline license, submit a support ticket, https://support.gitlab.com/hc/en-us/requests/new
```

Story points: 1.0
Add feature tests for form submit preventing logic

We want to make sure the newly added logic that prevents the form from being submitted when emojis are present is also tested at the integration level.

The reason is that while the unit test [in here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/spec/frontend/sessions/register_form_spec.js#L134) gives some confidence about the Register form behaviour, (as [suggested](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4887#note_1012878978)) an integration test would yield a result closer to the real-life behaviour.

### Proposed solution

It should be sufficient to add an expectation to the current set of tests [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/spec/features/customer_sign_up_spec.rb).

### Proposed number of MRs

|Description|MR
|-|-|
| Add feature specs | 1 |

Story points: 1.0
Custom fields for new Zuora account

<!-- 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

https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4961 introduced the following custom attributes: `SSPChannel__c` and `Entity__c` and set `IsInvoiceSeparate = true` for all Marketplace subscriptions.

This change needs to be incorporated for Orders API.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Create custom attributes service class for New account and set the values appropriately. Consider moving the methods to subscription helper class.


### Result

The newly introduced custom attributes are set in the Orders workflow.

Story points: 2.0
Missing condition when creating missing cloud activation in admin area

### Problem

While looking into the code logic for the cloud activation creation, it was found that the checks for the automatic workflow (when a subscription callback comes from Zuora to CustomersDot) differ from the ones in place for the admin area workflow to create a missing cloud activation.

The automatic workflow [checks](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/bd99d8091d28f26aa62eec6578495da0a3ee9cbd/app/models/subscription.rb#L416-418) three conditions:
1. Does the subscription have a GitLab EE plan? ([code](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/bd99d8091d28f26aa62eec6578495da0a3ee9cbd/app/models/subscription.rb#L190))
2. Is the subscription cloud license compatible? ([code](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/bd99d8091d28f26aa62eec6578495da0a3ee9cbd/lib/zuora/subscription.rb#L47))
   * `TurnOnSeatReconciliation__c` is set
3. Can the subscription be cloud license activated? ([code](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/bd99d8091d28f26aa62eec6578495da0a3ee9cbd/app/models/subscription.rb#L475)) Which requires one of the following condition to return `true`:
   * the subscription was self serviced (subscription bought via CustomersDot)
   * `ContractSeatReconciliation__c` is not `null`
   * `ContractAutoRenew__c` is not `null`
   * `ContractOperationalMetrics__c` is not `null`

The admin area workflow [checks](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/bd99d8091d28f26aa62eec6578495da0a3ee9cbd/app/models/subscription.rb#L440-441) contain the checks from 1. and 2. but are missing 3. 

### Proposal

Align both workflows to do the same checks to ensure a cloud activation can only be created for eligible subscriptions. To do this, the [checks](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/bd99d8091d28f26aa62eec6578495da0a3ee9cbd/app/models/subscription.rb#L440-441) for the admin area workflow have to contain the check for a subscription to be cloud license activated ([code](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/bd99d8091d28f26aa62eec6578495da0a3ee9cbd/app/models/subscription.rb#L475)).

To ensure later modifications will be applied to both workflows, the three checks could be moved to their own method to be easily reused in the two workflows.

### Result

The automatic workflow and the admin area workflow are aligned with the checks for eligible subscriptions when checking if a cloud activation needs to be created.

Story points: 1.0
Revert PaymentTerm setting for Marketplace Zuora account

### Problem

Per [this discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4081#note_1011074254): we do not need to set Marketplace end user Zuora account `PaymentTerm` differently.

> the payment term only needs to be set on the Invoice Owner Account (Arrowsphere: Net 30 EOM). The payment term of the end user is irrelevant.

### Proposal

To clean up the code logic, we should revert related changes:
- https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/55a49713a3cd40a12e1334f7ba7fae4d6b5ffae2/app/services/zuora/helpers/subscription.rb#L24-29
- https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/55a49713a3cd40a12e1334f7ba7fae4d6b5ffae2/app/services/zuora/helpers/subscription.rb#L45-49

After revert, all paymentTerm will be the default value `DEFAULT_PAYMENT_TERM = 'Due Upon Receipt'`

### Result

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Set correct Terms of Service for Community program subscription renewal

## Problem

Similar to https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3185+, we should set correct subscription fields when Community Programs subscription renews, but ONLY if these fields have not been set already.

If the following fields are already set (from when the new subscription was created), do not change them.

## Proposal

Update fields according to this logic

### For SaaS

- `ContractAutoRenew__c` = No
- `TurnOnAutoRenew__c` = No
- `ContractSeatReconciliation__c` = No
- `TurnOnSeatReconciliation__c` = No


### For SM

- `ContractAutoRenew__c` = No
- `TurnOnAutoRenew__c` = No
- `ContractSeatReconciliation__c` = No
- `TurnOnSeatReconciliation__c` = No
- `TurnOnCloudLicensing__c` = No
- `ContractOperationalMetrics__c` = No
- `TurnOnOperationalMetrics__c` = No

### Result

### Next steps (if any)

### How will we measure success?

---

**Iteration MR/Issues Count:** 1

**Testing considerations:**

* Check community program renewals callback **updates** the super sonics flag correctly, if not set.
*  Check community program renewals callback **does not change** the super sonics flag, if already set
* Tips on how to create subscription ready for renewal: https://gitlab.com/gitlab-org/fulfillment-meta/-/blob/master/docs/tips_and_tricks/zuora.md#create-a-subscription-with-activation-date-in-the-past

Story points: 3.0
Prevent subscription purchase when quantity is invalid

### Problem

When user enters 0 as quantity during subscription purchase, subscription purchase/claim CTA is enabled even if quantity is invalid and user can successfully buy the subscription despite the invalid quantity entered. The subscription purchased is for the previous valid quantity entered. For example, user enters 3 for quantity, then changes to 0, clicks on Buy subscription - this will successfully create a subscription for 3 users.

| Feature | Current |
|-|-|
| New standard SM | ![Screen_Shot_2022-06-28_at_5.52.25_PM](/uploads/51e603f87d9722e2379a81b5c7ce5e0a/Screen_Shot_2022-06-28_at_5.52.25_PM.png)|
| New CP SM | ![Screen_Shot_2022-06-28_at_6.10.19_PM](/uploads/1c85b4879ac1a10881f4b58079c82ec6/Screen_Shot_2022-06-28_at_6.10.19_PM.png) |
| New standard SaaS | ![Screen_Shot_2022-06-28_at_5.56.33_PM](/uploads/ddf87441c9c4854683f5fa2a517142c5/Screen_Shot_2022-06-28_at_5.56.33_PM.png) |
| New CP SaaS | ![Screen_Shot_2022-06-28_at_6.04.50_PM](/uploads/18ca6537ceac2dbac0d9a3b77a42faf8/Screen_Shot_2022-06-28_at_6.04.50_PM.png) |

### Proposal

1. Disable the CTA when quantity is invalid so user can't purchase subscription when latest entered quantity is invalid
2. Replace the dollar value with `–` when quantity is invalid (replace the dollar values in the `order total` and the two `subtotal` lines)

![Screen_Shot_2022-06-29_at_5.33.08_PM](/uploads/cf144793f56799af4934e8bce74a92e8/Screen_Shot_2022-06-29_at_5.33.08_PM.png)

[Original discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4392#note_1010282717)

Story points: 2.0
Follow-up from "Notify Platypus when marketplace subscription provisioned"

There are two suggestions from MR review, which could be nice improvements:

The following discussion from !4982 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4982#note_1009838193): 

    > **Suggestion:** I thought rubocop warned about this but I think the preference is to break out the namespace hierarchy using `module` like you did for the class above.
    > 
    > ```
    > module Platypus
    >   class MarkSubscriptionProvisionedWorker
    > ```

- [ ] Another suggestion is [this comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4982#note_1009838197):
>>>
**Suggestion (non-blocking):** If we don't end up using the instance features of this class, you could consider a class that `extends self` instead, then the API to interact with this class is a little nicer (e.g. `Platypus::MarkSubscriptionProvisionedService.execute()`.

OR, if you wanted to keep it as-is, you could pass the attributes in `initialize`. This would allow you to set attr_readers for `external_subscription_source` and `external_subscription_id`. You could also break up this execute method a bit more this way. For instance, `access_token` could be it's own method.
>>>

Story points: 1.0
Process payments for new subscription in Orders API

The following discussion from !4947 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4947#note_1009249862):  (+1 comment)

    > **Question:** Will this logic for processing payments be captured in a later MR?  I'm just curious and totally fine if it's not included in this MR. :smile:

### Problem statement

Similar to how processing payment options are included in [Subscribe api](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/90fc752163c1f6f83cc104773b30289226ca166c/app/services/subscribe_service.rb#L103), we need a mechanism to set this in Orders API.

### Proposed solution

Cross posting the inferences from [this thread](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4446#note_1012628875):

In the subscribe api, the following options are sent in `subscribe_options` object:

```ruby
subscribeOptions: {
  generateInvoice: true,
  processPayments: <true if no coupon is used or if not marketplace>,
  subscribeInvoiceProcessingOptions: {
    invoiceDate: <current date>,
    invoiceProcessingScope: 'Subscription',
    invoiceTargetDate: <current date>
  }
}
```

While trying to map to Orders API, the following is what I was able to infer based on the description:
| Subscribe API | Orders API | Notes |
|---------------|------------|-------|
| `generateInvoice` | `runBilling` | |
| `processPayments` | `collectPayment` | |
| `InvoiceDate` | `documentDate` | |
| `InvoiceDate` | `targetDate` | |
| `subscribeInvoiceProcessingOptions` | - | Not required in Orders API |

Story points: 2.0
Refactor Order related implementation service methods to a class method

The following discussion from !4865 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4865#note_1004957734):  (+1 comment)

    > **Suggestion (non-blocking):** I wonder if it would be nice to consider adding class level methods for these new classes that allow us to execute by avoiding the `.new(...).execute` standard.  It would be a more convenient API, especially when it comes to stubbing in our tests.
    > 
    > `expect(OrderManagerService).to receive(:execute)`
    > 
    > vs.
    > 
    > ```
    > expect_next_instance_of(OrderManagerService) do |service|
    >   expect(service).to receive(:execute)
    > ```
    > 
    > Maybe something to consider in a future MR for these new Order classes if you like the idea.

Story points: 1.0
Implement Order preview

<!-- 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

Similar to subscription preview (before the actual purchase), we need a way to use the Orders API to preview an order.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Use the [Preview an order API](https://www.zuora.com/developer/api-reference/#operation/POST_PreviewOrder) for the preview workflow.

This is 3 step process:

| Step | Description | MR |
|------|-------------|----|
| Step 1 | Create Order Preview client and worker job that invokes the client | https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5170 |
| Step 2 | OrderPreview service | https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5168 |
| Step 3 | Using OrderPreview service in subscription preview workflow | https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5192 |

### Result

Preview subscription uses Order Preview API instead of Subscribe API.

### Next steps (if any)

### How will we measure success?

Story points: 3.0
[SaaS] Number of users field should default to group's billable user count in purchase flow

## Problem to solve

The number of users field in the new community programs SaaS subscription 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-27_at_1.22.25_PM](/uploads/aacb62c4287c84ea0d01c42f57ae9b31/Screen_Shot_2022-06-27_at_1.22.25_PM.png)

![Screen_Shot_2022-06-27_at_1.22.15_PM](/uploads/910479d4b5fc10eec52b6c129eb9afcd/Screen_Shot_2022-06-27_at_1.22.15_PM.png)

## Proposal

For the new community programs SaaS subscription purchase flow, the default for the number of users field should be group's billable user count.

The sections should also be reordered so that the namespace selection section comes before the user quantity section.

Story points: 2.0
Backfill to sync missing namespace data from CustomersDot to SFDC

## Problem

We recently identified a set of subscriptions with missing namespace fields.  This results in SFDC users unable to generate complete reports or view relevant customer subscription data.

## Background 
The likely causes for missing data values are as follows:
1. Zuora data null prior to ([sync integration](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1989)) implementation - expected since the work was move forward only. Technical work would be to backfill the data from GitLab.com-CustomersDot data.
1. Zuora data null post implementation - could be one of two causes:
   - Sales-assisted subscription in which the customer hasn't connected their namespace to the subscription yet. There's no technical work here.
   - Data sync issue, somewhere between Zuora-CustomersDot-GitLab.com, data is out of sync. Technical work would be to find the data issue, resolve it, and push the data to Zuora.
1. SFDC data null prior to the [latest work](https://gitlab.com/gitlab-com/business-technology/enterprise-apps/intake/-/issues/314) to bring the data in (I'm not sure of the date tbh) - I'd defer to the team who implemented the work, I'm not sure if they backfilled data which existed in Zuora.
1. SFDC data null post the latest work to bring the data in. - would be the same root cause as 2.2 above

## Proposal

Create a process to backfill missing namespace field values.

## Communication Plan

- [ ] Evaluate when this can be scheduled
- [ ] Once scheduled, communicate to Customer Success

Story points: 8.0
Include subscription custom attributes in Orders API

<!-- 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

https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4382 created a service that generates custom attributes required for new Subscription order action.

The [Orders API](https://www.zuora.com/developer/api-reference/#operation/POST_Order) requires subscription custom attributes to be sent in the `subscriptions` object:

```
{
  orderDate: ...,
  ...
  subscriptions: [
    {
      customFields: {

      },
      orderActions: [],
      ...
    }
  ]
}
```

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

In [OrderManagerService](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/d1f43892b1be3add5afba0f9f55a1719a9cb6470/app/services/zuora/orders/order_manager_service.rb), invoke the service `Zuora::Orders::CustomFields::CreateSubscription.new(customer: customer, params: params).execute` when order action is of New Subscription type.

### Result

New order includes the subscription custom fields set.

Story points: 2.0
Add feature spec for cancel flash notice behavior

<!-- 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 need to add a feature spec to verify the URL navigation behavior with the new [Vue cancelation modal](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/62e7646f3ba331c9892ff5f31d52207aaac5ac55/app/frontend/javascripts/subscription/components/cancellation_modal.vue). Thread [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4910#note_1000412840). 

Also remove [this unit test](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4910/diffs?diff_id=419419267#f07ba46d14657e90fe9c115cec0bd944f7d112e7_195_223) since the feature spec will better cover that scenario.

### Proposal
Add a test identical/very similar to [this](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/62e7646f3ba331c9892ff5f31d52207aaac5ac55/spec/features/existing_customers/renewal_spec.rb#L25) that uses the new Vue cancellation modal. 

### Result
We have better coverage of the new Vue cancel modal behavior when the user cancels their subscription.

Story points: 1.0
Use current subscription instead of active for Ramp subscriptions when downloading/copying license

### Problem

In https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3969, we updated the provisioning logic in CDot to support SM ramp subscriptions.  This involved using the `Subscription.build` method in places where licenses are provisioned like when activating a Cloud subscription or when processing a Zuora callout.  The `Subscription.build` method can build a ramped `Subscription` object with products from the current ramp interval rather than using the latest/active subscription information.  For instance, if interval 1 had a quantity of 5 and interval 3 had a quantity of 20, the license would be generated initially with a quantity of 5.

However, when downloading/copying a license from the CustomersDot Manage Subscriptions page, this Subscription is loaded without this logic, so the license will always use the active/last interval quantity (e.g. 20).  

## Proposal 
For Ramp subscriptions only, update the download/copy action for a Self Managed subscription on the `Manage Purchases` page to use the `Subscription.build` method. This will ensure only the current ramp interval is used.  

This issue is related to https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3916+ where we are considering UX changes in CDot related to ramp subscriptions.

Story points: 1.0