giseldo/neodataset huggingface dataset:
Do not set Service Activation Date in Orders API

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem

Service Activation date should not be explicitly set, but should inherit the value of Contract Effective Date. Also, we do not require Service Activation of Orders. (see related [conversation](https://gitlab.slack.com/archives/C037WQ2BUGK/p1665417907870689?thread_ts=1665414245.001139&cid=C037WQ2BUGK).

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

- In [`Zuora::Orders::Actions::BaseService`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/ac19a2843ad59a38351558c4e77b2e4b90fd7ee7/app/services/zuora/orders/actions/base_service.rb#L34), remove attribute `service_activation`
- In [TriggerDate](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/ac19a2843ad59a38351558c4e77b2e4b90fd7ee7/app/services/zuora/orders/entities/trigger_dates.rb#L20) entity, remove support for `service_activation`
- Update specs

### Result

Service Activation date is not set during Order creation in Zuora.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
[Reseller] Hide subscription management buttons for a subscription purchased via a reseller

## Problem

Subscriptions purchased via a Reseller should not be amended via the Customers Portal. 

Any subscription changes should be done via the Reseller (and not the customer), since Resellers are responsible for paying the related invoices.

For screenshots of the current experience for Reseller customer (if they were able to login) see https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/809+.


## Proposal

Hide the following buttons on the subscription card if the subscription is managed by a reseller:

- Add Seats
- Upgrade
- Resume
- Cancel
- Renew
- Buy additional CI Minutes
- Buy additional Storage

Looks like we have a `subscription.managed_by_reseller?` method in the code.

### SM Subscription card

All buttons should be removed. 

![cdot-sm-subscription-card-crossed](/uploads/268a4f53a15dd0972e6512e9a0559ac0/cdot-sm-subscription-card-crossed.png)

### SaaS Subscription card

The only button we need to keep is `Change linked namespace`

![cdot-saas-subscription-card-crossed](/uploads/0eba0eec5a61f0a15a8f87d25d623860/cdot-saas-subscription-card-crossed.png)

**Note:** Hiding the `Buy new subscription` button will be tackled in this issue - https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5074

## Implementation breakdown
| Description | MR |
| ------ | ------ |
| :one: Hide CI minutes button | https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5695|
| :two: Hide buy storage button| https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5719/ |
| :three: Hide upgrade plan button | https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5728 |
| :four: Hide add seats button | https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5729/ |
| :five: Hide renew button | https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5730  |
| :six: Hide cancel and resume button | https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5731 |


## Result

Reseller customer will not be able to amend their subscription.

### Next steps (if any)

### How will we measure success?

Story points: 3.0
Set appropriate billing options when updating a subscription

<!-- 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 updating a subscription using Orders API, set billing options as described below:

| Attribute | Value |
| ------ | ------ |
| `target_date` | If subscription has expired, set to current date. <br/> Default to Subscription term end date |
| `document_date` | Current date |
| `document_date` | Current date |
| `process_payments` | Based on `params[:process_payments]` |
| `payment_method_id` | Based on whether `params[:payment_method_id]` is present |

These attributes are inline with the existing [Amend API](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/60e7bfca2087f17bc06104474ca1b0a3f5b9bb9c/app/services/amendment_base_service.rb#L192).

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Update billing params and remove setting of service activation date as described in the Problem statement.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
SendSeatOverageNotificationJob continually enqueued for the same namespace

### Problem

We noticed the sidekiq queue in CDot growing endless and it seems the same job, `Reconciliations::SendSeatOverageNotificationJob`, is being enqueued over-and-over with the same params.  More info in [this Slack thread](https://gitlab.slack.com/archives/CL7SX4N86/p1665070227457529).

Our current pending Sidekiq queue count is 23,646 and growing.  You can see the reconciliations queue at https://customers.gitlab.com/sidekiq/queues/reconciliations

### Proposal

We can work on a short-term fix to block the particular namespace id, `10782951`, for the numerous jobs, until we determine a better long-term solution.

Story points: 1.0
Follow-up from "Set default payment before an upgrade"

The following discussion from !5518 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5518#note_1122714925): 

    > **Thought (no change necessary):** I was noticing some similarities (you may have as well) between this method and the `set_default_payment_method` [in `::Zuora::Helpers::PaymentMethod`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/42542df5fa778f782ae3ccefc21f04711eb0a1f3/app/services/zuora/helpers/payment_method.rb#L21).  There is even a `payment_method_id` method defined there.  
    > 
    > I wonder if there is room for refactoring to combine these in the future? There is a difference in setting `auto_pay` but we may be able to define that in a flexible way.  Anyway, just a thought for the future perhaps.

Story points: 2.0
Update setup instructions to include setting salesforce secrets

<!-- 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

With unset salesforce values in `secrets.yml`, mailer preview will no longer generate.

### Proposal

Update the readme to list instructions for setting the salesforce secrets

Story points: 1.0
[Error Budget] Investigate `MaxAdditionalSeatsExceededError`

From: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4918#note_1124235188  
Sentry: https://sentry.gitlab.net/gitlab/customersgitlabcom/?query=is%3Aunresolved+lastSeen%3A%2B1d+maxadditional

This error seems like valid business logic and not an application exception. We should stop raising an error where appropriate so we're not reporting these as errors.

Story points: 2.0
[SPIKE] Investigate on improving SubscriptionController#create response time

According to the kibana query below, we see that the endpoint: `SubscriptionsController#create` has the worst Appdex, with `515` operations over the threshold out of `674`.

This issue is a placeholder to dig deeper into the request and try to find a way to improve the response time.

1. **Rails Requests Apdex**: slow requests exceeding the threshold along with total number of request

![Screenshot_2022-10-05_at_17.57.45](/uploads/98ae6e9ec9d4f4fbfbbcae0eef4fe86a/Screenshot_2022-10-05_at_17.57.45.png)

[Kibana log](https://log.gprd.gitlab.net/app/kibana#/visualize/create?type=table&indexPattern=7092c4e2-4eb5-46f2-8305-a7da2edad090&_a=(filters:!((meta:(key:json.subcomponent,negate:!t,params:graphql_json,type:phrase),query:(match:(json.subcomponent:(query:graphql_json,type:phrase)))),(meta:(key:json.meta.feature_category,params:!(purchase),type:phrases),query:(bool:(minimum_should_match:1,should:!((match_phrase:(json.meta.feature_category:purchase)))))),(meta:(key:exists,type:json.duration_s,value:exists),query:(exists:(field:json.duration_s))),(meta:(key:exists,type:json.target_duration_s,value:exists),query:(exists:(field:json.target_duration_s)))),query:(language:kuery,query:''),vis:(aggs:!((enabled:!t,id:'1',params:(),schema:metric,type:count),(enabled:!t,params:(field:json.meta.caller_id.keyword,missingBucket:!f,missingBucketLabel:Missing,order:desc,orderBy:'3',otherBucket:!t,otherBucketLabel:Other,size:5),schema:bucket,type:terms),(enabled:!t,params:(field:json.request_urgency.keyword,missingBucket:!f,missingBucketLabel:Missing,order:desc,orderBy:'3',otherBucket:!t,otherBucketLabel:Other,size:5),schema:bucket,type:terms),(enabled:!t,params:(field:json.target_duration_s,missingBucket:!f,missingBucketLabel:Missing,order:desc,orderBy:'3',otherBucket:!t,otherBucketLabel:Other,size:5),schema:bucket,type:terms),(enabled:!t,id:'3',params:(customLabel:'Operations+over+specified+threshold+(apdex)',field:json.duration_s,json:'%7B%22script%22:+%22doc%5B!'json.duration_s!'%5D.value+%3E+doc%5B!'json.target_duration_s!'%5D.value+?+1+:+0%22%7D'),schema:metric,type:sum))))&_g=(time:(from:'now-3d',to:'now')))


2. **Rails slow requests**: Top slow requests

![Screenshot_2022-10-05_at_18.09.53](/uploads/43fad2671ebd5fe5717b14d97e10bcab/Screenshot_2022-10-05_at_18.09.53.png)

[Kibana log](https://log.gprd.gitlab.net/app/discover#/?_a=h@7842932&_g=(time:(from:'2022-10-05T09:37:00.000Z',to:'2022-10-05T15:37:59.999Z')))

Story points: 3.0
'License seat links' - customer field has incorrect URL

<!-- 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 customer field in the 'License seat links' view links to the customer information in the `Customer` view. \
The URL is incorrect though.

Currently: https://customers.gitlab.com/admin/RailsAdmin::Customer/6057 \
Should be: https://customers.gitlab.com/admin/Customer/6057

### Proposal

Fix URL

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result

Clicking on a customer name in the 'License seat links' view will open the customer information in the `Customer` view.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Follow-up from "FF use of Orders API in Upgrade workflow"

The following discussion from !5539 should be addressed:

- [ ] @aish.sub started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5539#note_1122624105):  (+2 comments)

    > **note**: I wonder if it will be better (helpful?) to update this custom action to `add_main_product_during_renewal` in order to make it explicit (similar to `add_main_product_during_upgrade`) :thinking:

Story points: 1.0
[Documentation & Learning] True-Up Logic

## Documentation

* https://gitlab.com/gitlab-org/gitlab/-/blob/aaa552b248b3af6dd2a4de88173fff7bfe85f4e1/doc/subscriptions/self_managed/index.md#users-over-license
* https://gitlab.com/gitlab-org/gitlab/-/blob/30adf0ce90db1326e9e53388aae26b3266651033/doc/subscriptions/quarterly_reconciliation.md#quarterly-reconciliation-and-annual-true-ups
* https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/510+
* https://about.gitlab.com/handbook/business-technology/enterprise-applications/quote-to-cash/troubleshooting/#true-ups-adding-seats-users


## Learning

* The true-up logic can be simplified by skipping it for Cloud Licenses (https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5483).
* Introduce the ability to revoke cloud licenses (activation codes, https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5486).
* Define a process to recognize and require payment for overages (separate from removing true-ups) https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5299

Story points: 1.0
[Documentation & Learning] Legacy License Provisioning

## Step 1: Documentation & Learning

* [x] You feel the existing document is accurate, current, and thorough.
* [-] You have engaged `@courtmeddaugh` / `@fneill` as needed for assistance if you feel business or customer-facing documentation should be updated.
* [x] You have a strong enough understanding of the process to be able to host a knowledge share session.

Story points: 2.0
Create activation code for all SM subscriptions (even when TurnOnCloudLicensing = No)

## Background
There is one remaining bucket of customers for whom no cloud activation is created, meaning there no way for them to access an activation code other than requesting one be created by the support team:
* Customers with `TurnOnCloudLicensing` = `No` - we do not generate a cloud activation for explicitly opted out customers

## Proposal
Update the activation code logic to create an activation code for all Self-Managed subscriptions, so that even opted out customers have the option of activating with cloud licensing.

## Experience
When a customer has `TurnOnCloudLicensing` = `No` (opted for a legacy license), but an activation code exists, we show an expandable banner with both the legacy license available for download and the activation code:


![image](/uploads/3b360a2fbacae9aed15e0a97cf492293/image.png)

## Next Steps
Once this is closed, we should backfill any active Self-Managed subscriptions that do not have an activation code available (https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5604).

Story points: 2.0
[Backfill] Create activation codes for subscriptions on legacy licenses pre-SCL

## Background
https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/589+ defines the process for customers to activate with Cloud Licensing mid-term if they already have an active legacy license subscription. For most customers, a Support ticket is required to move to Cloud Licensing.

To make it easier for these customers to self-activate with Cloud Licensing, this issue will evaluate the possibility of mass-generating activation codes for customers that do not have one.

## Details
Today, the Customer Portal subscription activation display banner for `TurnOnCloudLicensing` = `null` has a dependency on if an activation code exists.
* If activation code exists: display legacy download option only
* If activation code does not exist: display activation code only

As of September 2022, we are creating activation codes for all subscriptions where `TurnOnCloudLicensing` is not = `No`. However, prior to SCL launch (July 2022), we did not create activation codes for these subscriptions.

## Proposal
1. Query the subscription names with `TurnOnCloudLicensing` set to `null` and `Status = "Active"` in Zuora (with a Data Query, [example](https://apisandbox.zuora.com/platform/data-query/queries/20e2a75f-8e30-4ea6-b922-a0a73c80efde)) and then cross check those with existing cloud activations. 
2. If no cloud activation exists for the subscription name, create one.
3. In doing so, ensure we do NOT send customers emails with the activation code (to avoid confusion).

## Result
All customers (who did not explicitly opt out of Cloud Licensing, `TurnOnCloudLicensing` = `No`) will have a cloud license activation code available for download visible in the Customer Portal, allowing for mid-term activations of cloud licensing without the need for a support ticket.

Story points: 3.0
Perform Post Order creation steps for 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

Once a subscription is amended, there are a few post order creation steps that is performed:

- Update EoA starter/bronze offer
- mark coupon as redeemed

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Perform the above listed steps when applicable in `Zuora::Orders::PostCreationService`

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Improve SeatLink Apdex score

### Problem

~"group::provision" [apdex customersdot rails_requests failure is high](https://dashboards.gitlab.net/d/stage-groups-detail-provision/stage-groups-provision-group-error-budget-detail?orgId=1&from=now-24h&to=now&viewPanel=14). For the past 7 days the [apdex failure ratio is 47255/93360](https://dashboards.gitlab.net/d/stage-groups-detail-provision/stage-groups-provision-group-error-budget-detail?orgId=1&from=now-7d&to=now&viewPanel=14). It is holding back our overall error budget.

By sorting the averge on [Grafana ranking](https://dashboards.gitlab.net/d/stage-groups-detail-provision/stage-groups-provision-group-error-budget-detail?orgId=1&from=now-24h&to=now&viewPanel=44), `Api::V1::SeatLinksController#create` seems to be the largest contributing factor. It usually peaks around 4 AM UTC each day at -50% mark. E.g. in CDot production log, I found one request taking 7s.

### Proposal

We should first gather stats on request time in order to see how the distribution and average looks like. Since we don't have log.gitlab.net for CDot this will take some manual effort.

Engineering-wise, we can look into reducing seat link time. 

The peak probably means a large number of self-managed instances are concentrated in the same timezone. We may also look into spreading the sync time further apart. 

Product management-wise: we may have to consider increase the request threshold (urgency). According to [Rails request Apdex SLI doc](https://docs.gitlab.com/ee/development/application_slis/rails_request_apdex.html#decreasing-the-urgency-setting-a-higher-target-duration), automated process is not user face therefore it makes sense to have a lower urgency.

### Result

Reduce the number of apdex errors.

### Next steps (if any)

### How will we measure success?

A healthier [apdex percentage](https://dashboards.gitlab.net/d/customersdot-main/customersdot-overview?orgId=1&viewPanel=23&from=now-7d&to=now) of less than -5%.

Story points: 8.0
[Spike] Backporting Cloud License fixes to 14.1

With the efforts for [Strict Cloud License](https://gitlab.com/groups/gitlab-org/-/epics/7088) and [Cloud License Follow-Ups](https://gitlab.com/groups/gitlab-org/-/epics/8187) we should look at which Cloud License ~"type::bug"  fixes we should backport to [Cloud License V1](https://gitlab.com/groups/gitlab-org/-/epics/1878), so customers upgrading to this version don't experience issues fixed down the road.

An example of this could be this issue: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4688.

Story points: 3.0
Do not show subscription management buttons on CI mins subscriptions without attached namespace

<!-- 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 mentioned in this [comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4428#note_1108064352), we should not be showing subscription management buttons on CI minutes subscriptions without namespace attached.

### Proposal
As mentioned in point 3 of this [refinement](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4428#note_1092677679), update the logic to hide subscription management buttons.

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result
Subscription management buttons should not be visible on CI minutes (and other free plans) with no linked namespace.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Remove Visual Compliance except for eDisty Marketplace use

### Problem

As described in [this thread](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3393#note_1106637176), Visual Compliance code is enabled for eDisty Marketplace Orders, but disabled for all other use in CustomersDot.  This is because Visual Compliance proved to not be as effective in screening, particularly outside of the US.  Given eDisty Marketplace Orders are starting out as US-only, we've enabled VC just for this workflow for now.  The intention eventually is for VC to be replaced with Risk Rate as described [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3393#note_1107774308).

### Proposal

Given we do not want to enable VC for code paths other than eDisty Marketplace, let's remove this code to avoid confusion and potentially enabling this path by accident.

Note there are 2 distinct feature flags related to visual compliance: `compliance_check_marketplace` and `compliance_check`.  We want to keep the flag `compliance_check_marketplace`, but drop the flag for `compliance_check` and any related code.  

- `perform_compliance_check` [in application_controller.rb](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/e3d1c1a06c37668851bf96058ad78699288fa7e7/app/controllers/application_controller.rb#L92)

Story points: 2.0
[Knowledge-sharing] Provisioning-related Notifications

Please check the video [here](https://www.youtube.com/watch?v=T_UM41tO10U).

[Notes](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4849#note_1222246231) and [recommendations](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4849#note_1260130350) are below :point_down_tone2:

Story points: 2.0