giseldo/neodataset huggingface dataset:
Add ability to use Zuora Data Query

### Problem

The [gem `iron_bank`](https://github.com/zendesk/iron_bank/) that we use as a third party tool to connect CustomersDot to Zuora doesn't support complex query (like joining two data models). To find eligible subscriptions in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4405+, we need to use a complex query. The query will use the `Subscription` as the main data model and join the `Account` and `Contact` data models to get to the data we need for the mentioned issue (to send reminder emails to instance admin/sold to contacts of a subscription).

With IronBank that isn't possible, but with [Zuora's Data Query](https://apisandbox.zuora.com/platform/data-query), this can be achieved (also see [API docs](https://www.zuora.com/developer/api-reference/#tag/Data-Queries)).

One thing to note is that Data Query is async and will not return the result directly.

### Proposal

Add the ability to use Zuora's Data Query.

### Result

The complex query needed for https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4405 can be done with the help of Zuora Data Query.

Story points: 3.0
Staging sanity of CustomersDot application - CI Decomposition

<!-- 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/

-->

As mentioned in https://gitlab.com/gitlab-org/gitlab/-/issues/365739, we need to perform a sanity testing of the functionality for CustomersDot application.

Story points: 1.0
Remove discount alerts for deprecated subscriptions

### Problem

We have alerts in our code base that we show we customer **upgrades to** the deprecated subscription type (Bronze/Silver/Gold/Starter) that are eligible for discounts. Right now there is no valid case when we should show it (see [internal slack thread](url)).

`"Don't miss out on your exclusive deal"` alerts should be safe to remove now, the renewal form is already a complex component and we should keep it clean.

| SelfManaged | SaaS |
| ------ | ------ |
| ![Screenshot_2022-06-20_at_15.10.38](/uploads/bb6a56644729ccd35f5cc9463dcf6eba/Screenshot_2022-06-20_at_15.10.38.png) | ![Screen_Shot_2020-12-23_at_16.15.55](/uploads/6580d8e7b162a22adb484fe9cd57be83/Screen_Shot_2020-12-23_at_16.15.55.png) |

### Proposal

Remove the alerts from the source code.

Story points: 1.0
New account data for 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

When creating a new order, the account details can be provided by specifying either of the two attributes: `existingAccountNumber` or `newAccount`.

As the name suggests, `existingAccountNumber` is used for an existing account, and `newAccount` for a new account.

While OrderManagerService currently supports pass the [`existingAccountNumber`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/618359c09943f0c8716ad277b6c546562c103d40/app/services/zuora/orders/order_manager_service.rb#L40), we need a mechanism to send the `newAccount` object for new customers.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Create an entity that constructs account object. It should return existing or new data based on whether the customer has an account or not.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Add fields to GraphQL API to support community program management in GitLab

### Problem

This is foundational work for https://gitlab.com/gitlab-org/gitlab/-/issues/363439+ and https://gitlab.com/gitlab-org/gitlab/-/issues/363440+.

We need to know what date a subscription is eligible for renewal from and whether or not the subscription can have seats added to it so that we can show the correct UI to the user, at the correct time for self managing their subscriptions in GitLab.

Currently this information is hard-coded in the GitLab codebase, but with the introduction of community programs, the renewal dates are different and not all subscriptions are eligible to have their seat count modified.

### Proposal

Update the [`SubscriptionType`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/a56a94813b677713d9f8c43e320ca06cd3314c3f/app/graphql/types/subscription_type.rb) to have the attributes `enable_renew_from: Date` and `can_add_seats: Boolean` in the response.

- `enableRenewFrom` should have the same behaviour as [the method on `Subscription`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/a56a94813b677713d9f8c43e320ca06cd3314c3f/app/models/subscription.rb#L684)
- `canAddSeats` should be `false` for community program subscriptions (and `true` for all others?)

More discussion in planning issue here: https://gitlab.com/gitlab-org/gitlab/-/issues/363537

### Result

These attributes are available on the `SubscriptionType` in the CustomersDot GraphQL API.

Story points: 3.0
More customizations when creating marketplace subscriptions

### Background

We found out in [this thread](https://gitlab.com/groups/gitlab-org/-/epics/6873#note_993065034) that more customizations are needed when creating accounts and subscriptions in the Marketplace API in CDot.

### Proposal

The following 3 customizations are needed.  As I understand it, these fields will be static for all Marketplace orders.

#### 1. `IsInvoiceSeparate = TRUE`

All Arrow subscriptions should be invoiced separately (e.g. `IsInvoiceSeparate` = `true`). The default setting for `IsInvoiceSeparate` = `false` for subscriptions. However, in order to ensure that we have a 1:1 relationship between subscription and invoice, we will need this setting set to `true`.  

The `IsInvoiceSeparate` attribute can be passed in the subscribe request body as seen in [the Zuora docs](https://www.zuora.com/developer/api-reference/#operation/Action_POSTsubscribe).  This will be set in the request body where `request_body['subscribes'][0]['SubscriptionData]['Subscription']['IsInvoiceSeparate']` is `TRUE` .

#### 2. `SSPChannel__c = "Reseller"`

SSP Channel should be set as `Reseller` for the Arrow account in Zuora as well as all end user accounts.  This means setting `SSPChannel__c` to "Reseller" for accounts created in the subscribe request.

This field has not be set in the `SubscribeService` before and may require a change to the IronBank schema.

#### 3. `Entity__c`

> Entity MUST be the same on all end user and Arrow account (if Arrow is US end user must be US) - this is a revenue requirement

We don't currently set `Entity__c` when creating accounts as part of the subscribe request so this will be a new attribute to set in the request.  As per [this comment](https://gitlab.com/groups/gitlab-org/-/epics/6873#note_993248300), this attribute should be set to `"US"` for all Arrow orders.  ~~It's not clear yet whether this applies to all Marketplace orders or just Arrow.  We've [asked about this below](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4430#note_995757617), as it may impact where the default lives; a) in Platypus, then passed to CDot in the marketplace request, OR 2) in CDot for all marketplace orders.~~

~~**Update**: per [comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4430#note_995956944), we hope to have the `Entity__c` value passed through the Marketplace API request from Platypus.~~

**Update again**: per [comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4430#note_1000132233), we will set `Entity__c = "US"` for all Marketplace orders in this iteration.

Story points: 2.0
CI min subscriptions have subscription management buttons on CustomersDot

# Bug

## Summary

Subscriptions that have CI minutes only are not renewable nor upgradable but the `Upgrade plan`, `Resume subscription`, `Buy more CI minutes`, `Buy more storage` buttons are visible on the active CI minutes subscriptions in CustomersDot. The expired ones do not have the `Resume subscription` button.

## What is the expected *correct* behavior?

It should not have any subscription management buttons

## Relevant logs and/or screenshots

An example of an account that has both expired and active CI minutes subscription is [210330 (internal)](https://customers.gitlab.com/admin/customer/210330/)

![Screenshot_2022-06-15_at_19.59.44](/uploads/64f97217cf5280015dbdb9bd5ea115f6/Screenshot_2022-06-15_at_19.59.44.png)

## Workarounds

(Ways to get around the issue)

## Reported examples

1.
1.
1.

## Implementation plan
| Scenario | MR |
| ------ | ------ |
| :one: Hide `Cancel / Resume subscription` button for addon only plans | https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5390 |
| :two: Move amend or create decision for addons to backend  | https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5402 |
| :three: Hide subscription management buttons for CI minutes subscriptions which are not linked to a namespace | https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5450 |

<!---
Please add both severity and priority level according to: https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#severity-labels
--->

Story points: 3.0
Update CSS in repo to hide the inline submit button in zuora iframe

<!-- 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 https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4250+, we [decided](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4250#note_945133329) that we would be taking the [one button approach](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4250#-one-button-ob) i.e. hide the internal iframe button and always shown an external button. This is currently behind the feature flag `zuora_hpm_no_refresh`. To achieve this, along with enabling the feature flag, we will also be disabling the internal iframe submit button through Zuora CSS.


### Proposal
1. Update the existing CSS (we can probably get the existing CSS from finance team or check if we have it tracked in our repo) to hide the zuora inline submit button. (Add `display: none` on class `.btn-submit.btn-submit` and remove existing CSS on `.btn-submit.btn-submit`)
2. Add the Zuora HPM id (both staging and production) and the new CSS to be updated in this [issue](https://gitlab.com/gitlab-com/business-technology/enterprise-apps/financeops/finance-systems/-/issues/791) description.
3. If this CSS is not being tracked in the repo currently, consider adding it with the appropriate naming convention (e.g. the id from [secrets](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/config/secrets.yml.example#L91)).   

_Note: We currently have 2 css files ([style.css](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/vendor/zuora/css/style.css) and [hpm2.css](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/vendor/zuora/css/hpm2.css)) being tracked in our repo. Need to confirm which HPM these styles are for. Updating the CSS file names with a clearer naming convention might help in identifying the correct HPM going ahead._

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result
We need to update the Zuora HPM id (staging and production) and the updated CSS to hide inline submit button in Zuora iframe in this [issue](https://gitlab.com/gitlab-com/business-technology/enterprise-apps/financeops/finance-systems/-/issues/791) description.  
We need to mention in this issue that we need to finalise on a date and time so as to sync the Zuora CSS update and enabling the feature flag `zuora_hpm_no_refresh`. Read this [discussion](https://gitlab.com/groups/gitlab-org/-/epics/7969#note_992473878) for more context on why this is needed.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Add new feature flag to show add new payment method page under maintenance mode

<!-- 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 https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4250+, we [decided](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4250#note_945133329) that we would be taking the [one button approach](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4250#-one-button-ob) i.e. hide the internal iframe button and always shown an external button. This is currently behind the feature flag `zuora_hpm_no_refresh`. To achieve this, along with enabling the feature flag, we will also be disabling the internal iframe submit button through Zuora CSS.

However we would have a problem in syncing the two operations - enabling the `zuora_no_hpm_refresh` feature flag and the zuora css update (since the CSS update will be done by finance systems team through an issue). If we enable `zuora_no_hpm_refresh` and then update the Zuora CSS, we will see 2 buttons for the time duration we take between the 2 updates. If we update Zuora CSS first and then the feature flag, then we will see no buttons in the time duration we take between the 2 updates. This will only affect the `Add new payment method` functionality since currently that is the only implementation where we are using the internal iframe button.  

### Proposal
1. Introduce a feature flag `add_new_payment_method_maintenance_mode`.  
2. Make code changes to show `Maintenance mode` message when feature flag is enabled and not to allow users to use the `Add new payment` page.

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result
`Maintenance mode` message should be shown when `add_new_payment_method_maintenance_mode` feature flag is enabled.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Implement one button approach in new_payment_method.vue

<!-- 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 https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4250+, we [decided](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4250#note_945133329) that we would be taking the [one button approach](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4250#-one-button-ob) i.e. hide the internal iframe button and always shown an external button.  

This is currently behind the feature flag `zuora_hpm_no_refresh`. To achieve this along with enabling the feature flag, we will also be disabling the internal iframe submit button through Zuora CSS. However since the Zuora CSS will be common across all places where this Zuora iframe is used, we need to implement the one button approach in [new_payment_method.vue](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/main/app/frontend/javascripts/payment_methods/components/new_payment_method.vue) too.


### Proposal
Implement a similar one button approach as suggested [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4250#-one-button-ob). Currently [new_payment_method.vue](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/main/app/frontend/javascripts/payment_methods/components/new_payment_method.vue) doesn't have an external button since it uses the `inline-submit` methodology on the old [zuora_new_credit_card_form.vue](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/main/app/frontend/javascripts/payment_methods/components/new_payment_method.vue#L89). We need to introduce a button which will work with the new [zuora_static_credit_card_form.vue](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/main/app/frontend/javascripts/payment_methods/components/new_payment_method.vue#L88).  
Reference: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4862/diffs  

_**Note:** When testing with `zuora_no_hpm_refresh` FF enabled, we would need to update the Zuora CSS (from Zuora apisandbox portal) under the [hosted page's](https://apisandbox.zuora.com/apps/HostedPageLite.do?method=list) CSS field.  
Copy CSS from this file and update in Zuora hosted page's CSS field - [style.css](/uploads/b0fca3bb14f102d72d86dedfe1acdef2/style.css)_.  
_This is only for testing purposes. Do not use this CSS for production._


<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result
The add new payment method flow (which uses `new_payment_method.vue`) should work fine with `zuora_np_hpm_refresh` flag enabled and disabled.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Implement one button approach in subscription_renew_form.vue

<!-- 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 https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4250+, we [decided](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4250#note_945133329) that we would be taking the [one button approach](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4250#-one-button-ob) i.e. hide the internal iframe button and always shown an external button.  

This is currently behind the feature flag `zuora_hpm_no_refresh`. To achieve this along with enabling the feature flag, we will also be disabling the internal iframe submit button through Zuora CSS. However since the Zuora CSS will be common across all places where this Zuora iframe is used, we need to implement the one button approach in [subscription_renew_form.vue](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/main/app/frontend/javascripts/subscription/components/subscription_renew_form.vue#L472-482) too.


### Proposal
Implement a similar one button approach as suggested [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4250#-one-button-ob).  
Reference: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4862/diffs  

_**Note:** When testing with `zuora_no_hpm_refresh` FF enabled, we would need to update the Zuora CSS (from Zuora apisandbox portal) under the [hosted page's](https://apisandbox.zuora.com/apps/HostedPageLite.do?method=list) CSS field.  
Copy CSS from this file and update in Zuora hosted page's CSS field - [style.css](/uploads/b0fca3bb14f102d72d86dedfe1acdef2/style.css)_  
_This is only for testing purposes. Do not use this CSS for production._

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result
The SM renewal flow (which uses `subscription_renew_form.vue`) should work fine with `zuora_np_hpm_refresh` flag enabled and disabled.

### Next steps (if any)

### How will we measure success?

Story points: 3.0
Refactor customer registration emoji validation

We recently introduced validation against emojis on the ~frontend. During the implementation of , we realised it would've been less tedious work to already abstract the validation logic (gitlab-org/customers-gitlab-com!5006), in order to reduce the amount of later refactoring. We later introduced [`VeeValidate`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5017/diffs) to do the heavy lifting for custom form validation.

This issue has been changed from abstracting the logic to refactoring the validation for the customer sign-up / registration page.

Discussion for approach for custom validation - https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4644

### Proposed solution

- Apply VeeValidate similar to how we do it for [customer details edit](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/app/frontend/javascripts/account/components/personal_details.vue#L22)
- Delete all [emoji-specific](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/7afd8712efc24d889dde3487f2db25110b9f94d4/app/frontend/javascripts/sessions/sessions_constants.js#L9) logic

| Description | MR|
|-|-|
| Refactor customer registration emoji validation | _tbd_ |

Story points: 2.0
Rate plan for new subscription - 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

When a user purchases a new subscription, it includes the product and the number of quantity they wish to subscribe to.

In the Subscribe API, this information was captured in [rate_plan_data](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/app/services/subscribe_service.rb#L154) attribute. It included details of the main and optional plan.

We need a way to capture this information when creating a new subscription through the Orders API.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

The [Order action `createSubscription`](https://www.zuora.com/developer/api-reference/#operation/POST_Order) has a `subscribeToRatePlans` object. It holds the list of rate plans associated with the subscription.

Use the object to pass the rate plans a user subscribes to.

### Result

The selected plan and quantity gets reflects in the new order / subscription created.

### Next steps (if any)

### How will we measure success?

Story points: 2.0