giseldo/neodataset huggingface dataset:
Order actions: update a product in a subscription (amendment)

<!-- 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 [other amendment actions](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4323#problem), we need a service to that creates an `orderActions` object when a [product in a subscription is updated](https://knowledgecenter.zuora.com/Billing/Subscriptions/Orders/AC_Orders_Tutorials/C_Update_a_Product_in_a_Subscription?_gl=1%2A1udimk6%2A_ga%2AMzk3MTU1OTE4LjE2NDgwNjkzODE.%2A_ga_MY8CQ650DH%2AMTY1MjkxMjQ0OC41Ny4xLjE2NTI5MTM3NTAuMA..&_ga=2.124943242.1673435247.1652906974-397155918.1648069381).

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

n the module `app/services/order_actions`, create a service class `UpdateProduct`.

The service implements the following:

* inherits `OrderActions::BaseService`
* defines `#execute` method that accepts `params`

The `#execute` method constructs `orderAction` object to add a product to a subscription, with the below parameters:
| Parameter | Type | Description |
|-----------|------|-------------|
| `type` | String | Constant value: `UpdateProduct ` |
| `triggerDates` | Array of Objects | Each object has the keys: `name` and `triggerDate`. Defines `ContractEffective`, `ServiceActivation` and `CustomerAcceptance` dates |
|`updateProduct `|Object|Defines `ratePlanId ` and `chargeOverrides` (see example payload below)|

<details>
<summary> Example request </summary>

```
{
  "type": "UpdateProduct",
  "triggerDates": [
    {
      "name": "ContractEffective",
      "triggerDate": $Today
    },
    {
      "name": "ServiceActivation",
      "triggerDate": $Today
    },
    {
      "name": "CustomerAcceptance",
      "triggerDate": $Today
    }
  ],
  "updateProduct": {
    "ratePlanId": $RPId,
    "chargeUpdates": [
      {
        "chargeNumber": $ChargeNum,
        "pricing": {
          "recurringVolume": {
            "quantity": 50
          }
        }
      }
    ]
  }
}

```

</details>

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Order actions: service to remove a product from a subscription (amendment)

<!-- 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 [other amendment actions](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4323#problem), we need a service to that creates an `orderActions` object when a [product is being removed from a subscription](https://knowledgecenter.zuora.com/Billing/Subscriptions/Orders/AC_Orders_Tutorials/D_Remove_a_Product_from_a_Subscription?_ga=2.132862094.1673435247.1652906974-397155918.1648069381&_gl=1%2Azr4393%2A_ga%2AMzk3MTU1OTE4LjE2NDgwNjkzODE.%2A_ga_MY8CQ650DH%2AMTY1MjkxMjQ0OC41Ny4wLjE2NTI5MTI0NDguMA..).

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

In the module `app/services/order_actions`, create a service class `RemovedProduct`.

The service implements the following:

* inherits `OrderActions::BaseService`
* defines `#execute` method that accepts `params`

The `#execute` method constructs `orderAction` object to add a product to a subscription, with the below parameters:

| Parameter | Type | Description |
|-----------|------|-------------|
| `type` | String | Constant value: `RemoveProduct ` |
| `triggerDates` | Array of Objects | Each object has the keys: `name` and `triggerDate`. Defines `ContractEffective`, `ServiceActivation` and `CustomerAcceptance` dates |
| `removeProduct ` | Object | Defines `ratePlanId`, the rate plan ID of the product being removed |

<details>

<summary> Example return object </summary>
{
  "orderDate": "$Today",
  "existingAccountNumber": "$AccountNum",
  "subscriptions": [
    {
      "subscriptionNumber": "$SubscriptionNum",
      "orderActions": [
        {
          "type": "RemoveProduct",
          "triggerDates": [
            {
              "name": "ContractEffective",
              "triggerDate": "$Today"
            },
            {
              "name": "ServiceActivation",
              "triggerDate": "$Today"
            },
            {
              "name": "CustomerAcceptance",
              "triggerDate": "$Today"
            }
          ],
          "removeProduct": {
            "ratePlanId": "$RPId"
          }
        }
      ]
    }
  ],
  "processingOptions": {
    "runBilling": false,
    "collectPayment": false
  }
}
</details>

### Result

The service constructs the `orderActions` object to remove a product from a subscription.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Allow validating older licenses in Admin

### Problem

During a recent incident, a [license](https://customers.gitlab.com/admin/license/20343) that was created in 2017 was validated in `/admin/license/validate_license`. The validations for a license have changed over time and now require fields like expires at, zuora subscription id or zuora subscription name to be present. 

Since this wasn't the case when the mentioned license was created, the license can not be decrypted in `/admin/license/validate_license`.

### Proposal

Allow using `/admin/license/validate_license` with older licenses that aren't decrytable as of today because of validation changes. At the moment there are two display, a green alert for a successful validation and a red one for any issues with validating the license. Add a yellow alert for licenses that aren't considered valid anymore to differentiate between an actual valid license and a license that was once considered valid.

### Result

Ability to validate older license in `/admin/license/validate_license`.

Story points: 1.0
Use order manager service in subscription controller

<!-- 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

Once we have the elements to create an order, the next step is we use it to create a new subscription. This change should be feature flagged.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

When feature flag is turned on, use  [`OrderManagerService`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4314) when creating a new subscription via the [`SubscriptionsController`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/66c2b5da4aa5a9d338c3bd2bbe1cee96933772b9/app/controllers/subscriptions_controller.rb#L80) workflow.

Marketplace changes to be handled as part of https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4526

:warning: Ensure the Subscription via Orders API workflow is enabled only when:

- Feature flag is enabled
- Not a marketplace request
- Not a preview

### Result

Orders API is used to create subscription.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Create job for Zuora Order client

<!-- 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

In CDot, Zuora actions are usually invoked as a [background job](https://gitlab.com/gitlab-org/customers-gitlab-com/-/tree/main/app/jobs/zuora/actions), as these actions make API calls to Zuora.

Once we have [Zuora::Order action](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4286) created, we can similarly add a background job that invokes the order action. 

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Create `Zuora::Actions::Order` job in `app/jobs/zuora/actions`. 

The `#perform` method has supports the following:

  - it accepts `params` argument. The argument supports keys that `IronBank::Actions::Order` accepts: `orderDate`, `existingAccountNumber`, `subscriptions` and `processingOptions`.
  - It invokes IronBank Order action `IronBank::Actions::Order.call(params)`
  - returns the result returned by IronBank Order action
  - handles appropriate exceptions

### Result

The `Zuora::Actions::Order` job is used to create orders in Zuora.

### Next steps (if any)



### How will we measure success?

Story points: 1.0
Orders: Base service

<!-- 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

The [Create Order's API](https://www.zuora.com/developer/api-reference/?_ga=2.234436310.991883880.1652218606-397155918.1648069381&_gl=1*9e5pc3*_ga*Mzk3MTU1OTE4LjE2NDgwNjkzODE.*_ga_MY8CQ650DH*MTY1MjI5OTkwOS41MC4xLjE2NTIzMDAyNzYuMA..#operation/POST_Order) supports multiple **Order operations** such as Creating a Subscription, Adding a product to a subscription, renewing a subscription and so on.

Each operation can be a separate service under module `Zuora::Orders`. The purpose of the base class is to contain shared logic of the operations. 

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Create a module `Zuora::Orders` in `app/services`. The module will be used to hold all Order operations.

Define `BaseService` in the `Zuora::Orders` module. `Zuora::Orders::BaseService` service inherits [`BaseService`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/app/services/base_service.rb).

`Zuora::Orders::BaseService` will not have any implementation code at this time however we can add logic as and when we introduce other order operations (e.g. https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4310).

Story points: 1.0
Make sure Unleash errors do not bring the application down

### Problem

See https://gitlab.com/gitlab-com/gl-infra/production/-/issues/7033#note_942314208 for full context

Part of https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/703

### Proposal

Make sure Unleash has some sort of caching that allows us to avoid any downtime in the event the communication with GitLab.com is down.

We could also question the user of Unleash if this is given us problems and explore other options.

### Result

Avoid downtime in CustomersDot due to the feature flag system being down

Story points: 3.0
Rename external id and source fields from Order to Subscription

### Problem

As [described here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4070#note_945175025), we need to modify the params and Zuora custom fields related to `External Order Id` and `External Order Source`.  It turns out an Order in Arrow is closer to what we know as a Subscription rather than Order.  This issue should cover updating the Marketplace API as well as the Ironbank schema files that reference these Zuora custom fields.

I've already engaged with Ent Apps about adding the new custom fields so that we can begin updating the IronBank schema files.

### Proposal

- [x] Update the IronBank schema files for sandbox and staging. https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4769, https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4781
   - Remove fields `ExternalOrderId__c` and `ExternalOrderSource__c`
   - Add fields `ExternalSubscriptionId__c` and `ExternalSubscriptionSource__c`
- [x] Update Marketplace API endpoint to reference new fields https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4782
- [x] Once schemas are updated, notify Ent Apps in https://gitlab.com/gitlab-com/business-technology/enterprise-apps/financeops/finance-systems/-/issues/628 that legacy custom fields can be removed from API Sandbox and Central Sandbox.
   - Notified [here](https://gitlab.com/gitlab-com/business-technology/enterprise-apps/financeops/finance-systems/-/issues/628#note_954973121)

Story points: 2.0
Remove set_super_sonics_aware_field_before_license_notification once Orders API is in use

### Problem

As described in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4185, there was a race condition where license notification was delivered to customers before the super sonics aware flag could be set on `CloudActivation`.  This was addressed in https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4702 with some additional code [in `app/workers/zuora_callback_worker.rb`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4702/diffs#bdf5b9dac21f5beca61699558db5ec40ffde85ab_164_162), `set_super_sonics_aware_field_before_license_notification`.

Something similar happened in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4513 after the release on 2022-07-07 of Strict Cloud License (SCL). When renewing and the SCL flags were not set yet, a race condition led to sending out the wrong email (unified email instead of cloud activation email). This was fixed in https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5053 with the same approach as above. To ensure this race condition isn't happening for subscriptions before the SCL release, the Super Sonics release date is used instead for the fix.

However, once CDot transitions to fully using the Orders API, we should no longer need these extra codes because all actions will be associated with one order which yields one subscription version, whereas the Amend API leading to multiple amendments and subscription versions.  The race condition should not be an issue under Orders.

### Proposal

Remove the additional code introduced in introduced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4702 and https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5053. In `app/workers/zuora_callback_worker.rb`, the methods [`set_super_sonics_aware_field_before_license_notification`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/app/workers/zuora_callback_worker.rb#L179) and [`set_super_sonics_flags_before_license_notification`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/app/workers/zuora_callback_worker.rb#L132) have to be removed. As well as the method [`renewed_after_super_sonics_released?`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/app/models/subscription.rb#L231) in the Subscription model.

This work cannot be done until CustomersDot transitions using Zuora Orders API ([epic](https://gitlab.com/groups/gitlab-org/-/epics/6438)) which is currently being planned in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4173.

Story points: 1.0
Update new logo in gitlab_login.haml

<!-- 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
New GitLab logo was updated in CustomersDot portal in #4242. However we seemed to have missed to update the `app/views/devise/sessions/gitlab_login.haml` template. 

#### Steps to reproduce

1. Create/find a user on GitLab that has not linked their account to customers-dot yet
1. Navigate to `<HOSTNAME>/subscriptions/community_program/new?edition=saas&product=oss`
1. Observe logo on the button `Continue with your GitLab.com account` to be old logo.

### Proposal
Update new logo in the above mentioned template. Also check if the logo update has been missed in any other place in CustomersDot.

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result
New logo should be visible in `app/views/devise/sessions/gitlab_login.haml` template. 

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Configure bundle on CI to disallow any changes to Gemfile.lock

This is a ~"corrective action" of sirt-2266.

This project (https://gitlab.com/gitlab-org/customers-gitlab-com) uses `bundle` or `bundle install` in CI. Per the Rubygems.org advisory, we should use either the `frozen` or `deployment` options as defense-in-depth to mitigate supply chain attacks. Most of these projects currently do not use the `frozen` or `deployment` options.

## More background

See https://github.com/rubygems/rubygems.org/security/advisories/GHSA-hccv-rwq6-vh79:

> Using Bundler in --frozen or --deployment mode in CI and during deploys, as the Bundler team has always recommended, will guarantee that your application does not silently switch to versions created using this exploit.

Note that the `deployment` option installs gems to `vendor`, which we may not want. So `frozen` will usually be the smaller change.

Note that:

> \[DEPRECATED\] The `--frozen` flag is deprecated because it relies on being remembered across bundler invocations, which bundler will no longer do in future versions. Instead please use `bundle config set --local frozen 'true'`, and stop using this flag

Story points: 2.0
Update renewal link from GitLab for community program subscription

The renewal link on group's billing page for community program subscription needs updating to redirect to community program renewal flow.

![Screen_Shot_2022-05-10_at_8.49.53_AM](/uploads/2e0090e85ebafbaac0182bc78ae71815/Screen_Shot_2022-05-10_at_8.49.53_AM.png)

The namespace renewal link (`/gitlab/namespaces/{namespace_id}/renew`) currently redirects to `/subscriptions`.

This should redirect to (`/subscriptions/community_program/{subscription_id}/renew`) instead.

Story points: 1.0
Mark coupon code as redeemed only for new CP subscription purchase and renewal

# Bug

## Summary

Changing namespace for a community subscription logs an error message `The coupon code '' was used to check out but it was unable to be marked redeemed`. This should only happen for new community program subscription and its renewal since we don't need coupon code for changing namespace or addon purchase.

[Sentry issue](https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/3291044)

## Steps to reproduce

* Change the linked namespace for an existing community program subscription with more than 1 seat in use or purchase an addon
* Check logs locally / on Slack for Staging for the above mentioned error message

## What is the current *bug* behavior?

An attempt to mark an empty coupon code is made.

## What is the expected *correct* behavior?

We shouldn't mark coupon as redeemed when changing namespace.

## Relevant logs and/or screenshots

[Sentry issue](https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/3291044)

## Bug fix proposal

Add `renewing?` check when calling `mark_coupon_redeemed` in [`amend_subscription_service.rb`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/eb8385b30405922a26e613e43777a3cea3ee4a1c/app/services/amend_subscription_service.rb#L40)

Story points: 1.0
Frontend validation against emoji customers info during registration

### 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. Create a new account on Gitlab
3. Navigate to CustomersDot and select `sign in with Gitlab`
4. Fill out the details to register for a customers dot account, and add an emoji to the first name
5. Create a group on GitLab and navigate to billing
6. Select a plan, fill out the details and submit the purchase
7. There is an `UNKNOWN_ERROR` message

<img src="/uploads/5901d4353e4af31417b9a499a1a3d103/CleanShot_2022-05-09_at_14.54.59.png" width='500px' />

#### Workaround

Once the emoji is removed from the name on the CustomersDot account, the purchase completes successfully.

### Proposal

For the [registration form](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/3096d7e4915b7e0f8450426fa0bcd352314a8677/app/frontend/javascripts/sessions/components/register_form.vue), it should be sufficient to use the `state` and `invalid-feedback` props for form/groups (see example [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/3096d7e4915b7e0f8450426fa0bcd352314a8677/app/frontend/javascripts/subscription/components/coupon_code_input.vue)).

The fields to validate against the presence of emoji are:

- first_name
- last_name
- city
- zip_code (postal_code)
- company

| Description | MR |
|-|-|
| Promote `emoji-regex` to a npm `dependency` | gitlab-org/customers-gitlab-com!4845 |
| Add validation to customer registration form (first and last name) | gitlab-org/customers-gitlab-com!4852 |
| Validate customer registration form (company and address fields) | gitlab-org/customers-gitlab-com!4887 |

Story points: 3.0