giseldo/neodataset huggingface dataset:
Refinement: Update the Renew button to provide more information

<!-- The first four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. -->

### Problem to solve

The ability to manually renew a subscription is only available starting 15 days prior to the expiration date of the subscription.

Currently, the renew button is disabled until 15 days before the expriration date with a tool tip explaining when the customer will be able to renew.

![Screen_Shot_2022-11-30_at_4.59.23_PM](/uploads/06d9ecd6f1b61cde47a2875103b60a83/Screen_Shot_2022-11-30_at_4.59.23_PM.png)

This has proven to be a confusing experience for customers because they often do not see the tooltip.

Additionally, customer sometimes try to find a way to pay true-ups without knowing that the true-up is paid at the same time as renewal.

### Intended users

Subscription owners/managers in CDot

### User experience goal

Customer know when they can renew and what they can do when they click the `Renew` button once it's available.

### Proposal

<!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey -->

Keep the renew button active at all times, regardless of whether or not the customer has the ability to renew. 

If the ability to renew is not available when they click the `Renew` button, show a modal explaining the renewal window and that they will pay for true-ups at the time of their renewal.

**Note:** We need to promote this issue to an epic and then break it down into smaller issues based on this [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3521#note_1318050870). The [refinement notes](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3521#note_1318042013) can be used for the issue breakdown.

**Design:** [See design section](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3521/designs/Clicking__Renew__when_renew_action_is_not_available.png)

Story points: 1.0
MalformedQueryFault error raised because custom field, collectionsagent__c removed

### Problem

We're seeing some errors related to a malformed Zuora query in CustomersDot production.

- https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/2769584
- https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/2769590
- https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/2769602
- https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/2769599

Looks like the custom field, `collectionsagent__c` was removed from the Account object in Zuora production.

### Proposal

I've reached out to @mquitevis about restoring the field in Zuora production temporarily as we remove the reference from CustomersDot.

Story points: 1.0
Add  documentation to the CustomersDot REST API

### Problem
Current REST API is not documented. To find out what we offer we need to check the code every time.

### Proposal
We could use [swagger](https://swagger.io/) for documentation.

- solves documentation & discoverability problem
- provides sandbox [SwaggerUI](https://swagger.io/tools/swagger-ui/) to allow developer and non developer to interact with APIs
- uses OpenAPI (fka Swagger Specification)

We would like to focus on `/subscription/*` endpoint first as it's the one we work the most at the moment

There is also [rswag](https://github.com/rswag/rswag#getting-started) gem for auto generated docs

#### What are our gains
- clean documentation
- faster lookup of what we have and how to use it
- spec could be used as a draft for future GraphQL endpoint during migration
- faster onboarding of new team members

#### Implementation plan
| Step | Issue |
| ------ | ------ |
| Setup documentation | 👉 you are here |
| Write the actual yaml docs for subscription | :white_check_mark:  https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3667 |

#### What we need to do
**Option A (preferred):** 
- Add openAPI integration https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3509#note_660256083, make sure the authentication works
- Document `/subscription*` routes

**Option B (in case integration doesn't work how it should):**
- add swagger specs & rswag integration (inspiration "https://medium.com/@clarkjohnson_85334/adding-swagger-docs-to-a-rails-6-api-using-rswag-a3e8bc577986)
- add swagger UI (documentation)

Both steps are critical because just documenting won't help in better discoverability

### How will we measure success?
Checking on "can we query X from CustomersDot" will become a trivial 5-minutes task

Story points: 5.0
Add 'Trial' indication in license list

For the investigation of license problems for customers with multiple subscriptions or a lot of historical changes, having as much info as possible available up front in the license list helps in narrowing down which license details need to be looked at. \
It would help if an indication was added showing if a license is a trial.

### 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 -->

A frontend test should accompany this change to ensure that the indication is correct depending on the trial status.

- If License is not trial, do not show the indication.
- If License is trial, show the indication.

Story points: 1.0
New Trial Plans Do Not Expire Properly

After we enable the `trial_plans` flag in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3378, trial plans will be created with their own plan - `ultimate_trial` instead of `ultimate`.

The new trial plans do not expire appropriately like the old plans do.

## Steps to reproduce

1. Create an ultimate trial using the current plans.  So that you have an `ultimate` trial plan.  (Not an `ultimate_trial` trial plan)

1. Enable the `trial_plans` and the `deprovision_newly_expired_subscriptions` feature flags for your local development environment.

1. Create an ultimate trial again.  This plan should end up with an `ultimate_trial` plan, because the `trial_plans` flag is enabled.  (`deprovision_newly_expired_subscriptions` is related to the `ExpireOrderCronJob` worker which comes into play later)

1. Open the billing pages for both plans.  In the screenshots below, we can see that both New Trial Group (`ultimate`) and Eric Group (`ultimate_trial`) have Ultimate Trial plans set to expire in the future.

New Trial Group (`ultimate`)

![Screen_Shot_2021-08-17_at_5.29.58_PM](/uploads/790932fb0dbc0b0b258f9df218ecc2ae/Screen_Shot_2021-08-17_at_5.29.58_PM.png)

Eric Group (`ultimate_trial`)

![Screen_Shot_2021-08-17_at_5.29.48_PM](/uploads/d11c2c54611f98bfb0b4758ad7e78f0a/Screen_Shot_2021-08-17_at_5.29.48_PM.png)


5. Set the system clock forward to a date after the Ultimate Trial expiry date.  In the running example, this would be any date after 2021-09-12.

![Screen_Shot_2021-08-17_at_5.35.03_PM](/uploads/0fb21e03bd7b66113da417e30a5948b0/Screen_Shot_2021-08-17_at_5.35.03_PM.png)

6. Wait briefly for the [`ExpireOrderCronJob`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/6d58fe82c4780841bea2c3f56b93f601e93274a0/app/jobs/expire_order_cron_job.rb) to run.  Refresh the browser and observe what happens to each trial plan.  See the screenshots below.  New Trial Group (`ultimate`) shows that it is expired and we can see from the lack of an "Epics" menu item that the Ultimate features have been withdrawn.  However, Eric Group (`ultimate_trial`) shows an error from CustomersDot and the Ultimate Trial features are still present, as evidenced by the "Epics" menu item.

New Trial Group (`ultimate`)

![Screen_Shot_2021-09-17_at_5.37.57_PM](/uploads/c40eea34357959deb70ce02aa2f3a6e7/Screen_Shot_2021-09-17_at_5.37.57_PM.png)

Eric Group (`ultimate_trial`)

![Screen_Shot_2021-09-17_at_5.37.40_PM](/uploads/7ff362412515791521cc107e24faf52b/Screen_Shot_2021-09-17_at_5.37.40_PM.png)

Story points: 1.0
Add confirmation dialog to 'Resend to customer via email' icon from cloud activation and license list

LicenseDot has a `Resend to customer via email` button on the license details page. \
In CustomersDot this functionality is now available as an icon in the license list. \
As the icon is tiny, amidst several other icons, and the resending is immediate, accidental resends will happen.

~~Either move the functionality to a button on the license details page~~, or add a confirmation dialog. \
Edit: button is already present on the license details page.

Story points: 2.0
Allow manual entry of dates in CustomersDot datepicker

## Summary

The `New Offline License` and `Duplicate license` forms in CustomersDot have a datepicker that doesn't seem to accept manual entry of dates. \
We often copy/paste or type dates in ISO 8601 format, in addition to clicking around in the calendar to pick the date.

## Proposal

Add ability to paste a date from a user's clipboard.

Story points: 3.0
Show 'Previous Users Count' and 'Trueup Count' in CustomersDot's list of licenses

Recently LicenseDot was improved by showing the `Previous Users Count` and `Trueup Count` in addition to `Users Count` in the list at https://license.gitlab.com. \
This proves to be very useful while investigating license problems. \
By looking at the values in the list you know which licenses are worth including in the investigation and which are not.

CustomersDot's license list at https://customers.gitlab.com/admin/license only shows `Users Count`. \
Please add `Previous Users Count` and `Trueup Count`.

Story points: 1.0
Inform Sales of limitation when disabling cloud license

For https://gitlab.com/gitlab-org/gitlab/-/issues/337958 we created a temporary fix, however there can be an edge case: 

> especially for customers that have multiple instances. Say we have a customer who originally activated using cloud and later wants to use offline licenses. Support or Sales manually updates the Zuora subscription with `TurnOnCloudLicensing__c` as "No", and provides the customer with an offline license. Say the customer does not install the license immediately, the Zuora subscription might be reverted back to `TurnOnCloudLicensing__c` as "Yes". Those with multiple instances would need to make sure all had an offline license applied before seat link ran again.

@teresatison do you know how we can communicate with Sales/Support that, if we ever want to revert from cloud license back to offline license, the offline license must be applied before seat-link occurs, and **on all instances**?

Our temporary fix will be removed after 1-2 month, after that Sales/Support will no longer need to worry about this.

Story points: 0.0
Renewal license has 'Previous users count' set to 'Users count'

### Summary

A renewal license was generated with an incorrect `Previous users count`. \
The `Previous users count` happens to be the same as the `Users count`. \

This could be a coincidence, but I recall someone recently mentioning a similar incorrect renewal. \
Could not find an issue for it though.

### Workaround

Manually create a license with the correct numbers.

### Reported examples

1. https://customers.gitlab.com/admin/license/1000674
1. https://gitlab.zendesk.com/agent/tickets/232843, https://customers.gitlab.com/admin/license/1000852
1. https://gitlab.zendesk.com/agent/tickets/242306, https://customers.gitlab.com/admin/license/1003353
1. https://gitlab.zendesk.com/agent/tickets/237329, https://customers.gitlab.com/admin/license/1003239
1. https://gitlab.zendesk.com/agent/tickets/242071, https://customers.gitlab.com/admin/license/1003463
1. https://gitlab.zendesk.com/agent/tickets/242947, https://customers.gitlab.com/admin/license/1004046
1. https://gitlab.zendesk.com/agent/tickets/251300, https://customers.gitlab.com/admin/license/1008102
1. https://gitlab.zendesk.com/agent/tickets/255564, https://customers.gitlab.com/admin/license/1010903
1. https://gitlab.zendesk.com/agent/tickets/258317, https://customers.gitlab.com/admin/license/1012418
1. https://gitlab.zendesk.com/agent/tickets/261120, https://customers.gitlab.com/admin/license/1014650
1. https://gitlab.zendesk.com/agent/tickets/279611

<!---
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
[UX] Information Hierarchy and General Layout for Support Admin Tool

## User Story

As a product owner, I want to map current user flows and object domains in CustomersDot Admin Support Tool to help design and improve the information hierarchy and layout for users.

## Deliverables

- IA Documentation
- List of user flows 
- Conduct interviews with Support tooling users
- UX Scorecards on user JTBD (Still to be defined)

Story points: 5.0
Exclude trials from deletion of groups/namespaces when they have a subscription

### Problem

After the implementation of https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1879 , users can no longer delete a group while there is a trial.

However, unlike a regular subscription, trials cannot be removed from a group. So a user must wait 30 days for the trial to expire before having the option to delete the group.

While it's not a complete blocker, it is a significant inconvenience for users. If they want it deleted earlier, they have to write into support, who can change the trial expiration date.

Just for reference, we encountered this while wanting to test: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/66951

### Proposal

Exclude trials from the subscription check for deletion of groups/namespaces. If needed, we can wait until the trial specific plans `ultimate_trial` and `premium_trial` are in use.

### Result

Users should be able to delete trial-only namespaces.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Prod gitlab_customers_dot_jwt_public_key not populating

Related to https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3000

For some reason, `gitlab_customers_dot_jwt_public_key` is not populating in `secrets.yml` for production. It is for staging. 

template updates: https://gitlab.com/gitlab-cookbooks/cookbook-customers-gitlab-com/-/merge_requests/133  
vault values: https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/13949

Story points: 1.0
Unify property names for CI Minutes and Storage

While working on !3689 we figured out that we use `productNameFull` and not `productName` in a majority of places withing addons purchase flow. `productName` is only used once for purchase success notification.

- [ ] @sheldonled started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3689#note_648238773):  (+4 comments)

    > **question**: can we unify `productName`, `productNameFull`, `productNameShorthand` into just `productName`?

## Suggestion

1. Remove the `productName` from the https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/frontend/javascripts/purchase/products.js
1. Update all usages of `productName` to use `productNameFull`
1. Rename `productNameFull` into `productName`

## Visual changes that would be caused this way

No visual changes for CI Minutes, only Storage

| Before (Storage) | After (Storage) |
| ------ | ------ |
| ![Screenshot_2021-08-11_at_18.10.48](/uploads/57d3bbc5c53730a28f7f71c79735b46f/Screenshot_2021-08-11_at_18.10.48.png) | ![Screenshot_2021-08-11_at_18.12.47](/uploads/0e571ae3fa7a9ce8c341d744c52a2ecb/Screenshot_2021-08-11_at_18.12.47.png)|

Story points: 1.0
Update Storybook setup

<!-- 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
Storybook has an outdated setup and is not widely used for dev/design topics rather for test runs.

### Proposal
We can get more out of the tool, it offers a great dev environment for isolated components. It can be used together by designer and developer to check components before they land in staging/production.

To achieve it, we could introduce a couple of addons that make developers lives easier. As a minimum, we should consider adding [essential addons](https://storybook.js.org/docs/vue/essentials/introduction) (especially [controls](https://storybook.js.org/docs/vue/essentials/controls) that offers dynamic props change). These addons are already used by `gitlab` project.

Also, it's time to migrate the setup to use `main.js`, `preview.js` and add postcss-addon on top. It would not only remove the deprecation warnings but make us ready for Storybook 7 (most likely to be released in 2021).

### Next steps (if any)
If we cover the two topics above, we can consider updating the old and/or building new stories utilizing mentioned addons and involving designers to check/test components and pages in Storybook.

Story points: 2.0
CI Minutes Provisioning - Trigger namespace change

### Establish CI Minute Purchase Identifiers on GitLab

The following outlines requirements from the architecture proposal as defined in !3142, we've split up the tasks into separate issues along system boundaries.

**Base components**

* [x] Add a table in the GitLab DB: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/62393

**API (re-)Sync components**

* [x] Create a new endpoint that moves packs: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/64212

**Support Namespace Changes**

* [x] Trigger an update of the namespace ID via the endpoint added above :point_left_tone3: **we are here**


### Testing and verification

As part of this work, we have put https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2925 behind a feature flag until this issue is complete. We will need to verify both flows (new purchases and namespace changes) are applied correctly once this work is complete and the feature flag enabled.

Story points: 5.0
Remove version check when setting Super Sonics flags processing renewal amendments

### Problem

As described in [this thread](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3034#note_639971420):

> Just to summarize where we are now, we decided that for renewals to be eligible for cloud licensing we would check a number of factors ([defined here in code](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/b7ab6e6ec6167bfae68f5cd045e245bb7500c0c3/app/workers/zuora_callback_worker.rb#L113)) when processing the renewal amendment callout. The one that I'm wondering about is the gitlab version check. This check works by querying for the latest seat link record for the subscription where the gitlab version is available, and compares this version to the minimum version requirement for cloud licensing (14.1).
>
> I think this is a problem because after we decided on this path, we later decided to no longer send seat link data from GitLab starting on version 14.1 unless the SM instance did has a license with cloud licensing enabled. I don't see how any renewal would be eligible for cloud licensing given we won't receive the version data for 14.1.
> 
> Now that we are rolling out with both types of licenses (offline and cloud), I wonder if we shouldn't just remove the GitLab version requirement altogether. Before we were concerned about forcing customers into the cloud license strategy that they weren't prepared for, but that shouldn't matter now.
>
> It has some nice side benefits as well like:
>
> 1. Gets more people with the option of cloud licensing.
> 1. Might entice more customers to upgrade their GitLab version when renewing.
> 1. Removes a query against the LicenseSeatLink table which probably won't be performant over time.
> 1. Makes the code cleaner.

### Proposal

Remove [the GitLab version check](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/7c54a467dcecf386814d5d9e524c98b6be87dc07/app/workers/zuora_callback_worker.rb#L118) that happens in the `ZuoraCallbackWorker` as part of the logic to decide whether the subscription should have the Super Sonics custom fields set at renewal.

Story points: 1.0
Downloading a license results in a new license being generated

<!---
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!
--->

### Summary

Each time a license is downloaded from the `Customers Portal > Manage purchases` screen, a new license is generated.

### Steps to reproduce

- Go to `Customers Portal > Manage purchases` screen
- Use the `Download license` button to download the license file. Do this twice.
- Observe in https://customers.gitlab.com/admin/license that the license was created twice. Inspecting the details page will show a different digest and key.
- Decoding the downloaded files will show that the information is the same in both files.

### What is the current *bug* behavior?

Each time a license is downloaded from the `Customers Portal > Manage purchases` screen, a new license is generated.

Possibly relevant is that for the subscription where I observed this behavior the existing license was present in LicenseDot, but not yet in CustomersDot.

### What is the expected *correct* behavior?

Each time a license is downloaded from the `Customers Portal > Manage purchases` screen, the existing license is returned.

### 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.
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: 2.0
[FE] Validate activation code length on frontend

### Problem

Many tried to pass the license file as an activation code during Cloud License activation. License files are all very long while activation codes are a length of 24 characters.

### Proposal

- We should validate the length of the activation code in the front end. This can quickly help customers to understand that they have entered the wrong thing in the activation code field.
- We should also include some help text underneath the activation input field...<br>`This activation code is a 24-character alphanumeric string.`

![Frame_21](/uploads/cb9dba022be5e8210672911422124b18/Frame_21.png)

### Result

- Customer can learn about mistakes more quickly.
- Reduce errors on sentry

Story points: 1.0