giseldo/neodataset huggingface dataset:
Flaky test: VCR::Errors::UnhandledHTTPRequestError

### Problem

This spec, [introduced here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2599/diffs#bcb86af9495467f36c3dd1683988ef3798f91962_56_57), started to fail a bit more often (perhaps a coincidence):

```
rspec './spec/features/upgrade_subscriptions_spec.rb[1:3:2:1:2]' # upgrading subscriptions with eoa_starter_bronze disabled when ultimate plan selected behaves like an app without EoA banners does not show the alert about free upgrade
```

#### Example failures

- https://gitlab.com/gitlab-org/customers-gitlab-com/-/jobs/2409005037
- https://gitlab.com/gitlab-org/customers-gitlab-com/-/jobs/2406620513
- https://gitlab.com/gitlab-org/customers-gitlab-com/-/jobs/2304577351


### Proposal

Perhaps this investigation can be of some guidance in terms of resolving the flake: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/736#note_229553100.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Follow-up from "Add mailer for Offline Cloud License"

The following discussion from !4690 should be addressed:

- [ ] @fneill started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4690#note_935166630):  (+3 comments)

We want to update all the `or later` usages in our emails to refer to the GitLab version to be `and later` to be consistent with the [style guide](https://docs.gitlab.com/ee/development/documentation/styleguide/word_list.html#later)

Story points: 1.0
Add marketplace API to CDot openAPI doc

As suggested in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4253#note_935114380.


> 1. Is there some documentation on the API endpoints for Disty that I can refer to?

I'm not aware of this documentation if it exists. @qzhaogitlab Perhaps we can add it to [openAPI docs for CDot](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/doc/api/openapi.yaml) (disclaimer: it's not a complete list of endpoints right now)? There's information about how to update the docs [here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/main/doc/api/index.md).

### How will we measure success?

Story points: 2.0
[SaaS] Add messaging about user overage process to Renewal flow

## Problem to solve

SaaS customers are being surprised and taken off-guard by Quarterly Subscription reconciliations. Because self-service SaaS customers have not historically been charged true-ups, the QSR process and the fact that they have to pay for overages is totally new. See tickets from customers [here](https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/337).

## Intended users

**This issue is just for SaaS customers.**

* Group Owners who are **renewing a subscription** through our self-service renewal flow
* See exactly which use cases we're solving for in the [Epic description](https://gitlab.com/groups/gitlab-org/-/epics/7229#saas-customers).

## Proposal

When a user is **renewing** GitLab, make sure that they are aware of the overage process. Show a message to all customers using the self-service renewal flow that notifies them about the overage process.

[Purchase Design here](https://gitlab.com/gitlab-org/gitlab/-/issues/347267/designs/Option_2__Alert_during_checkout_informing_user_of_QSR.png), could we reuse for renewal flow?

Link for `How does billing work?`: `https://docs.gitlab.com/ee/subscriptions/quarterly_reconciliation.html` (shared [here](https://gitlab.com/gitlab-org/gitlab/-/issues/347267/designs/Option_2__Alert_during_checkout_informing_user_of_QSR.png#note_828638740))

Story points: 2.0
Remove Customer dependency from Subscription model

### Problem

[The `Subscription` model](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/1d243289b208023d7437ce3d0fa363f8f38454b8/app/models/subscription.rb) is a wrapper model around a `Zuora::Subscription`.  A `Customer` object is required when instantiating a `Subscription` object ([see definition](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/1d243289b208023d7437ce3d0fa363f8f38454b8/app/models/subscription.rb#L68)).  In most places as it relates the model, the `Customer` object is used as a way to reference the `zuora_account_id`.  There are some exceptions to this rule though ([example1](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/1d243289b208023d7437ce3d0fa363f8f38454b8/app/models/subscription.rb#L265), [example2](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/1d243289b208023d7437ce3d0fa363f8f38454b8/app/models/subscription.rb#L384)).

We've seen where dependence on Customer records can be problematic (https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3837, https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2880).  We should look into removing this dependency in Subscription which will help to simplify logic in this model, and also hopefully resolve some data inconsistency problems.

### Proposal

Remove `Customer` as a dependency when initializing a `Subscription` object.

Story points: 5.0
Rename Subscription#previous

### Problem

Currently our Subscription#previous method is overriding IronBank::Subscription#previous method.

* `Subscription#previous`: find the latest older version with an earlier term start date
* `IronBank::Subscription#previous`: find the version before current version

This semantic differences can cause confusion, and can be a source of future bugs.

### Proposal

We should rename the former with a more comprehensive name.

### Result

No behavior change as this is a refactoring

Story points: 2.0
Update text on summary for invalid seat number

The following discussion from !4554 should be addressed:

- [ ] @lmeckley started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4554#note_921532958):  (+3 comments)

    > **question (non-blocking, UX)**: Should we remove the text below `Price` in the `Purchase Summary` when the user has an invalid input? Otherwise we're showing a specific seat number that doesn't necessarily relate to what the user typed in.
    > 
    > ![Screen_Shot_2022-04-22_at_9.48.57_AM](/uploads/5cbafa197db858e0c0a37c49ccdbeeb4/Screen_Shot_2022-04-22_at_9.48.57_AM.png)

## Proposal

Remove the text entirely when the seats count is an invalid number

Story points: 1.0
Maintenance mode - quiet all Sidekiq queues except zuora_health_check

## Problem to solve and proposal

When in maintenance mode, Sidekiq queues are still able to receive jobs. While this is unlikely to happen (as the CustomersDot app would not enqueue new jobs because of the maintenance mode), it would be still good practice to quiet all Sidekiq queues (except the `zuora_health_check` queue) upon having the maintenance mode on, and to have them to reaccept new jobs when the maintenance mode is off.

The `zuora_health_check` queue is the only queue not to quiet as it is tightly coupled to the app maintenance mode: it checks Zuora health periodically and gets the app into (or out of) maintenance mode depending on the Zuora health state.

Story points: 2.0
Gitlab.com Admin API token rotation


A new admin token was generated in https://gitlab.com/gitlab-com/team-member-epics/access-requests/-/issues/20979#note_1297201378

We need to:
- [x] [Update the secret to the new value in ansible](https://gitlab.com/gitlab-org/customersdot-ansible/-/blob/master/doc/readme.md#ansible-vaults-for-customersdot-secrets) before the old token expires (April 2023). Preferably with a couple weeks buffer.
- [x] Create a new issue with a due date some time period (1 month?) before this new token expires.
- [x] Create a new slack reminder with a link to the issue that is triggered before the due date and perhaps triggers multiple times?
- [x] Update docs detailing this process.
- [x] Handoff process to ~"group::fulfillment platform"

Story points: 3.0
Remove subscription name field from manually creating licenses form

### Problem

When manually creating licenses in the Admin area of CustomersDot, there are fields for the subscription name and ID. These fields are optional when creating a legacy license. Hence, the backend logic that checks if the subscription exists in Zuora works when both fields are field or when just one of them are filled. When only the subscription name is filled in, a wrong subscription version can be linked to the license. Whereas the filled in subscription ID will result in linking the correct subscription version is linked to the license.

Gathering some feedback from Support (see [this comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4601#note_919402242) and [this one](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4601#note_920060764)) shows that they have access to SFDC and Zuora and therefore access to the subscription ID AND name. Given this information, asking both the subscription name and ID in the form is obsolete since the subscription ID will be sufficient.

### Proposal

Remove the subscription name field from the form when manually creating licenses. The information can be pulled from the subscription found with the ID and automatically set on license create.

### Result

Removing an obsolete field and ensuring that correct subscription version is linked to the created license.

Story points: 2.0
Only allow eligible community program subscriptions for renewal

Add restrictions to only allow eligible community program plans (listed below) to be renewed:

```
ULTIMATE_SAAS_EDU_1_YEAR
ULTIMATE_SM_EDU_1_YEAR
ULTIMATE_SAAS_OSS_1_YEAR
ULTIMATE_SM_OSS_1_YEAR
```

Attempting to renew any other community program plan using URL (`/subscriptions/community-program/{subscription_id}/renew`) or by accessing renewal landing page (`/subscriptions/community-program/renew`) should redirect to home page.

Story points: 1.0
Use HPM's own actions to adjust height

The following discussion from !4553 should be addressed:

- [ ] @agulina started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4553#note_910290229): 

    > **question (non-blocking)**: would it be possible to leverage the iFrame's own action (example [here](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/84342/diffs#7f5d08a2fb96aaa436ea700da47c90a91d22b5d6_0_139))?
    > 
    > _Edit_: we can also have it for a follow-up.

Story points: 2.0
Evaluate zuora client_id and client_secret env variables in iron bank config

<!-- 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 [exporting schema](https://gitlab.com/gitlab-org/customers-gitlab-com#ironbank) from Zuora for a particular environment, the commands rely on the presence of zuora `client_id` and `client_secret` env variables in the [iron bank config](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/config/initializers/iron_bank.rb#L9).

The [config](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/config/initializers/iron_bank.rb#L9) however checks only for secrets.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Check for presence of zuora `client_id` and `client_secret` env variables in [iron bank config](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/config/initializers/iron_bank.rb#L9) before defaulting to secrets.

### Result

Zuora environment specific operations such as exporting schema will not require resetting secrets.

Story points: 1.0
Always validate the presence of `expires_at` when creating license manually

The following discussion from !4559 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4559#note_910451285):  (+1 comment)

    > **Question:** Now that this validation is being moved to a service that manages license creation only, I wonder if it makes sense to always validate the presence of `expires_at` now, for offline, legacy, or otherwise?  I know we have plenty of legacy licenses without `expires_at`, but didn't we talk about making sure that all new licenses had an expiration going forward?

## Proposal

Always validate the presence of `expires_at` when creating license manually (via the `RailsAdmin::CreateLicenseService`).

Story points: 1.0
Incorrect term dates shown for community program subscription renewal

## Summary

Subscription renewal term is showing today's date plus a year as the new term period. It should instead be from subscription's current term end date until a year from term end date

Both SaaS and SM renewal are affected by this, example below is of SM renewal

![Screen_Shot_2022-04-12_at_4.06.48_PM](/uploads/053093ad1236348358d45f71ef050dd0/Screen_Shot_2022-04-12_at_4.06.48_PM.png)

![Screen_Shot_2022-04-12_at_4.07.26_PM](/uploads/c1c35f1a39767afbb475ea57e2c8d0ba/Screen_Shot_2022-04-12_at_4.07.26_PM.png)

## Steps to reproduce

[Steps to setup community program subscription which is up for renewal](https://gitlab.com/groups/gitlab-org/-/epics/5711#steps-to-setup)

* Visit `/subscriptions/community_program/{subscription_id}/renew` 

## What is the current *bug* behavior?

Renewal term shown is from todays date until a year

## What is the expected *correct* behavior?

Renewal term should be from subscription's current term end date until a year from term end date


## Implementation notes

We can use [`renewal_term`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/c0e53a8b27eec8fce4b4c405cb0d22929f7f23fe/app/helpers/subscription_helper.rb#L14) helper to get the renewal period and wire it up to use from the components.

Story points: 1.0
Create a plan for upgrading to Orders APIs, create issues

## Summary

We need to identify all of the code that utilizes Subscribe / Amend APIs, and create a plan for how we will move to Orders API.

### Documentation

Zuora has the following documentation to guide clients through the migration from Subscribe/Amend APIs to Orders API: https://knowledgecenter.zuora.com/Billing/Subscriptions/Orders/Orders_Harmonization/Orders_Migration_Guidance#Orders_API_Migration_Guidance

Additional documentation can be found here https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/462+

## Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

## Result

All issues are created, added to the [epic](https://gitlab.com/groups/gitlab-org/-/epics/6438), and are ~"workflow::ready for development".

We should also be able to estimate how long the work will take, so that it can inform our progress towards completing project Matterhorn.

## Next steps (if any)

### How will we measure success?

Story points: 3.0
Update method name for to differentiate midterm and renewal upgrades

### Description
For the MR here https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4563, we have introduced a new method `available_gitlab_renewal_upgrades` and renamed `available_gitlab_upgrades` to `available_gitlab_midterm_upgrades`

We check if the order belongs to Saas or EE before providing plans for renewal. If order belongs to Saas plans then `available_gitlab_com_renewal_upgrades` is called and `available_gitlab_ee_renewal_upgrades` if order belongs to SM.

During midterm upgrade we call `available_gitlab_midterm_upgrades` and depending on SaaS and SM order we make calls to `available_gitlab_com_upgrades` and `available_gitlab_ee_upgrades` respectively.


### Proposal

We can update the names `available_gitlab_com_upgrades` to `available_gitlab_com_midterm_upgrades` and update `available_gitlab_ee_upgrades` to `available_gitlab_ee_midterm_upgrades` to have a better nomenclature.

Story points: 1.0
Remove reconciliations feature flag

### Problem

In https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4545#note_898092068, it came up that the [`reconciliations` feature flag](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/60/edit) is quite old and could probably be removed.

The feature flag has been enabled in production for a couple of months now (can't find a comment for a specific date). There are about 8 places in the code that are using the feature flag.

### Proposal

Remove the `reconciliations` feature flag and all related code places from the code. After removing it from the code, delete the feature flag config https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/60/edit.

### Result

Removing a feature flag and technical debt.

Once removed, we can update the feature flag cleanup epic: https://gitlab.com/groups/gitlab-org/-/epics/8672.

Story points: 2.0
User with Maintainer role can start trial for a Group

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label in relevant trackers:

- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=bug
- https://gitlab.com/gitlab-org/customers-gitlab-com/issues?label_name%5B%5D=bug

and verify the issue you're about to submit isn't a duplicate.

Do not include confidential information!
--->

# Bug

## Summary

Normally, only group Owner should be able to start a trial for a group. There's a loophole that allow users with `Maintainer` role to take out a trial for the group without having access to Group Billing page.

## Steps to reproduce

1. User A create a new group ABC
1. User A invite User B as a member of group ABC with `Maintainer` role

As User B

1. Signed into GitLab.com in the browser
1. Navigate to https://about.gitlab.com/free-trial/
1. Click on the `Continue with SaaS` button
1. Fill in the form and click `Continue`
1. See the Ultimate trial provisioned for the group

## What is the current *bug* behavior?

Users with Maintainer role can take out trial for a group.

## What is the expected *correct* behavior?

Only group Owner should be able to take out trial. 

## Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output,
logs, and code as it's tough to read otherwise.)

## Workarounds

(Ways to get around the issue)

## Reported examples

1. https://gitlab.zendesk.com/agent/tickets/279237
1.
1.

<!---
Please add both severity and priority level according to: https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#severity-labels
--->

Story points: 3.0
All SFDC Quotes should be marked as Primary

<!-- 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 current Quote [attributes](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/6601a127323e7fb3826d1a906f369015ef12b814/app/services/salesforce/create_quote_service.rb#L59-75) we send to SFDC do not include the `zqu__Primary__c` field. 

This field is required for an automation to be able to mark Opportunities as `IS EDU / OSS` and since it's currently not set, the automation doesn't update that field for the expected opportunities.

More details in https://gitlab.com/gitlab-com/sales-team/field-operations/systems/-/issues/1976#note_896371050.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

Add `zqu__Primary__c: true` to the Quote [attributes](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/6601a127323e7fb3826d1a906f369015ef12b814/app/services/salesforce/create_quote_service.rb#L59-75).

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Follow-up from "Use customer object from order subscription name"

The following discussion from !4452 should be addressed:

- [ ] @ddavison started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4452#note_885897739):  (+7 comments)

    > Shortening this seems confusing to me. What do you think about using the full word `customer`? 
    > 
    > ```suggestion:-0+0
    >   def subscription(reload: false, customer: customer)
    > ```

Story points: 2.0
[Community Programs Renewal] API changes to renew community program subscriptions

Update subscription API currently doesn't accept coupon codes, therefore can't renew community subscriptions

# Requirements

The API should:

   * Accept coupon code
   * Validate coupon code
       - Should be active
       - Should be one of the generated coupons (should exist in the database) 
       - Shouldn't have been already redeemed
   * Raise a validation error for invalid coupons
   * Renew a community program subscription with a coupon code
   * Mark the coupon code as redeemed once used

We need to make sure standard subscription renewal behaviour is unchanged since the code changes for standard and community program renewals are in the same area

Story points: 2.0
Seat overage notification cannot find subscription when account ID is missing

### Problem

This is a follow up from https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4120+ and is likely dependent on https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4452+.

Currently, for some `Order` records, when we call `order.current_subscription` we get `nil` returned as the `account_id` is blank. 

Qingyu has already done an investigation of this here (https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4120#note_889020095):

> Yes this is a known data integrity issue:
> 
> * `order.customer.zuora_account_id` is `nil`, OR,
> * `order.customer.zuora_account_id` does not match `zuora_subscription.account_id`
>   * NOTE: `zuora_subscription` should purely calculated by `order.subscription_name/subscription_id`. Such as `Zuora::Subscription.find_by(name: order.subscription_name)`.
>   * BTW: We have `order.zuora_account_id` to speed up some queries in certain scenarios. But sadly, I've seen `order.zuora_account_id` is also not maintained correctly sometimes.
> 
> This is a subset of the issue https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1874+.
> 
> AFAIK, the first area we start to fix this problem is: in reconciliation https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3865+
> 
> * this is limited to reconciliation, and,
> * this is just the first iteration in the reconciliation area.
> 
> We believe we can detach `Order` and `Customer` in QSR. For other areas(outside of QSR), we still need to evaluate the impact > as part of https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1874+.


### Proposal

https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4452+ is already being worked on to address this for reconciliation.

Once this is completed, we should be able to call `reconciliation.subscription` rather than [`order.current_subscription`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/3f4a30f72962aa0dbda3dd8f0eed05681262116d/app/services/reconciliations/send_seat_overage_notification_service.rb#L45) in the notification service and benefit from that work here too.

Story points: 2.0