giseldo/neodataset huggingface dataset:
Subscriptions buttons spec ToolTip needs fixing

The following discussion from !1983 should be addressed:

- [ ] @dreedy started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1983#note_418325959):  (+3 comments)

    > **question:** I’m a little confused by the description & setup of this test. Are we actually testing what the description says?
    > 
    > > when `hasSeatLinkData` is `true`
    > 
    > ```ruby
    > factory({ /*…*/ hasSeatLinkData: false})
    > ```

The spec in question is broken in it's current state. It needs some setup code to be able to assert on the tooltip it is supposed to be asserting on.

```
diff --git a/spec/frontend/subscription/components/subscription_buttons_spec.js b/spec/frontend/subscription/components/subscription_buttons_spec.js
index f350736d..2f38f2e2 100644
--- a/spec/frontend/subscription/components/subscription_buttons_spec.js
+++ b/spec/frontend/subscription/components/subscription_buttons_spec.js
@@ -327,8 +327,44 @@ describe('SubscriptionButtons', () => {
         });

         describe('when hasSeatLinkData is true', () => {
+          const originalCreateRange = document.createRange;
+          const origGetBCR = Element.prototype.getBoundingClientRect;
+
+          beforeEach(async () => {
+            // https://github.com/FezVrasta/popper.js/issues/478#issuecomment-407422016
+            // Hack to make Popper not bork out during tests.
+            // Note popper still does not do any positioning calculation in JSDOM though.
+            // So we cannot test actual positioning... just detect when it is open.
+            document.createRange = () => ({
+              setStart: () => {},
+              setEnd: () => {},
+              commonAncestorContainer: {
+                nodeName: 'BODY',
+                ownerDocument: document,
+              },
+            });
+            // Mock getBCR for visibility checks of trigger element
+            Element.prototype.getBoundingClientRect = jest.fn(() => ({
+              width: 24,
+              height: 24,
+              top: 0,
+              left: 0,
+              bottom: 0,
+              right: 0,
+            }));
+
+            // factory({ autoRenew: false, hasSeatLinkData: false });
+            factory({ autoRenew: true, hasSeatLinkData: true });
+            jest.runOnlyPendingTimers();
+            await wrapper.vm.$nextTick();
+          });
+
+          afterEach(() => {
+            // Reset overrides
+            document.createRange = originalCreateRange;
+            Element.prototype.getBoundingClientRect = origGetBCR;
+          });
           it('does not show autorenew tooltip on hover', async () => {
-            factory({ autoRenew: true, hasSeatLinkData: false });
             await wrapper.vm.$nextTick();

             expect(findGlTooltip()).toBeNull();
```

There is similar setup code in the test suite already, so let's refactor this into something helpful.

Story points: 2.0
Make CreateSalesforceAccountWorker retryable with Sidekiq

<!-- 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

> Well spotted. @rdavila looks like an easy fix, would you be able to submit that on a separate MR for `CreateSalesforceAccountWorker`?

Derived from: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1479#note_416471108

### Proposal

Send a fix similar to the one sent for `CreateSalesforceOpportunityWorker`

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Make context an optional argument to Unleash.enabled?

## Proposal

Update the [`Unleash` initializer](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/c8b54841a8706b289bb3a518082c31feb7cbbb14/config/initializers/unleash.rb#L17) so that the `enabled?` method has a default argument for `context` of an empty hash.

`def enabled?(feature, context = {}, *args)`

There are so many place within the code where we already pass the empty hash.  Updating it would make it more convenient to use and clean up existing references.

## Followup

The following discussion from !1979 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1979#note_418344696): 

    > We have so many places that send an empty hash for the context to the `enabled?` helper.  It's probably time we make that an optional argument and default it to an empty hash.  I might tackle that as a follow-up when I have downtime. :smile:

Story points: 1.0
SPIKE: Migrate Autorenewal process to automated process flow in customers.gitlab.com

## Summary

When a self-managed or GitLab.com subscription is set to autorenew, the process is driven by Zuora. Currently, this Zuora process requires manual intervention. While there is a possibility of automating this in Zuora, we may find that the timing and LOE is so large that we will not see manual process relief for some time.

### Manual effort estimation

Currently the billing team is spending an average of 110 hours monthly processing autorenewals (just those which actually renew, not those which must be cancelled due to non-payment) with a volume of over 560 subscriptions per month.

## Proposal

Let's explore what the dev effort would be to automatically process the renewal via customers.gitlab.com similar to what we will do with [Quarterly Coterms](https://gitlab.com/groups/gitlab-org/-/epics/27470) so that customers.gitlab.com processes the renewal and charging of credit card.

### Considerations

1. Where the original subscription was sourced by Web Store, we should only process and offer the autorenew feature for subscriptions with a valid credit card on file.
1. Where the original subscription was sourced by a sales-assisted order form, we should allow autorenew in any case. For those which have no credit card on file, we should generate the subscription and send an invoice.
1. Where the original subscription was sourced by a sales-assisted order form, we should identify if there is an open renewal opportunity in SFDC and if so, do not process autorenewal. (this can be follow-up iteration)

Story points: 1.0
CI minute purchase totals do not update

<!-- 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

https://customers.gitlab.com/subscriptions/new?plan_id=2c92a0086a07f4a8016a2c0a1f7b4b4c&transaction=ci_minutes

When hitting the above link the total isn't updated.

![ci_minutes_stuck](/uploads/2c4d983212b5881cfd521762f67897c8/ci_minutes_stuck.gif)

Zendesk ticket https://gitlab.zendesk.com/agent/tickets/173687

### Proposal

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Cleanup unused secret variable

Follow-up of https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1657 

## Problem
With changes for https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1657 a variable (`finance_cc_email`) from the application's secrets is not needed anymore and should be removed. This should be addressed after the work for https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1657 is completed.

### Proposal
These steps are required to complete this issue:
- Remove the value in the [`secrets.yml.example`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/staging/config/secrets.yml.example) for all environments
- Create infrastructure issue to remove the value from the chef vault of customers.gitlab.com
- Create merge request in the [CustomersDot's cookbooks](https://gitlab.com/gitlab-cookbooks/cookbook-customers-gitlab-com) to remove the variable from [`secret.yml.erb`](https://gitlab.com/gitlab-cookbooks/cookbook-customers-gitlab-com/-/blob/master/templates/default/secrets.yml.erb) and the default in [`default.rb`](https://gitlab.com/gitlab-cookbooks/cookbook-customers-gitlab-com/-/blob/master/attributes/default.rb)

### Result
Removal of unused secret variable

Story points: 1.0
Ensure project setup covers GDK refusing to connect to HTTPS with invalid license

<!-- 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

@astoicescu recently updated their GDK, and due to security concerns the GDK now drops HTTPS calls if the certificate is invalid.

This is obviously a good thing.

This can cause issues for our local development though.

We recommend ngrok for local development, and their wildcard is `*.eu.ngrok.io `.

However if one creates a ngrok url with `.` like https://ragnar.zuora-payment.eu.ngrok.io/ it'll be two subdomains and the license will be invalid.

A workaround is to drop from `https` to `http`.

### Proposal

Document this gotcha.

Story points: 1.0
Rename .rb to .rb.tt for templates used in templates folder

In the [generator folder](https://gitlab.com/gitlab-org/customers-gitlab-com/-/tree/staging/generator_templates/active_record) we have few templates which we are using for [migration](https://gitlab.com/gitlab-org/customers-gitlab-com/-/tree/staging/generator_templates/active_record/migration).

As it contains the ERB codebase the files are having a `.rb` extension instead of `.rb.tt`

The same is being used by Bundler and also Rails in their project. https://github.com/rails/rails/blob/master/activerecord/lib/rails/generators/active_record/migration/templates/create_table_migration.rb.tt

The corresponding issue for GitLab extension change is here https://gitlab.com/gitlab-org/gitlab/-/issues/251122

Story points: 1.0
Remove "HostedPlans" from namespace of Gitlab::HostedPlans::UpgradeSubscriptionPlanService

### Problem
Now that `Gitlab::HostedPlans::UpgradeSubscriptionPlanService` is used to upgrade both hosted and self-hosted plans, the namespace `HostedPlans` is misleading.

### Proposal
We should remove the `HostedPlans` namespace for this class and move the file under `app/services/gitlab/` instead.

### Result
Clearer class name for this service.

Story points: 1.0
Add Invoice balance and due date to Web Store

## Summary

As a follow up to https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/503 and to get us closer to delivering https://gitlab.com/groups/gitlab-org/-/epics/4372, we'd like to provide customers with `Invoice Due Date` and `Invoice Balance` within the Web Store.



### Additional Reference

1. See pertinent conversation: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/503#note_416662993

### UX

There shouldn't be a material change to the existing UX but will obtain sign-off/review on this assumption.

## Actions

1. [x] Pull invoice balance from Zuora
1. [x] Pull invoice due date from Zuora
1. [x] Create new `Invoice Due Date` column in FE of Web Store>Invoices page and display values
1. [x] Create new `Invoice Balance` column in FE of Web Store>Invoices page and display values

Story points: 1.0
Sign in view. Use gitlab-ui utility classes.

<!-- 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/

-->

### Description

This issue contains the follow-ups derived from https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1865/

- [x] Replace margins on `.signin-register-page` with utility classes added to gitlab-ui (after https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/1733 gets merged)

Story points: 1.0
Guide the user to login page when purchasing a subscription

### Problem

When the user wants to purchase a new subscription, the current HAML implementation allows visiting the new subscription page without having an account, and inside that page, the user will not see anything but a "Sign in" link.

#### Current flow

![](https://gitlab.com/gitlab-org/customers-gitlab-com/uploads/360236ea7a114aa0d2a7b674b581ce9c/guides_through_login.gif)

In the pajama's implementation #1473 and #1970, we need to redirect the user to the login page if they're not logged in.

Caught by @rhardarson :thumbsup: 

### Proposal

Redirect the user to the sign in page when they try to purchase a new subscription without having an active session.

### Result

No errors when the user trying to access the page without having an active session.

### Next steps (if any)

Story points: 2.0
SaaS users should be able to indicate the desired quantity of users during purchase

## Problem
Users purchasing GitLab.com subscriptions are not prompted to enter a number of seats they would like to purchase during the new subscription purchase flow. Instead, we read the number of seats active at the time of purchase and charge them accordingly. This limits growth and doesn’t give purchasing control to the user.

## Proposal

Allow users to enter a number of seats during the GitLab.com purchase flow.

### Success Criteria

- The user should be able to manually enter the number of seats desired for purchase
- The system should provide a message if the user enters a number less than `Seats currently in use`
- If the number entered is less than `Seats currently in use` do not block the purchase
- The user should be able to enter a quantity of users greater than `Seats currently in use`

Story points: 2.0
Move New GitLab.com Subscription flows to GitLab.com UI

## Problem

When a new GitLab.com subscriber enters the purchase flow from our pricing page or from the Web Store, if they do not already have a group created, they are blocked from continuing their purchase.


## Proposal

Move the GitLab.com New Subscription purchase flow to follow the same flow introduced if the user attempts to purchase via a GitLab.com CTA. 

It's managed under [`move_gitlab_purchases_to_gitlab`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/71/edit) feature flag.

### Success Criteria

- The user should remain in GitLab.com from a UI perspective
- The user should not be prompted to log into the Web Store
- If a group is not yet created, one should be created for them

Story points: 2.0
SPIKE: Move all purchasing flows to GitLab.com

## Summary

This is a research issue to break down the work to move SaaS purchase flows to GitLab.com. The expected output includes creating applicable BE and FE issues and providing an estimated weight where possible.

Please see epic: https://gitlab.com/groups/gitlab-org/growth/-/epics/36

## Options Comparison

| Option                           | Pros | Cons | Notes | Supporters |
| -------------------------------- | ---- | ---- | ----- | ---------- |
| Move components to GitLab                   | <ol><li>We have full control over how components behave inside GitLab</li></ol>    | <ol><li>Duplicated code between 2 projects</li><li>Harder to maintain 2 copies of the same component</li></ol> | |
| Move components to shared package then use in GitLab | <ol><li>Easier to reuse components between 2 projects</li><li>Reduce the components code used in each project by extracting it to external one</li></ol>   |  <ol><li>One extra project to maintain</li></ol>  | | |
| Compose new components for GitLab | <ol><li>Easy to adopt new UX/UI design</li><li>More control over SaaS specific purchase flows</li></ol> | <ol><li>New components to maintain</li><li>Not reusing existing components</li><li>We need to rewrite all JS tests to accommodate new components</li></ol> |  | @esybrant, @rhardarson, @vitallium, @aalakkad |
| ~~Serve pages through an iframe from CustomersDot~~    | <ol><li>No need to create another project or to duplicate components</li><li>Faster MVP</li></ol>    | <ol><li>Ambiguity on how to implement</li><li>Uncertainty on how to handle user sessions and data passed from HTML to Vue</li></ol>     | [invalidated](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1985#note_440724423) by @vitallium | |


## Action points

- [x] ask UX if they expect any change in the components when we move flows to GitLab or it will stay the same

Story points: 5.0
Follow up: Update additional fields on SFDC Quote creation

### Problem

Upon SFDC **Opportunity** creation we will also create a set of associated objects, **Quote** being one of these.

When creating a Quote [we also pass subscription data](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/8b9502d8c6f216de3e8287590fee1b14d3ef0145/app/services/salesforce/create_quote_service.rb#L55-56)

The current fields we are populating in SFDC are resulting in some confusion and duplication error. We would like to update the fields where we store this data on the SFDC end.

### Proposal

Update [these fields](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/8b9502d8c6f216de3e8287590fee1b14d3ef0145/app/services/salesforce/create_quote_service.rb#L55-56) with some custom fields TBDed.

### Result

No error on the SFDC upon **Quote** creation.

Story points: 1.0
Remove FF for adding seats to a dotcom subscription

### Problem
With the feature to add seats to dotcom subscriptions (https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1098), a new feature flag named `add_seats_for_dotcom ` was introduced. The feature has been tested and the feature flag is no longer needed.

### Proposal
Remove the feature flag from the code and the [feature flag page](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/64/edit).

### Result
Less complex code because of a removed condition and cleanup after feature flag removal.

### Next steps (if any)

### How will we measure success?

### Availability & Testing

Tests (including end-to-end) must run and pass before and after this FF is removed. 

<!-- 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 -->

Story points: 1.0
Remove FF for self-serve upgrades for self-managed subscriptions

### Problem
With the feature for self-serve upgrade for self-managed subscriptions (https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/107), a new feature flag named `upgrade_self_managed_subscription` was introduced. The feature has been tested and the feature flag is no longer needed.

### Proposal
Remove the feature flag from the code and the [feature flag page](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/65/edit).

### Result
Less complex code because of a removed condition and cleanup after feature flag removal.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Pajamas Update: GitLab.com "New Subscription" Page

Similar to #1473.

The change is managed under [`pajamas_new_gitlab_com_subscription`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/67/edit) feature flag.

### Problem

In order to match Pajama's design that we follow we should migrate the `New GL.com Subscription` page.


## Follow-up issue

- https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2039
- https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2110

### Proposal

Use the following design for the new GitLab.com subscription page

![](/uploads/9e3428a617b31972d66f521917c42fce/GitLab.com_-_Buy_subscription.png)

Story points: 3.0
Error on subscription upgrade with no plan

### Problem
Upgrading a subscription for which no plan can be found results in [an error](https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1845056):

```
NoMethodError
undefined method `any?' for nil:NilClass
```

### Proposal
Add check for plan presence on upgrade.

### Result
Resolve error for upgrades.

### Next steps (if any)

### How will we measure success?
No more erros on subscription upgrades.

Story points: 1.0
Analyze/modify ZuoraWorker use

The following discussion from !1954 should be addressed:

- [ ] @dstull started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1954#note_412412150): 

    > I was looking into this and thinking - oh, the workers that include this must define this then.... However that is not the case.
    > 
    > In the 4 classes that include this concern, 2 define this method that is referenced by the `perform` method in this module and 2 do not, and redefine the `perform` method. 
    > 
    > So as a follow up, we need to see if this concern really is leveraged in an optimal manner and refactor a bit.

Story points: 2.0