giseldo/neodataset huggingface dataset:
Investigate possible gem updates for Ruby 3 compatibility

This issue holds all gems that need to be updated in order to run CustomersDot on Ruby 3.2.

| Name       | Works on Ruby 3? | Updated? | Breaking changes | MR |
| ------     | ------ | ------ | ------ | ------ |
| [webmock](https://rubygems.org/gems/webmock)  |  Yes   |  No    |  No    |        |
| [countries](https://rubygems.org/gems/countries) |  Yes   |  No    |  Yes    |        |
| [pg](https://rubygems.org/gems/pg) |  Yes   |  No    |  No    |        |
| [date](https://rubygems.org/gems/date) |  Yes   |  No    |  No    |        |

Story points: 5.0
Retire AmendSubscriptionService and AmendmentBaseService

<!-- 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 final cleanup, delete amendment related services:

* Delete `AmendSubscriptionService` service and its spec file
* Delete `AmendmentBaseService` service and its spec file. Since `Gitlab:: UpgradeSubscriptionPlanService` used to inherit `AmendmentBaseService`, move used methods to the `UpgradeSubscriptionPlanService` class.
* Delete `Zuora::Actions::Amend` and `.amend` method in subscription model

### 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: 2.0
Retire `amendment` related params in Salesforce::CreateQuoteRatePlanChargeService service

The following discussion from !6721 should be addressed:

- [x] @a_luna started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6721#note_1313922963):  (+1 comment)

    > **question:** Are we considering retiring these `amendment` related params as well? 
    > 
    > Since the calls to `create_salesforce_quote_rate_plan_charge` are getting this parameter set to `nil`, these parameters are always sent as `nil` too :thinking: 
    > 
    > Although this could probably be tackled in a follow up to keep this MR from getting larger :sweat_smile: :thinking:

Story points: 2.0
Updating Customer Email as an Admin user

# Bug

## Summary

There are times when Support team need to update a customersDot email address per request of the customer, or in order to send a license file to the intended recipient after [a Zuora contact change took place](https://gitlab.zendesk.com/agent/tickets/383199) that the customer was not expecting (e.g. separate subscription closed won).  This is relevant even for creating/sending legacy licenses since they will pull Zuora contact info regardless of the email address entered into the form.

In the past, [this was a simple update/save](https://about.gitlab.com/handbook/support/license-and-renewals/workflows/customersdot/associating_purchases.html#process).  Now, with some recent changes to the platform, its require the email addresses to be confirmed by the customer, even when changed through admin actions, and it creates kind of an undesirable scenario for both us and the customer.  We should be able to circumvent this from the admin side.

For one, cdot sends 2 emails out per change, an "FYI this happened" and a "please confirm this happened".  That's fine in a vacuum, but it may unintentionally be spamming the customer, especially if the email address is being changed only temporarily.  For two, it breaks our workflow to "Change the email in the new account for example: person@example.com to person_edited@example.com"; `person_edited` is not a real address and therefore can't get the confirmation email, but that's sort of the point with that workflow to swap addresses around.

Also, I notice it updates Zuora BTST immediately, even when cdot still reflects the previous email address.  That may or may not be intentional?

## What is the expected *correct* behavior?

From the admin side, we should be able to update contact information without relying on the customer to confirm their address.  Or, we should have the means to confirm it for them without email.  In a perfect world, we should never need to change cdot contact info for them, but there are many relevant reasons for why support needs to change cdot info on behalf of the customer

## Workarounds

In some cases, you can change the email to update Zuora, send the license, then update it back in cdot.  This does probably spam the customer with multiple notifications that the address has been changed.

## Reported examples

1. https://gitlab.zendesk.com/agent/tickets/383199
1. https://gitlab.zendesk.com/agent/tickets/382845
1.

<!---
Please add both severity and priority level according to: https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#severity-labels
--->

Story points: 2.0
CustomersDot one-time sign in URL visible to read-only admin users

In the `https://customers.gitlab.com/admin/customer/####` page, the one-time sign-in URL for the customer is visible to all admin users. 

This could lead to impersonation, which should not be allowed for read-only roles. See the list of roles in: https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/doc/setup/okta.md#group-meaning

Story points: 1.0
Display a unique identifier in the Billing Account search list

<!-- 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/

-->

# Feature Request

## Problem

Searching a Billing account by name shows similar entries in the list when multiple Billing Accounts with the same name exists. This makes it a gamble when we need to associate a customer to a specific Billing account.

![Screenshot_2023-03-09_at_18.09.36](/uploads/dcb8266f48f4115e8efacaa92c27fd1c/Screenshot_2023-03-09_at_18.09.36.png)

## Proposal

Display the Zuora Account ID or Billing Account ID in the list displayed during a search

## Workaround

 In the new billing account membership, search a customer by email address, and in billing account, search by Zuora Account ID

Story points: 1.0
Add logging to Sync BillingAccount name to Customer company

The following discussion from !6726 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6726#note_1304713465): 

    > **Suggestion (non-blocking):** We could add logging for the success and error cases here.  If an update fails, it might be nice to know why.
    > 
    > I don't see this as a blocker as we can always add it later if needed.

Story points: 1.0
Follow-up from "Remove account_data_structure flag in Order model"

### Proposal

A few suggestions came up in the review of https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6699 that I wanted to follow-up on separately to avoid delays in getting that MR merged.  Each of the following items involve test refactoring:

* [x] Remove `:with_zuora_account_id` trait in Customer factory https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6752
* [x] Remove `:with_salesforce_account_id` trait in Customer factory https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6752
* [x] Include `billing_account` creation in the `:with_zuora_account` trait https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6764
* [x] Replace `:with_billing_account_membership` usages where `create_zuora_account` helper is also used in favor of `:with_zuora_account` trait. https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6769
* [x] Refactor `with_billing_account_membership` trait in [Customer factory](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/spec/factories/customers.rb#L69) to stop using the `zuora_account_id` field https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6812

### Follow-up from https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6699

Discussion Thread: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6699#note_1304799044

Story points: 2.0
Mailgun integration with Slack

We're currently going through a (sporadic) Mailgun outage. We found out about this after some investigation done yesterday (Feb 21st). It would be more convenient and better for general awareness to have Mailgun updates sent directly to our `#s_fulfillment_status` Slack channel.

This issue tracks effort to have integrate Mailgun with Slack. More info about how to do this here: https://www.mailgun.com/resources/integrations/slack/

Story points: 3.0
Follow-up from "Update implementation to identify professional services"

The following discussion from !6671 should be addressed:

- [ ] @vshumilo started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/6671#note_1302936956):  (+2 comments)

    > **praise / thought (non-blocking):** Nice to see this update where we can reference a product name consistently instead of trying to cover all the plans that can be updated anytime in Zuora.
    > 
    > As long as we have a convention or established agreement that this will always be the product name :fingers_crossed: 
    > 
    > Do you know if this is documented somewhere? Else I think it will be a nice follow up to just add some context around this in the docs and tag the stable counterparts.

Story points: 1.0
Marketplace API: Add missing descriptions to OpenAPI spec

<!-- 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 [Marketplace API spec](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/doc/api/marketplace_openapi.yaml?plain=1) doesn't currently have request and response descriptions for the following operations:

- [/oauth/token](https://customers.staging.gitlab.com/openapi_docs/marketplace#/marketplace/post_oauth_token)
- [/api/v1/marketplace/subscriptions](https://customers.staging.gitlab.com/openapi_docs/marketplace#/marketplace/post_api_v1_marketplace_subscriptions)
- [/api/v1/marketplace/subscriptions/{external_subscription_id}](https://customers.staging.gitlab.com/openapi_docs/marketplace#/marketplace/get_api_v1_marketplace_subscriptions__external_subscription_id_)

| | | |
| ------ | ------ |------ |
| ![Screenshot_2023-03-08_at_16.00.59](/uploads/b856ae367268513d2fb77c4dd8d9d20d/Screenshot_2023-03-08_at_16.00.59.png)      | ![Screenshot_2023-03-08_at_16.05.16](/uploads/2b5e779650aae43fdd254b513cb92657/Screenshot_2023-03-08_at_16.05.16.png)        | ![Screenshot_2023-03-08_at_16.05.37](/uploads/4922e758f5fb687b9b2e10816e88fb10/Screenshot_2023-03-08_at_16.05.37.png)  |


### Proposal

In the [Marketplace openapi.yaml](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/doc/api/marketplace_openapi.yaml?plain=1):
  - Add meaningful descriptions for all request parameters and response fields.
  - Specify which parameters are required.
  - Provide type of parameter and field (boolean, string, integer).

This will also ensure the spec is aligned with the [OpenAPI Specification](https://oai.github.io/Documentation/specification).

### Who can complete this issue

- A developer with knowledge of the API to update the Marketplace openapi.yaml.
- A technical writer to review for style, language, and comprehension.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Simplify Salesforce classes arguments forwarding

There are several Salesforce classes, the class method `def self.execute` and initializer `def initialize` have a long argument list.

Explicitly declare such as long argument list has some disadvantages:
- every copy of these argument lists need to be updated, when we update(add, rename, or remove) an argument
- the codes looks messy, thus less readable

We could use the `triple-dot syntax` to simplify them. As we already used in several codes in CustomersDot, such as in [CreateSalesforceContactService](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/46f7dda523ae373270a8ad0cdba4facfdc972083/app/services/create_salesforce_contact_service.rb#L4-6)

```
  def self.execute(...)
    new(...).execute
  end

```

### Problem

### 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
Remove instances of AmendSubscriptionService in specs

<!-- 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

There are a few instances where in `AmendSubscriptionService` is stubbed in specs such as:

- [`SubscriptionsController` spec](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/54d8d8bbda8810f42e5403861b852abb6da1b950/spec/controllers/subscriptions_controller_spec.rb#L1194)
- [Renewal](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/54d8d8bbda8810f42e5403861b852abb6da1b950/spec/features/existing_customers/renewal_spec.rb#L10) spec

Most of them use Order related services, and the invocation of `AmendSubscriptionService` is duplicated.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Find and remove the `AmendSubscriptionService` stub. Ensure no changes to current functionality of existing specs and that they continue to pass.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Remove activation code display dependency on super_sonics_aware

<!-- 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
Given the [backfill completed that generated activation codes for all remaining customers](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5604), any customer with customer portal access should be able to self-activate with cloud licensing. Because cloud licensing does not have any legal terms component, there is no reason to have a condition on whether or not to display the activation code based on if the customer is super sonics aware or not.

### Proposal
Remove the `super_sonics_aware` check for the different displays of legacy license / activation codes in the customer portal.

Related code is here: https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/f628a9a0ffc0d6a99181684bab3c417eb671d1a7/app/presenters/subscription_presenter.rb#L213

### Result
Any customer with customer portal access can self-activate cloud licensing, as outlined in https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/1034+.

### Reported Examples

1. https://gitlab.zendesk.com/agent/tickets/385142
2. https://gitlab.zendesk.com/agent/tickets/378605

Story points: 2.0
Show Bill To / Sold To instead of Customer data at checkout if Customer has a membership

### Proposal

At checkout, for Customers with BillingAccountMemberships, let's show Bill To / Sold To Contact information instead of Customer information.  You can see how the Customer information is presented in the screenshot below.

This change should be behind [the feature flag](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5873), `key_contacts_management`.

![Screenshot_2023-03-07_at_10.05.39_AM](/uploads/6fb9f7796617922d277fef16e6b098af/Screenshot_2023-03-07_at_10.05.39_AM.png)

Story points: 2.0
Hide address fields in Account details form if Customer has a membership

### Proposal

On the Account Details form when logged in as a Customer (shown below), the address fields should be removed when a Customer has a BillingAccountMembership.  The Customer address fields will not be used in app logic when a Customer converts to a paid Customer (ie. has a membership with a BillingAccount).

This change should be behind [the feature flag](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5873), `key_contacts_management`.

![Screenshot_2023-03-07_at_9.39.43_AM](/uploads/be7c9544175ac1672e45b7368a6d590c/Screenshot_2023-03-07_at_9.39.43_AM.png)

Story points: 2.0
Hide address fields in the Admin if Customer has a membership

### Proposal

On the Customer show page in CDot Admin (shown below), hide the address fields when a Customer has a BillingAccountMembership.  The Customer address fields will not be used in app logic when a Customer converts to a paid Customer (ie. has a membership with a BillingAccount).

This change should be behind [the feature flag](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5874), `key_contacts_management_admin`.

![Screenshot_2023-03-07_at_9.43.28_AM](/uploads/f9e7079bda2107febb526599aba80756/Screenshot_2023-03-07_at_9.43.28_AM.png)

Story points: 1.0
Track License Type on License detail view in CustomersDot Admin

<!-- 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 viewing `Licenses` in CustomersDot Admin, you can sort licenses by type of Cloud, Offline Cloud, Legacy Licenses & Trial. However, when I click on the `Show` button to view details of an individual license, I can't see from that view the license type. It would be helpful to have this so when I look at an individual license, I can easily identify the type.

![image](/uploads/679b02d3e96e240d8616980fc0ed881c/image.png)

### Proposal


Add a field that tracks type of license in this screen:

![image](/uploads/6a3d5cb8aef73ce1a23a901d1548c194/image.png)

It could also be useful to add this as a column in the `List of Licenses` view if possible.

### Result
From the detail license view, I can tell what license type it is.

### 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 be added to ensure that this new data appears on the Show page.  (Feature? Controller#show spec?)
- Test that the column appears in the `List of Licenses` view

Story points: 1.0
Deprecate Customer address fields if a membership exists

### Problem

There are a few places in the application that use Customer address information.  There could be places however that should use the address information from the Zuora Account key contacts instead.

### Proposal

Let's remove the usage of Customer address fields if a BillingAccountMembership exists for that Customer.  This could involve the following:

- [x] Review all app code for places where address is referenced from Customer.
- [x] Update any places where the address data can be accessed from the Billing Account key contacts.

Story points: 2.0
Consider disable/hide the production Marketplace openapi doc page

ATM the Marketplace openapi doc page is available on all environments:
- https://customers.gitlab.com/openapi_docs/marketplace
- https://customers.staging.gitlab.com/openapi_docs/marketplace
- http://localhost:5000

Should we consider to hide this page on production server(https://customers.gitlab.com/openapi_docs/marketplace)?
- For openapi doc purpose, staging server is enough for people to understand and try/play with the APIs
- I think we do not expect anyone will play those APIs on production server. 
   - It is dangerous. If people `place order` from the production page, it does **not** go through Marketplace partner's system. there is no history on partner's system to audit -- which is not expected I think. 
   - It does not bring too much convenience either. People needs to have Marketplace partner's **production client_id/client_secret** to be able to try the APIs on production page https://customers.gitlab.com/openapi_docs/marketplace. 
      - For GitLab developers, if for issue investigation, we would directly get that data from DB, rather than `get client_id/client_secret from DB, and then go back to the web page to try`.

So, the proposal is, hide the production page https://customers.gitlab.com/openapi_docs/marketplace. It is only available on non-production environmebnt(staging, localhost, stag-ref)
   - another option is: disable `try it out` feature on production. -- I do not prefer this option, because: unless we have an easier way to switch it off, it may require us to maintain a separate copy of [marketplace_openapi.yaml](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/doc/api/marketplace_openapi.yaml)


BTW: the [Marketplace partners overview page](https://docs.gitlab.com/ee/integration/partner_marketplace.html#marketplace-api-specification) only link to staging server(https://customers.staging.gitlab.com/openapi_docs/marketplace)

### Problem

### 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