giseldo/neodataset huggingface dataset:
Unable to save credit card validation due to name length

## Problem

https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/2988223/?referrer=gitlab_plugin

Specific event: https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/2988223/events/58585295/


```
Stacktrace (most recent call first):

  lib/gitlab/logger_helpers.rb:24:in `public_send'
    Gitlab::Logger.public_send(log_level, object, options) # rubocop:disable GitlabSecurity/PublicSend
  lib/gitlab/logger_helpers.rb:24:in `log'
    Gitlab::Logger.public_send(log_level, object, options) # rubocop:disable GitlabSecurity/PublicSend
  lib/gitlab/logger_helpers.rb:13:in `log_error'
    log(:error, error, extra: extra)
  app/services/zuora_callbacks/credit_card_validation_service.rb:60:in `mark_valid_cc_for_user'
    log_error(
  app/services/zuora_callbacks/credit_card_validation_service.rb:18:in `execute'
    mark_valid_cc_for_user
  app/controllers/zuora_callbacks_controller.rb:26:in `credit_card_validation'
    ).execute
  lib/middleware/maintenance.rb:25:in `call'
    @app.call(env)
  lib/middleware/health_check/health_check_responder.rb:14:in `call'
    return @app.call(env) if format.nil? || (ip_blocked(env) && not_authenticated(env))
...
(78 additional frame(s) were not displayed)

unable to save credit card validation
```

Kibana: https://log.gprd.gitlab.net/goto/a59f573cb130fe1b14eee41e521714cf

## Proposal

Update character constraint on Credit Card Holder Name from 26 to 50

## Implementation Plan

Update this area of code from `26` to `50` https://gitlab.com/gitlab-org/gitlab/-/merge_requests/71032#note_692224348

Story points: 3.0
Git push fails due to 10GB project size limit even additional storage is available

<!---
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

A customer pre-purchase Additional storage for their group namespace while none of the project under the namespace has reached the 10GB limit. When the customer try to do git Push which cause the project to go above the 10GB limit, the push is rejected.

## Steps to reproduce

1. Purchase Additional Storage for a namespace when none of the project has reach the limit yet
1. Do a git push to the project that would cause the project to go above the 10GB limit
1. Observe the push being rejected

## What is the current *bug* behavior?

Git push is rejected even though there's additional storage available for the group that the project is under.

## What is the expected *correct* behavior?

Git push command should come through when there's additional storage available.

## 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.)

```
batch response: Your push has been rejected, because this repository has exceeded its size limit of 10 GB by 660 MB. Please contact your GitLab administrator for more information.
Uploading LFS objects: 0% (0/30), 0 B | 0 B/s, done.
```

## Workarounds

Reach out to support so we can manually change the limit as a workaround.

## Reported examples

1. https://gitlab.zendesk.com/agent/tickets/248670
1. https://gitlab.zendesk.com/agent/tickets/254399
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
Send Future subscription info thru seat link

### Problem

In https://gitlab.com/gitlab-org/gitlab/-/issues/338657 we need to display future subscription information in self managed instance.

### Proposal

We pass future subscription information through seat link to the self managed instance.

### Result

### Next steps (if any)

https://gitlab.com/gitlab-org/gitlab/-/issues/338657

### How will we measure success?

Story points: 2.0
OH Testing: UC-9

## Summary

This is a specific testing issue for use case 9 on https://gitlab.com/groups/gitlab-org/-/epics/6606

### Testing DRIs

|Tester ID | Tester Name | Status |
|:---:|---|---|
| 1 | @tyleramos | :white_check_mark: @tyleramos |
| 2 |  |  |

### UC-9: SaaS Subscription created through sales-assisted order

| Step ID | Test Step   | Description | Expected Outcome | Testable? | Pass/Fail |
|---------|--------|----|----------|:---:|:---:|
| T-1     | Login to Zuora | Login to Zuora Central Sandbox and go to the [Customer Account list](https://test.zuora.com/apps/CustomerAccount.do?menu=Z-Billing). Search for the customer account you use in customers.staging.gitlab.com by email address and click on the Customer Account. | On the Customer Account Page | N | |
| T-2     | Prep a Zuora Order | From the Customer Account page, click on the "Create Order" button from the Customer Account page. Click the "Create Subscription" button. Leave the default settings except set the following custom fields in Zuora to `Yes`: `Contract Auto Renew`, `Contract Seat Reconciliation`, `Turn On Seat Reconciliation`, `Turn on Auto Renew`.  Click the "Continue" button. | On the screen to pick Products and Charges. | N | |
| T-3     | Select the Product | From the Products screen, search for "SaaS - Ultimate" and expand the list of Charges.  Check the box for "SaaS - Ultimate - 1 Year". Click the "Add Product" button at the bottom of the page. Click the "Review Order" button. If all looks good, click the "Activate" button. | A completed Order which created a subscription with the SaaS Ultimate 1 yr plan. | Y | |
| T-4     | Receive email with setup instructions | Receive an email from CustomersDot with instructions for completing the setup of the subscription by selecting the group to associate with the subscription. | The email should contain instructions for assigning a group to the subscription. | Y | |
| T-5     | View subscription details | Navigate to the "Manage Subscription" page in CustomersDot staging to verify the subscription details are accurate. | Subscription details show the correct Start date, Purchase date, Product, and Quantity. | Y | |

Story points: 1.0
OH Testing: UC-8

## Summary

This is a specific testing issue for use case 8 on https://gitlab.com/groups/gitlab-org/-/epics/6606

### Testing DRIs

|Tester ID | Tester Name | Status |
|:---:|---|---|
| 1 | @tyleramos | :white_check_mark: Completed & Passed |
| 2 | @a_luna | :white_check_mark: Completed & Passed |

### UC-8: SM Subscription created through sales-assisted order

| Step ID | Test Step   | Description | Expected Outcome | Testable? | Pass/Fail |
|---------|--------|----|----------|:---:|:---:|
| T-1     | Login to Zuora | Login to Zuora Central Sandbox and go to the [Customer Account list](https://test.zuora.com/apps/CustomerAccount.do?menu=Z-Billing). Search for the customer account you use in customers.staging.gitlab.com by email address and click on the Customer Account. | On the Customer Account Page | N | |
| T-2     | Prep a Zuora Order | From the Customer Account page, click on the "Create Order" button from the Customer Account page. Click the "Create Subscription" button. Leave the default settings except set the following custom fields in Zuora to `Yes`: `Contract Auto Renew`, `Contract Seat Reconciliation`, `Contract Operational Metrics`, `Turn On Seat Reconciliation`, `Turn on Auto Renew`, `Turn On Operational Metrics`.  Click the "Continue" button. | On the screen to pick Products and Charges. | N | |
| T-3     | Select the Product | From the Products screen, search for "Self-Managed - Ultimate" and expand the list of Charges.  Check the box for "Self-Managed - Ultimate - 1 Year". Click the "Add Product" button at the bottom of the page. Click the "Review Order" button. If all looks good, click the "Activate" button. | A completed Order which created a subscription with the SM Ultimate 1 yr plan. | Y | |
| T-4     | Receive email with legacy license and activation code | Receive the activation code and legacy license key via email. | The email should contain an activation code and the legacy license key. | Y | |
| T-5     | View subscription details | Navigate to the "Manage Subscription" page in CustomersDot staging to verify the subscription details are accurate.  Verify the activation code is shown and can be copied. Verify you can download the license file.  | (1) Subscription details show the correct Start date, Purchase date, Product, and Quantity (1). <br><br> (2) The Activation Code is shown and can be copied to clipboard. <br><br> (3) License file can be downloaded. | Y | |

Story points: 1.0
OH Testing: UC-6

## Summary

This is a specific testing issue for use case 6 on https://gitlab.com/groups/gitlab-org/-/epics/6606

### Testing DRIs

|Tester ID | Tester Name | Status |
|:---:|---|---|
| 1 | @tyleramos | :white_check_mark: Completed & Passed |
| 2 |  |  |

### UC-6: Customer upgrades an existing SM subscription

| Step ID | Test Step   | Description | Expected Outcome | Testable? | Pass/Fail |
|---------|--------|----|----------|:---:|:---:|
| T-1     | Purchase SM Premium for 5 users | Navigate to the purchase page for Premium SM 1 year subscription.  To make this easier given the plans page is no longer available in staging, [here is a shortcut to the purchase page](https://customers.staging.gitlab.com/subscriptions/new?plan_id=2c92a01176f0d50a0176f3043c4d4a53). | Purchase flow is successful. The success modal should have a link to activation instructions and a link to the newly created subscription. | Y | |
| T-2     | View subscription details | Navigate to the "Manage Subscription" page in CustomersDot staging to verify the subscription details are accurate. | Subscription details show the correct Start date, Purchase date, Product (Premium), and Quantity (5). | Y | |
| T-3     | Upgrade the subscription | From the Manage Subscriptions page in CustomersDot staging, click the "Upgrade" button. Change the plan to Ultimate and confirm the purchase. | Purchase flow is successful. | Y | |
| T-4     | Receive the renewal email with legacy license and activation code | Receive the activation code and legacy license key via the email. | The email should contain an Ultimate license with the same activation code as before but the legacy license key should be new. | Y | |
| T-5     | View subscription details | Navigate to the "Manage Subscription" page in CustomersDot staging to verify the subscription details are accurate. | Subscription details show the correct Start date (in 2021), Purchase date (in 2021), Product (Ultimate), and Quantity (5). | Y | |

Story points: 1.0
OH Testing: UC-7

## Summary

This is a specific testing issue for use case 7 on https://gitlab.com/groups/gitlab-org/-/epics/6606

### Testing DRIs

|Tester ID | Tester Name | Status |
|:---:|---|---|
| 1 | @tyleramos | :white_check_mark: Completed & Passed  |
| 2 |  |  |

### UC-7: Customer upgrades an existing SaaS subscription

| Step ID | Test Step   | Description | Expected Outcome | Testable? | Pass/Fail |
|---------|--------|----|----------|:---:|:---:|
| T-1     | Find a group in https://staging.gitlab.com/ with an existing plan subscription | Find a group that already has a plan. If you do not have one, you can follow steps 1-4 of [use case 2](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3790).  You can check the group plan by navigating to Settings -> Billing. | The Billing page shows a Group that is currently on Premium and able to be upgraded to Ultimate.  | Y | |
| T-2     | Upgrade plan to Ultimate | Click on the Upgrade button for Ultimate. Fill in the form and confirm the purchase. | Purchase flow is successful. | Y | |
| T-3     | View subscription details | Navigate to the "Manage Subscription" page in CustomersDot staging to verify the subscription details are accurate.  | Subscription details show the correct Start date, Purchase date, Product (Ultimate), and Quantity. | Y | |
| T-4     | View Billing page | Navigate to Group's Billing page in staging.gitlab.com. | The Group should be shown as "currently using the Ultimate SaaS Plan (Formerly Gold)". | Y | |

Story points: 1.0
OH Testing: UC-4

## Summary

This is a specific testing issue for use case 4 on https://gitlab.com/groups/gitlab-org/-/epics/6606

### Testing DRIs

|Tester ID | Tester Name | Status |
|:---:|---|---|
| 1 | @tyleramos | :white_check_mark: Completed & Successful |
| 2 |  |  |

### UC-4: Customer renews an existing SM subscription

| Step ID | Test Step   | Description | Expected Outcome | Testable? | Pass/Fail |
|---------|--------|----|----------|:---:|:---:|
| T-1     | Purchase SM Premium for 5 users | Navigate to the purchase page for Premium SM 1 year subscription.  To make this easier given the plans page is no longer available in staging, [here is a shortcut to the purchase page](https://customers.staging.gitlab.com/subscriptions/new?plan_id=2c92a01176f0d50a0176f3043c4d4a53). | (1) Purchase flow is successful. The success modal should have a link to activation instructions and a link to the newly created subscription. <br><br> (2) The following custom fields in Zuora are set to `Yes`: `Contract Auto Renew`, `Contract Seat Reconciliation`, `Contract Operational Metrics`, `Turn On Seat Reconciliation`, `Turn on Auto Renew`, `Turn On Operational Metrics` <br><br> (3) The following custom fields in Zuora are not set: `Turn On Cloud Licensing` | Y | |
| T-2     | View subscription details | Navigate to the "Manage Subscription" page in CustomersDot staging to verify the subscription details are accurate.  Verify the activation code is shown and can be copied. Verify you can download the license file.  | (1) Subscription details show the correct Start date, Purchase date, Product, and Quantity (5). <br><br> (2) The Activation Code is shown and can be copied to clipboard. <br><br> (3) License file can be downloaded. | Y | |
| T-3     | Renew the subscription | From the Manage Subscriptions page in CustomersDot staging, click the "Renew" button. Change the plan to Ultimate, change Active users from 5 to 6, and confirm the purchase. | Purchase flow is successful. | Y | |
| T-4     | Receive the renewal email with legacy license and activation code | Receive the activation code and legacy license key via the renewal email. | The email should contain the same activation code as before but the legacy license key should be new.  The user limit in the email should now show 6. The now Ultimate license should start in 2022 and expire in 2023. | Y | |
| T-5     | View subscription details | Navigate to the "Manage Subscription" page in CustomersDot staging to verify the subscription details are accurate. | (1) Subscription details show the correct Start date (in 2022), Purchase date (in 2021), Product (Ultimate), and Quantity (6). <br><br> (2) The next renewal date is in 2023. | Y | |

Story points: 1.0
OH Testing: UC-3

## Summary

This is a specific testing issue for use case 3 on https://gitlab.com/groups/gitlab-org/-/epics/6606

### Testing DRIs

|Tester ID | Tester Name | Status |
|:---:|---|---|
| 1 | @tyleramos | :white_check_mark: Completed & Passed |
| 2 |  |  |

### UC-3: Customer purchases an Add-on subscription

| Step ID | Test Step   | Description | Expected Outcome | Testable? | Pass/Fail |
|---------|--------|----|----------|:---:|:---:|
| T-1     | Find or create a group in https://staging.gitlab.com/ | Either find a group that does not already have a plan or create a new one on https://staging.gitlab.com/.  You can check the group plan by navigating to Settings -> Billing. | The Billing page shows a Group is able to be upgraded to Premium or Ultimate.  | Y | |
| T-2     | Purchase additional Storage | Navigate to Settings -> Usage quotas in staging.gitlab.com for your Group. Click on the tab for "Storage", then click the link to "Purchase more storage". Fill in the form leaving quantity at 1 and confirm the purchase. | Purchase flow is successful. | Y | |
| T-3     | View subscription details | Navigate to the "Manage Subscription" page in CustomersDot staging to find a new subscription was created and verify the subscription details are accurate.  | Subscription details shows a single product for "Gitlab Storage 10GB - 1 Year" under the subscription, with the correct Start date, Purchase date, Product, and Quantity (1). | Y | |
| T-4     | View Usage Quotas page | Navigate to Settings -> Usage quotas in staging.gitlab.com for your Group. Click on the tab for "Storage". | The Group should have additional storage available after the purchase (10 GiB). | Y | |
| T-5     | Purchase additional Storage | Navigate to Settings -> Usage quotas in staging.gitlab.com for your Group. Click on the tab for "Storage", then click the link to "Purchase more storage". Fill in the form leaving quantity at 1 and confirm the purchase. | Purchase flow is successful. | Y | |
| T-6     | View subscription details | Navigate to the "Manage Subscription" page in CustomersDot staging to find the subscription from earlier and verify the subscription details are accurate.  | Subscription details now shows 2 products, each for "Gitlab Storage 10GB - 1 Year" under the subscription, with the correct Start date, Purchase date, Product, and Quantity (1). | Y | |
| T-7     | View Usage Quotas page | Navigate to Settings -> Usage quotas in staging.gitlab.com for your Group. Click on the tab for "Storage". | The Group should have additional storage available after the purchase (20 GiB). | Y | |

Story points: 1.0
QSR Amendment.Name Process + Orders API

### Problem

Quarterly Subscription Reconciliation (QSR) and Auto-Renewal amendments are currently being identified in Zuora by by populating Amendment.Name with the following:

1. `Automated seat reconciliation` - for QSR
2. `AutoRenew by CustomersDot` - for Auto-Renewal

These Amendment Names are also being used to identify invoices related to QSR and Auto-Renewal.

With the full transition to Zuora Orders, the Amendment object is being replaced by the Order objects.  As part of this epic https://gitlab.com/groups/gitlab-org/-/epics/8665+, we will stop using Amendments to make subscription changes.  Therefore, we need a way to identify QSR and Auto-Renewal on the Order and Invoice objects.

### Proposal

1. **Transitioning from Amendment.Name:** use the `Order.Description` field when we transition to Orders API. This will be sufficient in identifying Orders that are generated from the QSR/Auto-Renewal processes, even if multiple order actions are utilized in the auto-renewal process. (this issue).
    - [x] QSR: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3784 (this issue)
    - [x] Auto renewal: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5017 
2. **Traversing from Order to Invoice**: to ensure a completely accurate 1:1 relationship between Order and Invoice, we should stamp the Invoice with a value to identify QSR/Auto-Renewal. (epic: https://gitlab.com/groups/gitlab-org/-/epics/8898)

### Result

Orders and Invoices related to QSR and Auto-Renewal are easy to identify in Zuora.

### Next steps (if any)


### How will we measure success?

Story points: 2.0
Use constants for amendment types consistently

## Proposal

Amendment types are referenced inconsistently throughout the CustomersDot code.  There is an `Amendment::Types` module where type constants are defined and these constants are used in some places.  There are different constants defined in `AmendGenerator`.  In many other places, strings are used instead of constants.  Let's update CustomersDot to reference one set of constants if possible.  It probably makes sense to define all the possible constants in `Amendment::Types`.

## Original discussion

The following discussion from !4063 should be addressed:

- [ ] @cwiesner started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4063#note_729757014):  (+1 comment)

    > **thought (non-blocking):** I wonder if it makes sense to move these strings into constants :thinking: If I understand it correctly, these are similar to the ones defined in `Zuora::Order` ([here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/3a3804e1fc1aa8d74a3c4b12d4c509fc82232af0/lib/zuora/order.rb#L13)), right?
    > 
    > Here's also the usage of `Amendment::Types::NEW_SUBSCRIPTION`. So do you think there's a single place to define all of these? :thinking:

Story points: 2.0
Allow Support team to create Starter temporary licenses in CustomersDot

<!-- 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
After the implementation of [[BE, FE] Improve trial license generation user experience in CustomersDot (#101)](https://gitlab.com/gitlab-org/license-gitlab-com/-/issues/101) it is no longer possible to create Starter trial licenses. \
This makes sense for (potential) customers as the Starter plan is being phased out, and no longer available as a new subscription. \
The L&R Support team however has to create temporary Starter licenses on a very regular basis, to help out customers that are still on Starter and experiencing problems during renewal. At the request of the Sales team or by L&R Support's own initiative a temporary license is provided to ensure continuity.

### Proposal

Re-instate the ability to generate a trial starter plan in Customers Portal app for the L&R Support team.

Note: Teresa: I'm thinking it's a simple rollback but please let me know if not.

### Result
The L&R Support team can create Starter temporary licenses again.

### Next steps (if any)

### How will we measure success?
Happy customers, happy L&R Support team, happy Sales team.

### Reported examples

1. gitlab-com/support/internal-requests#10827
1. gitlab-com/support/internal-requests#11084
1. gitlab-com/support/internal-requests#11581
1. https://gitlab-federal-support.zendesk.com/agent/tickets/2051
1. gitlab-com/support/internal-requests#11851
1. gitlab-com/support/internal-requests#11943
1. gitlab-com/support/internal-requests#11944
1. https://gitlab-federal-support.zendesk.com/agent/tickets/2106
1. https://gitlab.zendesk.com/agent/tickets/260553

Story points: 2.0
Generate API specs with running requests test traffic through Optic

We can automate REST API documentation by running our requests tests and documenting the resulted diff with Optic.

@jameslopez has a fork of the middleware that could get handy for proxying test traffic https://github.com/bluegod/ruby-rack-fixture/tree/fix-readme

Dev notes:

To add a gem

```
gem 'optic-middleware', git: 'git@github.com:bluegod/ruby-rack-fixture.git', branch: 'fix-readme'
```

and follow https://github.com/bluegod/ruby-rack-fixture/tree/fix-readme documentation

Story points: 2.0
Follow-up from "Update Staging documentation with relevant user"

The following discussion from !4050 should be addressed:

- [ ] @ebaque started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4050#note_724226215):  (+1 comment)

    > @cmcfarland As part of user provisioning process, would it be possible to add `/home/fulansdep/.rbenv/shims` to `fulansdep`'s `PATH` please? Or should I just simply add that in `fulansdep`'s dotfiles manually on the server?
    > 
    > That would make running rake tasks on Staging a bit more easier.

Story points: 2.0