giseldo/neodataset huggingface dataset:
Provide the ability in CustomerDot to send a cloud activation code to another account

[[_TOC_]]

## Step 1: Describe what this request is about by answering the following questions

### What is the problem/opportunity?  

Currently, in CustomerDot it is only possible to send a cloud activation code to the account owner. As shown below:

![image](/uploads/0fdf44b7bdc349f621367210a72fa5e8/image.png)

![image](/uploads/80ce6c24028fc7bd256d5c5e27596018/image.png)

However, it is possible to forward a license file to another account

![image](/uploads/d43104b38e2113e346b7550189bc715b/image.png)


This problem was exposed by a customer in a [zendesk ticket](https://gitlab.zendesk.com/agent/tickets/310143) when the account owner was on vacation and the other users did not have access to GitLab as a result. 

### Who is it for?

       1. External: SM customers


### Why is this important?

It is important that CustomerDot provides the parity of functionality for Cloud Licensing Activation Codes that it does for Offline/legacy licenses 

### How do you propose we solve for it?

Create forward license activation code functionality


### What does success look like, and how can we measure that?

CustomerDot provides the ability to send the Activation Code to another email

## Proposal
Implement the same process used today by legacy licenses.

### 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 -->

We will need to create many lower-level tests including, but not limited to:

- Unit specs
- Controller specs
- Jest specs
- Email validity
- Likely Model validation specs(?) [are we validating email via the model, controller?]
- Feature specs
- Mailer specs(?) [test that the email has indeed been sent to the appropriate email]

Other things to consider:

- When the customer adds a new email, are we saving this email somewhere, so it can be sent later from a list of valid emails?
- What email validation regex are we going to be using? Will this validation regex allow wildcard emails? (e.g.: ddavison+fulfillment[at]gitlab.com)

Story points: 3.0
Order should be rejected if an existing customer tries to purchase through Arrow

### Problem

We identified when discussing the [scorecard for UAT](https://docs.google.com/spreadsheets/d/1innM5QJP11Cc_0yuejYCkgyFqWrsuShgMG_pG-iN43s/edit#gid=0) as a group that orders need to be rejected when an existing customer attempts to make a purchase through Arrowsphere.  There are a few reasons for this:

1. We don't want to allow existing Customers with access to the Customer Portal to be able to make a purchase via Arrowsphere and allow them to manage their subscription through the Portal.
2. Customers may be looking to make adjustments to existing subscriptions through Arrowsphere by mistake.  By preventing this action, we are saving some headache and directing them to the sales-assisted route.

### Proposal

If a Customer record already exists, reject a subscription from being created through the marketplace subscriptions API.

We got clarification from the team that CustomersDot should block an Order if a Customer record exists with the email address (Sold To) and has an associated Zuora Account.  That means even if the Customer record was created through an earlier Arrowsphere order, it will still be rejected.

Story points: 1.0
Refactor SubscriptionSerializer in License creation

This is a refactoring suggestion to merge `SubscriptionSerializer` with `License` model.

`SubscriptionSerializer` was originally created to serialize Zuora callback data so we can send it to LicenseApp for creating a license.

LicenseDot is now merged with CDot, so its only usage is in `License#build_from_subscription`. We can consider it as an unnecessary layer of abstraction, with readability drawback: we can't easily tell how Zuora callback attributes are mapped to License record. Additional attribute name aliases were also introduced by this serializer, adding more cognitive load.

## Proposal

Two opposite proposals:

1. inline `SubscriptionSerializer` into `License#build_from_subscription` 
2. turn `SubscriptionSerializer` into a License factory, which would replace `License#build_from_subscription`

Story points: 2.0
Switch to asdf-postgres

<!-- 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

Our installation guide has a section for installing PostgreSQL via Homebrew and via `asdf`. So we have two tools for installing two things and that might cause problems like if you installed everything via Homebrew and then decided to switch to `asdf`. Which database will be used in this case? The answer is unknown.

### Proposal

Let's switch to a single tool for installing our dependencies. GDK and CustomersDot as well as other projects in GitLab uses `adsf` as default tool for managing runtimes. GDK also uses `asdf` to install the correct PostgreSQL version so we should to the same to eliminate possible discrepancies and simplify our setup documentation.

Story points: 1.0
Include customer VAT code for new 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

Similar to the [Subscribe API](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/2d39af088c7f64fd534fc55cee7aabc3b5f53ead/app/services/subscribe_service.rb#L56), include customer's VAT code when creating an account for a new subscription.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Update `Zuora::Orders::Entities::NewAccount` to include to pass `vat_code` in `tax_info` object.

### Result

VAT ID is set for the new account in Zuora if customer's account has a VAT code set.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Follow-up from "Generate order action for renew subscription"

The following discussion from !5077 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5077#note_1039042561):  (+2 comments)

    > **Suggestion:** Since this type name matches the class name (minus the namespace), [just like the one defined in `CreateSubscription`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5077/diffs#305e4eb502d53caa9613283a073924536c92e484_39_39), what do you think about defining a `type` method for this in `Zuora::Orders::Actions:BaseService` and removing the ones in the subclasses?
    > 
    > ```
    >         def type
    >           self.class.name.demodulize
    >         end
    > ```
    > 
    > If we think they'll always match the Action name, that might be a nice optimization.  This could be done in a follow-up as well. WDYT?

### Proposal

1. Consider defining `action_type` in `Zuora::Orders::Actions:BaseService` that returns the class name:

```ruby
def action_type
  self.class.name.demodulize
end
```
2. Remove `type` definition from the action classes (`CreateSubscription`, `RenewSubscription`)
3. Update `type` to `action_type` in the `#execute` method in each of the action class

Story points: 1.0
Replace usages of order.customer_id in feature flags and logging

Update uses of `order.customer_id` with `order.current_customer.id` following discussion from !5057:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5057#note_1035847495):  (+1 comment)

    > There are a handful of places where `order.customer_id` is used for scoping of `Unleash.enabled?` or logging. I suspect these could be updated as well.

Story points: 1.0
[Feature flag] remove include_future_subscriptions

<!-- Title suggestion: [Feature flag] Enable description of feature -->

# Summary

<!-- Short description of what the feature is about and link to relevant other issues. -->

This issue is to rollout [include_future_subscriptions](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3800) on CustomersDot production,
that is currently behind the [`include_future_subscriptions`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/112/edit) feature flag.

## Owners

- Team: Fulfillment::Provision
- Most appropriate Slack channel to reach out to: `#g_provision`
- Best individual to reach out to: @lulalala
- PM: @courtmeddaugh 

## Expectations

### What are we expecting to happen?

<!-- Describe the expected outcome when rolling out this feature -->

### What might happen if this goes wrong?

<!-- Should the feature flag be turned off? Any MRs that need to be rolled back? Communication that needs to happen? What are some things you can think of that could go wrong - data loss or broken pages? -->

### Release the feature

After the feature has been [deemed stable](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#including-a-feature-behind-feature-flag-in-the-final-release),
the clean up should be done as soon as possible to permanently enable the feature and reduce complexity in the codebase.

<!-- The checklist here is to help stakeholders keep track of the feature flag status -->
- [x] Create a merge request to remove include_future_subscriptions feature flag 
  - [x] Remove all references to the feature flag from the codebase
- [x] Ensure that the cleanup MR has been deployed to both staging and production
- [x] Disable the feature flag via the [CustomersDot dashboard](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags)
- [x] Ensure production environment is still working as expected
- [x] Remove the Unleash feature flag from the [CustomersDot dashboard](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags)
- [x] Close this rollout issue.

## Rollback Steps

- [ ] This feature can be disabled by performing the following actions:
  - [ ] Disable the Unleash flag on the [feature flag page](LINK TO THE FEATURE FLAG EDIT PAGE)

Story points: 1.0
Switch SFDC BCC for Cloud Activation emails to Voucher email

<!-- 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
Today, in order to show proof of license delivery in SFDC of Cloud Activation emails, we BCC the SFDC email address on the activation emails sent to customers. These emails include the activation codes customers use to activate their subscription. Providing this data to anyone with access to SFDC is problematic for compliance reasons, given anyone could use this code to activate a subscription.

### Proposal
https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4565+ will create a voucher email for cloud license activation emails that will contain subscription details but will remove the activation code. This voucher will also include the relevant SFDC ID.

Remove the SFDC BCC from the current cloud license activation email, and ~~instead add the SFDC BCC to the voucher email created in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4565~~ The SFDC BCC email is already set as default recipient in `VoucherMail`. Making it BCC again in `ActivationCodeVoucherMailer` would be redundant.

Story points: 1.0
Clean up tracking_subscription_management FF

## Summary

This issue is to cleanup the `tracking_subscription_management` feature flag, after the feature flag has been enabled by default for an appropriate amount of time in production.

The feature flag is enabling/disabling frontend and backend tracking for all subscription management events for SaaS and SM subscriptions.

## Owners

- Team: ~25005342  
- Most appropriate slack channel to reach out to: `#g_billing_and_subscription`
- Best individual to reach out to: @dzubova
- PM: @tgolubeva  

## Expectations

### What might happen if this goes wrong?

### Cleaning up the feature flag

<!-- The checklist here is to help stakeholders keep track of the feature flag status -->
- [x] Create a merge request to remove `:tracking_subscription_management` feature flag
  - [x] Remove all references to the feature flag from the codebase
- [x] Ensure that the cleanup MR has been deployed to both staging and production
- [x] Disable the feature flag via the [CustomersDot dashboard](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags)
- [x] Ensure production environment is still working as expected
- [x] Remove the Unleash feature flag from the [CustomersDot dashboard](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags)

Story points: 1.0
Flaky spec spec/requests/marketo_request_spec.rb

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem

This spec `spec/requests/marketo_request_spec.rb` started failing recently:

* https://gitlab.com/gitlab-org/customers-gitlab-com/-/jobs/2739474113
* https://gitlab.com/gitlab-org/customers-gitlab-com/-/jobs/2734260310

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Follow-up from "Number of users field should default to empty in CP SM purchase flow"

## Problem

The following discussion from !5039 should be addressed:

- [ ] @pslaughter started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5039#note_1028174844):  (+2 comments)

    > **suggestion (ux):** Could we add a placeholder to the user quantity input? As-is I don't think it's obvious to the user what they are supposed to do. I'm not sure it's even clear this is supposed to be a number :thinking:
    > 
    > ![Screen_Shot_2022-07-15_at_12.08.50_PM](/uploads/3f76db41b5021e65743a999ec7848533/Screen_Shot_2022-07-15_at_12.08.50_PM.png)
    > 
    > What do you think @vvempati / @esybrant?


## Proposal

Add a sentence of description to the subscription details section, similar to what we're doing for the standard subscription renewal flow.

For the technical proposal, see [this comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4552#note_1141749523).

<p>
<details>
<summary>See how the description looks in the standard subscription renewal flow</summary>

![image](/uploads/98f4658ab46f78b3da11a7dab3d7f70d/image.png)

</details>
</p>

#### Design

![image](/uploads/110ebecdd06f66b0aeb5f0f3e5dab703/image.png)

Copy:

>>>

If you've already configured your instance, enter the current number of billable users or greater if you expect more users. If you haven't yet configured your instance, enter the number of users you expect to have.

[Where to find this](/gitlab-org/customers-gitlab-com/-/blob/main/gitlab-org/customers-gitlab-com/-/blob/main/url)

>>>

Styling for the copy should be the same as in the standard subscription renewal flow, see image above in the proposal section.

Story points: 1.0
Update new account custom fields to use snake case

The following discussion from !4989 should be addressed:

- [x] @jagood started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4989#note_1025656052):  (+3 comments)

    > I wonder if it might look better to have a more descriptive function name for this that might give a clue as to why we're doing this?
    > 
    > ```ruby
    > def subscription_params
    >   return unless args.key?(:subscriptions)
    > 
    >   args.fetch(:subscriptions).map { |subscription| prep_custom_fields!(subscription) }
    > 
    >   camelize_params(:subscriptions)
    > end
    > 
    > def prep_custom_fields!(params)
    >   params[:custom_fields].deep_transform_keys!(&:capitalize)
    > end
    > ```
    > 
    > Hmmm, I'm not sure.  That might not help.  :thinking: 
    > 
    > On a related note, is the `custom_fields` key of the `subscriptions` the only place we'll ever have to worry about this?  If not, I wonder about solving this for the general case in `camelize_params`.  Maybe something kind of like...
    > 
    > ```ruby
    > def camelize_params(parameter)
    >   return unless args.key?(parameter.to_sym)
    > 
    >   params = prep_custom_fields(args.fetch(parameter.to_sym))
    > 
    >   IronBank::Object.new(params).deep_camelize(type: :lower)
    > end
    > 
    > def prep_custom_fields(params)
    >   case params
    >   when Array
    >     params.map { |i| prep_custom_fields(i) }
    >   when Hash
    >     params.deep_transform_keys { |k| k.end_with?('__c') ? k.capitalize : k }
    >   else
    >     params
    >   end
    > end
    > ```
    > 
    > That may still need some work.
    > 
    > But if we did this, then we wouldn't change line 25.

More specifically, [new account custom fields](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/app/services/zuora/orders/custom_fields/new_account.rb#L15) need to be updated to snake case:

> On a related note, is the `custom_fields` key of the `subscriptions` the only place we'll ever have to worry about this?

### Proposal

Convert `SSPChannel__c` and `Entity__c` to `s_s_p_channel__c` and `entity__c` respectively.

Story points: 2.0
Document Order services architecture

<!-- 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

As part of the [Orders API upgrade](https://gitlab.com/groups/gitlab-org/-/epics/6438) efforts, we've implemented a design pattern to structure the Order related services.

- `OrderManagerService` as the entry point for triggering a request to create an order. Based on the type of order operation (such as creating a new subscription, renewing, cancelling a subscription, updating a product, etc.), the `OrderManagerService` internally invokes the `order action` services that generate the parameters required to perform the operation
- `orders/actions` contain services pertaining to order actions
- `orders/entities` construct particular entity object (that can be shared and re-used by multiple order actions). For e.g. `NewAccount`, `RatePlan` object.
- `orders/custom_fields` generate custom fields for subscription, account, orders

![Orders_architecture](/uploads/176e6dca1af16f64ac2cd8b696d1b151/Orders_architecture.jpg)



### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Document the design choice, approach, and implementation details.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Hard to read link in error message

### Problem

After enabling Strict Cloud License, the license for cloud licenses is no longer available for download. When attempting to download it via a direct url call by visiting `/licenses/<subscription name of a cloud license>`, an error message is displayed after the redirect. The error message contains a link to the Support team that is rendered in a white color, making it hard to read on the light red background:

![Screen_Shot_2022-07-06_at_2.36.12_PM](/uploads/b2eb2f37eb081a903d95c8e633ccab1b/Screen_Shot_2022-07-06_at_2.36.12_PM.png)

This may also happen with other error messages too.

### Proposal

Change the color of the link to something more readable.

### Result

Easier readable link in the error message.

Story points: 1.0
Use Order manager service to create subscriptions initiated from marketplace

<!-- 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

Support marketplace attributes when creating a new subscription using Orders API.
Looking at `Marketplace::CreateSubscriptionService`, it appears the following attributes need to be supported:

```
external_subscription_id
trading_partner_id
fulfillment_distributor
lead_source
unit_price (products -> main)
```

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

This issue entails the following three steps:

- [x] Identify the corresponding parameters in Orders API
- [x] Include the attributes in `Zuora::Orders::OrderManagerService` or `Zuora::Orders::Actions::CreateSubscription` as appropriate (based on whether it is an order param or subscription param). Create entities if need be.
- [x] Allow Marketplace subscriptions to be created via Orders API ([remove the eligibility `false` condition when  the request is initiated from marketplace](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/6ef9daf015f8a7e748195917f0fec0ee82966cf9/app/services/zuora/orders/feature_availability.rb#L17): depends on https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5058 to be merged)

### Result

Marketplace subscriptions use Orders API to create subscriptions instead of Subscribe API.

Story points: 2.0