giseldo/neodataset huggingface dataset:
Handle seat overage notification unable to find subscription

See https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/3239505/?referrer=gitlab_plugin

## Summary

When seat overage notification is triggered, a small number of these causes error because subscription cannot be found.

Taking subscription `A-S00010110` as an example, due to its `order.customer.zuora_account_id` being nil, the `order.current_subscription` will also return nil. This caused the exception. (p.s. `order.zuora_account_id` is present though).

We will need to investigate

1. if this is a purely random data integrity
1. if this can be recovered, or should be properly ignored

This is currently not severe, because mailing operation is new and is stopped half-way through, therefore no customer is being affected.

Story points: 2.0
Create CloudActivation record immediately as part of web direct purchase

### Problem

An activation code for SM subscriptions are found in the `CloudActivation` model with a matching `subscription_name`.  These records much be created in order for the activation code to be shown in CustomersDot for a cloud licensing capable SM subscription.  

Currently, the `CloudActivation` record is created [when processing the Zuora callout](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/16e4f22fab6a4dfddfcff6f318241c2e67281b8d/app/workers/zuora_callback_worker.rb#L24) after a purchase/update is processed in Zuora. We've found at times there is a noticeable delay between the time of purchase and the time the callout is processed.  This could be because of a delay in Zuora sending the callout or a delay in CustomersDot processing it.  

When this happens, the customer sees the license file as the only method for activating their subscription, until the callout can be processed.

### Proposal

It would be better to create the `CloudActivation` as part of the initial purchase in the `SubscriptionsController`, [similar to how an order is created](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/343aa1c9ae880946b2aff53ed8c3a71628d0318a/app/controllers/subscriptions_controller.rb#L260).  This will ensure the activation code is present immediately after purchase.

Story points: 1.0
Create new feature flag for Community Program Renewals

Currently we use `community_program_coupons` for both new purchase and renewal flows for community program subscription.

With new flow going live on March 21st, we should create a new feature flag so we can make these 2 features go live independently.

We could create a flag called something like `community_program_renewals` for renewals flow.

[Feature flags](https://docs.gitlab.com/ee/operations/feature_flags.html)

We should also update the renewal routes to [check](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/app/controllers/subscriptions/community_program_controller.rb#L5) for this new feature flag instead. We should make sure we check for `community_program_coupons` for new flow as it is now.

Story points: 1.0
Customizations to FindOrCreateCustomerService for E-Disty

### Background

Provide the ability for GitLab authorized resellers to leverage Distribution e-marketplaces (like Arrowsphere) to purchase GitLab subscriptions in order to accelerate channel business and enable low/no touch orders.

This will be accomplished by building an automated end-to-end solution where a partner can purchase GitLab from our authorized distributors using an e-marketplace and receive the product “immediately” after submitting their order. In doing so, ensure data is captured and tracked accurately through all relevant GitLab systems/applications (Salesforce, Zuora, CustomersDot, Stripe, etc.).

Issues in this epic are focused on building the new API endpoint to support:
- Customer creation
- Zuora Subscription creation
- Creation of SFDC Account, Opportunity, etc
- License provisioning

References:
- [E-Disty: Data mapping spreadsheet](https://docs.google.com/spreadsheets/d/138UqGiYfGc8A4HyBin6JrsRelmjfGbqvg3UZ0nJaLTU/edit#gid=0)

### Proposal

In https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4079+, a new service was created that will create a customer (via `FindOrCreateCustomerService`) and a Zuora subscription (via `SubscriptionManagerService`).  These services must be customized to create these objects as desired for the E-Disty workflow.

In this issue, the `FindOrCreateCustomerService`, may need to be modified to support creating a customer from an E-Disty marketplace (Arrowsphere) order.  The existing classes were built with only the web-direct scenario in mind, but these will need to be extended to support E-Disty marketplace.  

For example, we know that customers created through this workflow do not need login access to CustomersDot and should not receive a welcome email.  This service created in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4079 should be able to call the `FindOrCreateCustomerService` such that it creates a customer with customer where `login_activated` and `billable` attributes are false.

Reference [the data mapping spreadsheet](https://docs.google.com/spreadsheets/d/138UqGiYfGc8A4HyBin6JrsRelmjfGbqvg3UZ0nJaLTU/edit#gid=0) to see the full list of fields from Platypus and how they should map to the Customer Model in CDot.

Story points: 2.0
Customizations to SubscriptionManagerService for E-Disty

### Background

Provide the ability for GitLab authorized resellers to leverage Distribution e-marketplaces (like Arrowsphere) to purchase GitLab subscriptions in order to accelerate channel business and enable low/no touch orders.

This will be accomplished by building an automated end-to-end solution where a partner can purchase GitLab from our authorized distributors using an e-marketplace and receive the product “immediately” after submitting their order. In doing so, ensure data is captured and tracked accurately through all relevant GitLab systems/applications (Salesforce, Zuora, CustomersDot, Stripe, etc.).

Issues in this epic are focused on building the new API endpoint to support:
- Customer creation
- Zuora Subscription creation
- Creation of SFDC Account, Opportunity, etc
- License provisioning

References:
- [E-Disty: Data mapping spreadsheet](https://docs.google.com/spreadsheets/d/138UqGiYfGc8A4HyBin6JrsRelmjfGbqvg3UZ0nJaLTU/edit#gid=0)

### Proposal

In https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4079+, a new service was created that will create a customer (via `FindOrCreateCustomerService`) and a Zuora subscription (via `SubscriptionManagerService`).  These services must be customized to create these objects as desired for the E-Disty workflow.

In this issue, the `SubscriptionManagerService`, and related classes, will need to be modified to support creating a subscription from an E-Disty marketplace (Arrowsphere) order.  The existing classes were built with only the web-direct scenario in mind, but these will need to be extended to support E-Disty marketplace.  For example, the `SubscribeService` uses some constants that only apply to web-direct use cases like [`TERM_DURATION_IN_MONTHS`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/dd52c9e8d03de2d44cdf87725d3c7564f98c8625/app/services/subscribe_service.rb#L8) and [`DEFAULT_BILLING_BATCH`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/dd52c9e8d03de2d44cdf87725d3c7564f98c8625/app/services/subscribe_service.rb#L10).

Here are some of the other areas that will need to be modified:
  - External Order Source
  - External Order Id
  - Payment Term
  - Billing Batch
  - Subscribe Options -> Process Payments
  - Payment Method Id (not needed)
  - Subscription Custom Fields (Super Sonics fields)
  - Invoice Owner Id

Reference the [data mapping spreadsheet](https://docs.google.com/spreadsheets/d/138UqGiYfGc8A4HyBin6JrsRelmjfGbqvg3UZ0nJaLTU/edit#gid=0) to ensure we capture all the required customizations.

Story points: 3.0
Incorporate customer/subscription service into new API controller

### Background

Provide the ability for GitLab authorized resellers to leverage Distribution e-marketplaces (like Arrowsphere) to purchase GitLab subscriptions in order to accelerate channel business and enable low/no touch orders.

This will be accomplished by building an automated end-to-end solution where a partner can purchase GitLab from our authorized distributors using an e-marketplace and receive the product “immediately” after submitting their order. In doing so, ensure data is captured and tracked accurately through all relevant GitLab systems/applications (Salesforce, Zuora, CustomersDot, Stripe, etc.).

Issues in this epic are focused on building the new API endpoint to support:
- Customer creation
- Zuora Subscription creation
- Creation of SFDC Account, Opportunity, etc
- License provisioning

References:
- [E-Disty: Data mapping spreadsheet](https://docs.google.com/spreadsheets/d/138UqGiYfGc8A4HyBin6JrsRelmjfGbqvg3UZ0nJaLTU/edit#gid=0)

### Proposal

Call the service that creates the customer and subscription (introduced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4079) from the new marketplace subscription create API endpoint (introduced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4078).  ~~This will likely involve transforming the request params in the action into the form that the service expects. Reference the data mapping spreadsheet to determine how parameters map to the CustomersDot data model and Zuora Subscribe API request.~~

We should confirm with Ent Apps what kind of response code and body are expected for both success and error.

Story points: 3.0
Build service to invoke other services (create customer, subscription, and salesforce objects)

### Background

Provide the ability for GitLab authorized resellers to leverage Distribution e-marketplaces (like Arrowsphere) to purchase GitLab subscriptions in order to accelerate channel business and enable low/no touch orders.

This will be accomplished by building an automated end-to-end solution where a partner can purchase GitLab from our authorized distributors using an e-marketplace and receive the product “immediately” after submitting their order. In doing so, ensure data is captured and tracked accurately through all relevant GitLab systems/applications (Salesforce, Zuora, CustomersDot, Stripe, etc.).

Issues in this epic are focused on building the new API endpoint to support:
- Customer creation
- Zuora Subscription creation
- Creation of SFDC Account, Opportunity, etc
- License provisioning

References:
- [E-Disty: Data mapping spreadsheet](https://docs.google.com/spreadsheets/d/138UqGiYfGc8A4HyBin6JrsRelmjfGbqvg3UZ0nJaLTU/edit#gid=0)

### Proposal

Build a new service that is responsible for:
- Creating a customer record, likely utilizing [the existing `FindOrCreateCustomerService`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/0abb2c47962048af373ccec20cdf74b55252dce4/app/services/find_or_create_customer_service.rb#L3)
- Calling [the `SubscriptionManagerService`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/49d0aeae5ed9b8066078bc8ab2ae31fd629eefcf/app/services/subscription_manager_service.rb#L3) to create the Zuora subscription and SFDC objects

This issue can focus on a simple approach where the service accepts a quantity, plan_id, and other parameters that are already supported by the underlying Customer and Subscription services.  This issue should not cover the customizations which will be necessary for the full E-Disty workflow.  We can look at [the `SubscriptionsController#create` action](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/343aa1c9ae880946b2aff53ed8c3a71628d0318a/app/controllers/subscriptions_controller.rb#L80) for examples of the parameters that can be passed to the `SubscriptionManagerService` currently.  We should consider wrapping the elements of this new service into a transaction so that transactions can be atomic.

This service will eventually be called from the new API endpoint introduced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4078+.

Story points: 3.0
Build marketplace subscription creation API skeleton

### Background

Provide the ability for GitLab authorized resellers to leverage Distribution e-marketplaces (like Arrowsphere) to purchase GitLab subscriptions in order to accelerate channel business and enable low/no touch orders.

This will be accomplished by building an automated end-to-end solution where a partner can purchase GitLab from our authorized distributors using an e-marketplace and receive the product “immediately” after submitting their order. In doing so, ensure data is captured and tracked accurately through all relevant GitLab systems/applications (Salesforce, Zuora, CustomersDot, Stripe, etc.).

Issues in this epic are focused on building the new API endpoint to support:
- Customer creation
- Zuora Subscription creation
- Creation of SFDC Account, Opportunity, etc
- License provisioning

References:
- [E-Disty: Data mapping spreadsheet](https://docs.google.com/spreadsheets/d/138UqGiYfGc8A4HyBin6JrsRelmjfGbqvg3UZ0nJaLTU/edit#gid=0)

### Proposal

Build the skeleton for the new, RESTful API endpoint that will eventually support creation of objects mentioned above.  This endpoint will be used by distribution e-marketplaces, the first example being Arrowsphere.  

We could build this new endpoint similar to existing controllers that use admin token authentication like [`Api::V1::LicensesController`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/11fe580936f339405a14254ea1fd4131f3fb6561/app/controllers/api/v1/licenses_controller.rb#L6) and [`Api::CustomersController`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/114b87e77e1529f7f6d25bea4b72096463e57f96/app/controllers/api/customers_controller.rb#L5).  Since this endpoint is intended to be consumed by e-marketplaces via Platypus, the controller could be named something like `Api::V1::Marketplace::SubscriptionsController` or `Api::V1::Platypus::SubscriptionsController`?

For this issue, we can focus on permitting the request params and returning an empty, successful response.

Story points: 2.0
Zuora Configuration for Arrowsphere orders

### Summary

This issue will capture the configuration changes required to support Arrow orders. Once approved, the changes will be done by EntApps team.

### Proposed changes

> [Distributor e-Marketplace: FinSys Requests](https://gitlab.com/groups/gitlab-com/business-technology/enterprise-apps/financeops/-/epics/16) epic

- [x] Create custom fields on Zuora Subscription to track Arrow order ([FinSys issue](https://gitlab.com/gitlab-com/business-technology/enterprise-apps/financeops/finance-systems/-/issues/628#note_911837751))
   - [x] ~~`External Order Source`~~
   - [x] ~~`External Order Id`~~
   - [x] `External Subscription Source`
   - [x] `External Subscription Id`
- [x] Create `Net 30 EOM` Payment Term ([FinSys Issue](https://gitlab.com/gitlab-com/business-technology/enterprise-apps/financeops/finance-systems/-/issues/675))
- [x] New Billing Batch + Automated Bill Run for Arrowsphere Orders ([FinSys Issue](https://gitlab.com/gitlab-com/business-technology/enterprise-apps/financeops/finance-systems/-/issues/676))
- [x] Create new Arrow invoice template ([FinSys issue](https://gitlab.com/gitlab-com/business-technology/enterprise-apps/financeops/finance-systems/-/issues/774))
- [x] Send Arrow invoices in bulk ([FinSys issue](https://gitlab.com/gitlab-com/business-technology/enterprise-apps/financeops/finance-systems/-/issues/777))
- [ ] New Arrow communication profile ([FinSys issue](https://gitlab.com/gitlab-com/business-technology/enterprise-apps/financeops/finance-systems/-/issues/783))

Story points: 0.0
Move user count logic from haml template to helper

<!-- 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/

-->
### Current Status
Code was moved to a [presenter](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5840), but introduced a [bug with Renewals](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5245). Before merging the [follow up MR](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6015) that un-reverts [the initial MR](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5840), we need solid reproduction steps of the [500 bug](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5245) to validate that the bug is not reintroduced.

### Previous Description
> #### Problem
> As suggested in this [comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4372#note_865226482), it would be a good idea to move the logic block in `subscriptions/community_program/renew_subscription.html.haml` into a helper. With this we would get the additional advantage of being tested. The same helper could be used for `subscriptions/renew.html.haml`(https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/app/views/subscriptions/renew.html.haml#L1-17) too as it has similar logic.
>  
> #### Proposal
> Move the logic block as suggested in this [comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4372#note_865226482) in `subscriptions/community_program/renew_subscription.html.haml` to a helper. Use this helper for `subscriptions/renew.html.haml`(https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/app/views/subscriptions/renew.html.haml#L1-17) too as it has similar logic.
> 
> <!-- 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)
> - Create helper.
> - Use helper in `subscriptions/community_program/renew_subscription.html.haml` and `subscriptions/renew.html.haml`(https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/app/views/subscriptions/renew.html.haml#L1-17).
> - Add relevant tests. 

### How will we measure success?
Users are able to successfully renew subscriptions

Story points: 2.0
Extend vue wrapper to have findByTestId helper

Currently to be able to find an element using `data-testid` for assertions, we declare `findByTestId` helper in each spec file and use it in tests.

Created as a [follow up](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4414#note_864946955)

**Proposal**

We can extend the wrapper to have `findByTestId` similar to how we do it in [`gitlab`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/frontend/__helpers__/vue_test_utils_helper.js), make `shallowMountExtended` and `mountExtended` helpers that use the `extendedWrapper`. We can then replace all `findByTestId` declarations with `shallowMountExtended` or `mountExtended` or just `extendedWrapper` in spec files

Story points: 2.0
Add presence validation for activated_at in SelfManagedInstanceActivation

### Problem

In https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4418#note_862077160, a discussion about the possibility of the `activated_at` timestamp for `SelfManagedInstanceActivation` being `nil`. Looking at the current code, the value will always be present (code when [creating](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/dded5fcb0654a9af94b78c3153b4acadb1e5e60d/app/services/cloud_activations/activate_service.rb#L43) and [updating](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/dded5fcb0654a9af94b78c3153b4acadb1e5e60d/app/services/cloud_activations/activate_service.rb#L19) the `SelfManagedInstanceActivation`). Despite of that, in https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4418#note_863466271, the suggestion was made to add a presence validation for `activated_at`.

### Proposal

Add a presence validation for `activated_at` in the `SelfManagedInstanceActivation` model to ensure the field always has a value.

### Result

Additional safety to ensure the field will always have a value.

### Availability & Testing

<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.

What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?

Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change

See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning -->

Associated with this change, should be a model spec update of `self_managed_instance_activation_spec.rb` to accommodate the new presence validation.  (`it { is_expected.to validate_presence_of(:activated_at) }`)

Story points: 1.0
Spike: Evaluate clearer error messages when activating cloud license

### Problem

Errors occurring during activation of a cloud license are not clear enough what the reason for the error is. In https://gitlab.com/gitlab-org/gitlab/-/issues/346461, a misleading message about a connectivity error showed up when trying to activate a cancelled subscription. The error was actually a no method error when the license was built (via the [SeatLinkCreateService](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/7d14b53ed8df3fe8f996a992ca3e060f0bc8b430/app/services/seat_link_create_service.rb#L181)) because the subscription couldn't be found. With the fix for this, the new error message will be the general "an error occurred while activating your subscription" error.

### Proposal

While [discussing](https://gitlab.com/gitlab-org/gitlab/-/issues/346461#note_863397425) the fix for the mentioned error with Support, it came up to improve the error reporting when activating a cloud license. Hence, this spike issue to take a closer look into how that might be possible. The errors will come from different code places (e.g. Zuora subscription, license creation, seat link creation, etc.) and have to be returned to the [ActivationService](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/dded5fcb0654a9af94b78c3153b4acadb1e5e60d/app/services/cloud_activations/activate_service.rb#L25-28) and its [graphql mutation](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/1b4516ee084d478c139cfd55bf3180ad9dc804dc/app/graphql/mutations/cloud_activations/activate.rb#L29).

### Result

A clearer error message on where something went wrong when activating a cloud license.

### Availability & Testing

<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.

What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?

Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change

See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning -->

Tests should accompany this change to ensure that whatever error is received, is rendered properly on the frontend.

Story points: 3.0