giseldo/neodataset huggingface dataset:
Unable to Reset Password in GitLab Customer Portal

<!---
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

An existing GitLab customer cannot reset their password in the GitLab customer portal from within their account.  It shows successfully completed but still uses the old password.  This has been repeated by the customer in different browsers without ad blockers running and in private modes so no cached data might interfere somewhere.  I gave it a severity 4 since it's a single customer and they can still use their account they just can't change the password at the moment.

### Steps to reproduce

The customer enters the old and new passwords and the system shows completed but no change is made.

### What is the current *bug* behavior?

The password never changes.

### What is the expected *correct* behavior?

The password should update.

### Relevant logs and/or screenshots
There are no records of any error newer than a year ago for this customer in Sentry.

### Workarounds

None known.

### Reported examples

1. Ticket [186667](https://gitlab.zendesk.com/agent/tickets/186667)

<!---
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
Follow-up from "Avoid UpdateProduct amendment for upgrade@renewal"

# Purpose

Refactor the expression [found here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2449/diffs#c74f9d3b85ffdd0e8a6b0d43ea9b111d8e09f1ff_73_70) in the `AmendSubscriptionService` class.  We could move the logic to a method to help with readability and comprehension.  There may also be an opportunity to simplify part of the expression here: `seat_increase? || (renewing? && quantity_has_changed?)`.  

## Follow-up from:

The following discussion from !2449 should be addressed:

- [ ] @cwiesner started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2449#note_479704182):  (+1 comment)

    > **suggestion:** The amount of conditions are making it harder to put a name to what's the context here. What do you think about moving them to one or multiple methods for easier readability? I know that naming things is hard, I can think of something like `increase_seat_for_same_product` but I'm not too happy about that name either :sweat: 
    > 
    > We can also address this in a follow-up if you think it's worth addressing.

Story points: 1.0
Change default branch name to main

### Problem

Related to https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/1357

Master isn't an inclusive word and Git has decided to adopt `main` as what was previously known as `master`.

### Proposal

Set the default branch as `main` and remove any references to `master`.

This will impact deployment and we'll better wait for https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/11464 so we don't have to change the cookbooks and deployment tools.

### Result

`main` will be the default branch

Story points: 3.0
Rename Zuora Subscription custom field perform_reconciliations__c to PerformReconciliations__c

<!-- 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 IronBank gem, which the CustomersDot app uses, automatically converts field names like `perform_reconciliations__c` to `PerformReconciliations__c` before calling the Zuora API. Due to this, trying to update the `perform_reconciliations__c` field from the CustomersDot app fails.

### Proposal

1. Create a new custom field in production Zuora with the same details as https://apisandbox.zuora.com/apps/CustomField.do?method=viewDetail&id=2c92c0f87688a09601768ac3019f7cc5&objectType=Subscription. Note that the field label is  `Perform reconciliations1?` on sandbox just to visually distinguish it from the existing custom field during testing. On production Zuora, the label can be `Perform reconciliations?`.

1. Update the CustomersDot app to use the new custom field and remove the old (`perform_reconciliations__c`) one.

1. Delete the existing `perform_reconciliations__c` field once the production CustomersDot app has been updated.

#### Steps

- [X] Add new custom field to Zuora sandbox.
- [X] Add new custom field to sandbox schema files - https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2443.
- [x] Remove old custom field from sandbox schema files - https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2502.
- [x] Remove the old custom field from Zuora sandbox.
- [x] Observe staging to see if there are any problems.
- [x] Remove old custom field from production schema files - !2613.
- [x] Ask `@mquitevis` to rename the custom field in production Zuora.
- [x] Add the new custom field to production schema files: https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2688

### Result

The CustomersDot app is able to update the value of the `PerformReconciliations__c` field.

<!-- ### Next steps (if any) -->

<!-- ### How will we measure success? -->

Story points: 3.0
Stop converting symbols to strings in Zuora::Resource

The following discussion from !2414 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2414#note_473217243): 

    > Nice catch with this!  Thanks for adding the detailed comment too.  Do you think it's worth creating a follow-up issue for revisiting this after rails is updated?  It could be linked to https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/498.   This is pretty minor though so not a must-have.

ActiveJob in Rails 6 supports serializing symbols. So, once we upgrade to Rails 6, we can remove the `.map(&:to_s)` from this line: [lib/zuora/resource.rb#L81](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/73847ee8ef0a74d81dcc02dea4d47728c8ab9003/lib/zuora/resource.rb#L81)

Story points: 2.0
[Exception] Invoice not present in Salesforce::CreateOpportunityObjectsService

The following discussion from !2388 should be addressed:

- [ ] @asubramanian1 started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2388#note_473231381):  (+1 comment)

    > **question:** This seems be [failing](https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/2382820/?query=is%3Aunresolved%20Zuora%3A%3ARecordNotFound%20Sidekiq) quite often in the past month. Should we [rescue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/4571495130f3e77ea5bc91336f11f95385e17ca9/app/services/salesforce/create_opportunity_objects_service.rb#L49) and return the response appropriately?

Story points: 2.0
Add loading indicator to price per user in renew pages

### Problem

In subscription renew pages, we're changing the price `per user yearly` according to the selected plan.

However, when the plan changed and before the request is complete, we show a loading spinner on all soon-to-change parts (e.g. invoice, total, etc.).

But we are missing the loading spinner on the price per user part.

![screencapture-subscriptions-A-S00061735-renew-2020-12-17-12_09_13](/uploads/49faeb847687b0d6dc7309ad8a082424/screencapture-subscriptions-A-S00061735-renew-2020-12-17-12_09_13.png)

### Proposal

Add loading spinner to that part of the renew page.

That part can be found inside 2 components: `SubscriptoinRenewForm.vue` and `DotComSubscriptoinRenewForm.vue`.

Thanks to @cwiesner for catching this!

Story points: 2.0
More efficient implementation for current_customer_has_subscription? method

### Problem

The [`current_customer_has_subscription?` helper method](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/890901f02954ecf2b7cc4520303c184ec29d83b8/app%2Fhelpers%2Fcustomer_helper.rb#L7) is used to simply return a boolean for whether a customer has at least one active subscription.  However, this method using the following logic, which queries for all subscriptions in Zuora, then subsequently all rate plans and rate plan charges, and initializes `Subscription` objects for each one.  This is very inefficient, especially for customers with more than one subscription.

```
  def current_customer_has_subscription?
    return unless current_customer

    SubscriptionsFinder.for_customer(current_customer).present?
  end
```

This seems like an easy win to speed up almost all our page loads because this helper is called in the navigation partial which is used in the application layout (IOW most pages).

### Proposal

Instead of using `SubscriptionsFinder`, here are a few alternatives:

- A simple fix would be to pull `raw_subscriptions` directly from the customer and return if any are found.  This bypasses the queries for rate plans rate plan charges.  This could be something like: `current_customer.raw_subscriptions.any?`.
- Even better would be to limit the query to Zuora to only pull the first subscription.  Something like `current_customer.raw_subscriptions(limit: 1).any?`.  This would require a few modifications but IronBank supports limits in `where` (e.g. `Zuora::Subscription.where({status: 'Active', account_id: cus.zuora_account_id}, limit: 1)`.

### Result

Faster page loads.

Story points: 2.0
Clean-up: graduate saas_manual_renew feature flag

### Problem

On 2020-12-17 we enabled [`saas_manual_renew`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/76/edit) on production, which has been introduced as part of #2132.

After 2 milestones of running without problems, we need to graduate the feature flag and make the change permanent.

Story points: 2.0
Flaky invoice spec does not use VCR

### Problem
One of the specs for `Zuora::Invoice` is flaky because of a 502 Bad Gateway error ([example](https://gitlab.com/gitlab-org/customers-gitlab-com/-/jobs/910417018)). The spec in question sends out a real request and would also fail when running the spec without an internet connection.

```
Failures:
  1) Zuora::Invoice.between creates a Zuora query string using the given start and end dates
     Failure/Error: query_result = client.query(query_string) # up to 2k records from Zuora
     IronBank::ServerError:
       Body: <html>
       <head><title>502 Bad Gateway</title></head>
       <body>
       <center><h1>502 Bad Gateway</h1></center>
       </body>
       </html>
     # ./lib/zuora/invoice.rb:18:in `between'
     # ./spec/lib/zuora/invoice_spec.rb:9:in `block (3 levels) in <top (required)>'
     # ./spec/lib/zuora/invoice_spec.rb:26:in `block (3 levels) in <top (required)>'
Finished in 5 minutes 54 seconds (files took 9.43 seconds to load)
3125 examples, 1 failure, 1 pending
Failed examples:
rspec ./spec/lib/zuora/invoice_spec.rb:16 # Zuora::Invoice.between creates a Zuora query string using the given start and end dates
```

### Proposal
Use VCR for this spec to stub the http request.

### Result
No flaky spec for this.

Story points: 1.0
Change midterm keyword argument to something more meaningful

# Purpose

The keyword argument `midterm` defined [here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/4d6db5ed2e483281c0545db679debd626dbe5755/app%2Fservices%2Famendment_base_service.rb#L32) could be clearer.  Some suggestions for improving are:
- `effective_date` and pass the date to the method.  The default would be `Date.current`.
- `effective_immediately` or `effective_now`: boolean defaulting to `true`

## Followup from

The following discussion from !2348 should be addressed:

- [ ] @vshumilo started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2348#note_467696479):  (+3 comments)

    > **non blocking**
    > 
    > :thumbsup: 
    > 
    > How do you feel about calling it something inline with `effective_immediately: false`... it is longer :( but it feels more specific.

Story points: 1.0
Refactor discount percentages logic for easier interpretation

# Purpose

In https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2354, we introduce a method, `SubscriptionHelper#eoa_starter_bronze_discount_percentages` which returns an array of discount percentages for the remaining renewal uplifts, assuming the subscrpition is participating in an EoA offer.  In the review, a comment was made (see below) that we could clean this logic up to be clearer by moving into a service (or something similar).

## Follow-up for:

The following discussion from !2354 should be addressed:

- [ ] @vshumilo started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2354#note_467549506):  (+1 comment)

    > I understand this but it is not very straightforward.
    > 
    > What do you think about creating a ~"🍎" follow up to move this into a EoA service or dedicated method for the math only? so it is easier to follow.
    > 
    > We also might process the `uplifts` set directly given for the last item (list_price) the discount will be 0 given by:
    > 
    > `(1 - (price.to_f / list_price)) * 100`

Story points: 2.0
New Gold/Ultimate subscription does not charge the right amount

### Summary

Gold subscription does not charge for any guest users in the targetted namespace. But when buying a new Gold subscription for an existing group that already has guests in it, this exception is not taken into consideration.

### Steps to reproduce

The steps below include screenshots taken on https://customers.stg.gitlab.com and https://staging.gitlab.com

1. In GitLab, create a group with one guest in it - which bring the total of members to 2:

   ![2020-12-15_15-24](/uploads/1c87758ee43b636e3a5719fe24609065/2020-12-15_15-24.png)

1. In CustomersDot, purchase a Gold subscription for that group:

   ![2020-12-15_15-25](/uploads/f0b086a05e60a965c03ddfc1812d6f44/2020-12-15_15-25.png)

! For local development don't forget to turn on `move_gitlab_purchases_to_gitlab` `71` FF, all the UI is moved to GitLab

### What is the current *bug* behavior?

The minimum number of users for this purchase is 2.

### What is the expected *correct* behavior?

At minimum, only the group owner should be charged. So the minimum number of users selectable should be 1.

### Relevant logs and/or screenshots

See screenshots above

Story points: 3.0
Community Programs Self-Checkout: BE logic to recognize coupon code

## Summary

This issue is to create the BE logic to recognize coupon code as per the details found in: https://gitlab.com/groups/gitlab-org/-/epics/5068

## Success Criteria

1. When a user enters a [coupon code](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2361) at New Subscription checkout, the subscription is charged at $0.00
1. The subscription must be created using the applicable Community Programs Sku (OSS, EDU, YCombinator)
1. The user should not be prompted to enter a credit card since the net is $0.00 _(note research done here: https://gitlab.com/groups/gitlab-org/-/epics/5068#note_468450428)_

## Process overview

https://gitlab.com/groups/gitlab-org/-/epics/5068#process-overview

Story points: 3.0
BE: Move CI Minutes purchase flows to GitLab.com UI

## Summary

This is the BE version of https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1990. 

## Problem
During the CI minutes purchase process, depending on how the user entered the purchase flow, they may be asked which namespace the CI minutes should be applied to. This is an over complication as a result of disparate systems.



## Proposal

Move the CI Minutes purchase flows to GitLab.com CTAs. 

### 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
- The user should not be prompted to enter a namespace for the purchase

### Testing & Availability
- User redirect to checkout page when clicking on `buy more CI minutes` on Usage Quota page
- Namespace field default to personal/group namespace
- User able to change quantity during purchase
- Invalid quantity value is not allowed
- User able to enter billing info for new payment method or use an existing one
- User able to verify order summary before proceeding to purchase
- User be prompted with successful purchase/purchase error message
- User be redirected back to Usage Quota page after purchase

Story points: 8.0
New customer purchase workflow prevents purchases on groups with expired subscriptions

### Summary

The new customer purchase workflow that occurs on the GitLab.com side (rather than customers.gitlab) prevents users from selecting a group to apply a new purchase on if that desired group currently has an expired subscription which is still within the 14-day grace period. For example, purchasing a new Bronze plan to replace the expired Gold plan is not possible.

### Steps to reproduce

Have a group with an expired subscription, but which is still within the grace period before the system automatically downgrades the group to Free.  Attempt a new purchase workflow from customerDot, which redirects to gitlab.com/susbcriptions. The dropdown when choosing a group for the new subscription is not populated with desired group

### What is the expected *correct* behavior?

Customer should be able to make a new purchase for a group with an expired subscription

### Relevant logs and/or screenshots

1. Customer has 3 groups, one of which is currently on Gold with expired subscription:

![groups-in-cd-admin](/uploads/cb742a718edfc6e1216826c2b7e94320/groups-in-cd-admin.png)

2. From customers.gitlab.com, when attempting to purchase a new plan, the workflow redirects to `gitlab.com/subscriptions` and the form only displays 2 groups, neither are the desired group:

![new-workflow](/uploads/798787d697b430b8086118fc967410ae/new-workflow.png)

3. There are no available plans for purchase when viewing group billing page:

![dotcom-billing](/uploads/5a7678f87301c39ed50be570b998bff2/dotcom-billing.png)


**However**, Circumventing the new process (see below) shows the group with the expired subscription as available for applying a new purchase:

![cd-workflow](/uploads/e7cec93ab357447fef6f0a5a28e7452f/cd-workflow.png)

### Workarounds

Circumventing the redirect to gitlab.com and going directly to the customerDot URL and entering the `plan_id` allows the purchase to continue from customers.gitlab.com, and the group is available.  For example, bronze plan id `2c92a0ff5a840412015aa3cde86f2ba6`:

`https://customers.gitlab.com/subscriptions/new?plan_id=2c92a0ff5a840412015aa3cde86f2ba6&transaction=create_subscription`

Purchase workflow can then continue directly from customerDot.

Alternatively, manually downgrading the group to free should also allow the new purchase to proceed.

### Reported examples

1. Customer ticket: https://gitlab.zendesk.com/agent/tickets/183643
1. https://gitlab.zendesk.com/agent/tickets/181064 [Rotanak's ticket](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2344#note_465828943)
1. https://gitlab.zendesk.com/agent/tickets/185862

Story points: 3.0
Subscription indicator in Customers Admin based on active subscription in Zuora

## Summary

In https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2141 we created a `Subscription` designation for internal admins viewing customers.gitlab.com admin search results to allow them to easily distinguish which of the customer records are associated with a Zuora subscription.

The criteria for the work was solely the presence of a `Zuora account` id associated with the customer record. While this covers the majority of cases, there will be edge cases where an id is present but no valid subscription exists. We made the trade off to implement with this known constraint as it was a fast and low cost implementation.

## Proposal

Update the label display logic to ensure the customer record is actually tied to an active subscription in Zuora.

Story points: 2.0
Follow-up: Add frontend specs for upgrading a GitLab.com subscription during renewal

Add frontend specs for upgrading a GitLab.com subscription during renewal to cover `upgrade_product_id` (will be renamed to `change_product_id` in !2309).

The following discussion from !2309 should be addressed:

- [ ] @jakeburden started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2309#note_461771562): 

    > **Follow-up Suggestion (non-blocking):**
    > 
    > Noticed we don't test for this prop in [dotcom_subscription_renew_form_spec.js](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/spec/frontend/subscription/components/dotcom_subscription_renew_form_spec.js). We should create a follow-up issue to add a test case for this on the frontend.

We also need to add tests to cover this in `subscription_renew_form_spec.js` if needed.

Story points: 2.0