giseldo/neodataset huggingface dataset:
Customer cannot make new purchases after subscription was refunded

<!---
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

Customer was trying to make a new purchase but got Unknown error message.

### Steps to reproduce

1. Purchase a subscription
1. Get the subscription refunded
1. Try to purchase a new subscription → see the error

### What is the current *bug* behavior?

Customer cannot purchase new subscription when the previous subscription was refunded

### What is the expected *correct* behavior?

Customer can make new purchase regardless of refunded ones.

### Relevant logs and/or screenshots

![Error](/uploads/08a38bd7a9b5d6a22c15e16a3d6cfc59/Error.png)

### Workarounds

(Ways to get around the issue)

### Reported examples

1. https://gitlab.zendesk.com/agent/tickets/168006; Sentry event log: https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1330530/events/31962262/ ; SFDC: https://gitlab.my.salesforce.com/0016100001SrpL6
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: 1.0
Check if make_default action is used, otherwise delete it

Remove `make_default` method/endpoint from [`payment_methods_controller.rb`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/controllers/payment_methods_controller.rb) with any other references, since it's no longer in use.

The following started on !1729:

I see there's still an option to set the [Default Payment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/frontend/javascripts/payment_methods/edit_cc.vue#L162), and the [`update` api ](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/controllers/payment_methods_controller.rb#L87) probably handles it. Meaning we *may* not require the `make_default` action anymore, however it might be a good idea to get it cross-checked.

Story points: 1.0
Resolve Exceptions in RuboCop todo

All items that have exceptions should be resolved/inline disabled if not a light change, and rule removed from todo or moved to `.rubocop.yml` file if not default enabled/configured.

### Problem

Currently many rules have exceptions in the `.rubocop_todo.yml`.

### Proposal

- Resolve those exceptions.
- Double check the [Style/RedundantFreeze](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1799#note_397773621) items

### Result

Better compliance with our style guide.

### Next steps (if any)

### How will we measure success?

Smoother review process and more standard/code written by the same hand

Story points: 5.0
Resolve disabled RuboCop rules in todo file

Enable/resolve the exceptions with these disabled rules/cops:

- [x] `Layout/ArgumentAlignment` !1887 
- [x] `Layout/FirstHashElementIndentation` !1798 
- [x] `RSpec/ContextWording` !1867 
- [x] `RSpec/EmptyLineAfterLetBlock` !1765
- [x] `RSpec/ExpectInHook` !1879 
- [x] `Style/FrozenStringLiteralComment` !1799 
- [x] `Style/GuardClause` !1766 
- [x] `Style/IfUnlessModifier` !1772
- [x] `Style/TrailingCommaInArguments` !1866 
- [x] `Style/TrailingCommaInHashLiteral` !1878 

### Problem

Currently many rules are disabled due to too many exceptions in the `.rubocop_todo.yml`.

### Proposal

Resolve those exceptions and remove the entire cop/entry out of the `.rubocop_todo.yml` so that it will follow default configuration of being enabled.

### Result

Better compliance with our style guide.

### Next steps (if any)

### How will we measure success?

Smoother review process and more standard/code written by the same hand

Story points: 5.0
Our exisiting CI jobs do not run alongside static security checks - Confirm if this is intended

<!-- 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

Raised in [this slack thread](https://gitlab.slack.com/archives/CNLHTE457/p1596480844131600)

We're seeing SAST checks run in their own pipeline, and the jobs we've defined in `.gitlab-ci.yml` run in their own.

Some of the pipeline runs are flagged "Detached state" and we probably do not want this :thinking: 

* https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1754/pipelines#c77fa4e671717bfa2a920ffed00535f301dd5a4f


![image](/uploads/596b95c5d170680535b504e2bc6cbbbf/image.png)

Story points: 2.0
Follow-up: add support link to plain text alerts

## Problem

We're using plain text as alert, where we tell the users to "contact support" without any link to guide them to the right direction.

## Proposal 

Update all plain "contact support" alerts so those two words would link to: `https://about.gitlab.com/support/`.

The idea from @nicolasdular started on this [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1741#note_388200342).

We could be placing the link in a constant for easy reuse.

/cc @amandarueda @chris_baus for prioritization and scheduling.

Story points: 2.0
Perform BulkDownloadInvoice  on the 1st day of the month

<!-- 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/

-->

### Proposal

Update the monthly invoice download to be on the 1st day of the month instead of the 3rd.

### Result

Monthly invoices are sent on the 1st of the month.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Handle zuora callbacks from "Professional Services" Subscriptions

### Problem

There were reports of 500 errors in `ZuoraCallbacksController#subscription_update` requests.  It turns out these all appear to the from "Professional Services" subscriptions.

Related info:
- [Slack thread](https://gitlab.slack.com/archives/CMJ8JR0RH/p1596224122000000)
- [Sentry error](https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1700065/events/7be3912a293d48daa1a557b436da214f/)
- [Zuora Account page with callout errors](https://www.zuora.com/apps/CustomerAccount.do?method=view&id=2c92a0fd71c96bdb0171cc6f139f36e6)

### Proposal

I don't believe these errors are cause for alarm, but we should confirm.  If so, we should handle subscriptions of this type without throwing errors.

Story points: 2.0
Follow-up: remove .gl-top-4 from utilities.scss

### Problem

We introduced a new utility class `.gl-top-4` in !1741, also sent a [merge request](https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/1612) to gitlab-ui to add the class to the main project so we could reuse it.

Once the gitlab-ui MR is merged, we'd have 2 definitions for the same class.

### Proposal

Delete the class from `app/frontend/stylesheets/_utilities.scss`.

### Result

### Next steps (if any)

Schedule.

### How will we measure success?

Story points: 1.0
Ensure ordering of invoice items is consistent

<!-- 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

Uncovered in https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1622#note_385785696

Our backend gets a response from Zuora and relays `invoice_items` to the frontend. These `invoice_items` do not have a consistent order, which makes any comparison between individual items error prone.

### Proposal

Sort `invoice_items` response on the backend or frontend.

### Result

Consistent response and calculations.

Story points: 2.0
Can't change namespace of Gold subscription to a Free group with Guest users

<!-- 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
As a potential (or past) Gold customer I might want to change the namespace of a subscription to a group on Free. If any Guest users are present, the customers application will bill me for the number of seats in `billable_users` regardless of the _target_ subscription level. In the case of Gold, Guest users should _not_ be charged.

Reproduction is hard because you need an existing subscription. 

#### What works

The following flow _works as expected_ on a new purchase from the billing page:
- Create a new (free) group.
- Add a guest user
- Attempt a purchase of Gold, and note it will charge for the correct number of users.

#### What doesn't work
Attempting to change the namespace of an _existing_ subscription to a Free group does _not_ work correctly.


### Proposal
Build the list of billable users based on the target subscription level, rather than the current subscription level. Mirror the logic in the new purchase flow.

### Workaround
Re-establishing a Gold trial restores the billable users count to what it should be and allows the subscription to be applied.

Story points: 5.0
Namespaces with paid plan can return nil

<!-- 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

Seeing `namespaces_with_paid_plan: namespaces_with_paid_plan.map(&:id).uniq` fail with `ActionView::Template::Error: undefined method `map' for nil:NilClass`

https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1678514/?query=undefined%20method%20%60map%27

### Proposal

Add a guard so we do not have a runtime error.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 3.0
Follow-up from "This fixes an issue of doing nothing"

We should double check if we're properly handling the preview mode here. At a first glance looks like we should access the key through a `Symbol`. For now, it's likely we're always ignoring the passed preview mode.

The following discussion from !1702 should be addressed:

- [ ] @rdavila started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1702#note_382608503):  (+3 comments)

    > @jejacks0n can you please double check if we're getting the correct value by using a `String` instead of `Symbol` here? Ar a first glance looks like we should be using a `Symbol` here.

Story points: 1.0
Follow-up from "Move add-ons on namespace change"

The following discussion from !1635 should be addressed:

- [ ] @chloeliu started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1635#note_382505061): 

    > **Non-blocker**: I might be missing it somewhere, but shall we also add a scenario for 'namespace change not allowed' from UI perspective(if it's ready)? To verify a dropdown item disabled or maybe an error flashcard.

Story points: 1.0
Add new cop to detect missing new line at the end of the files

### Problem

Sometimes we forgot to include the new line at the end of the file and the diff shows a warning like `\ No newline at end of file`.

### Proposal

Update Rubocop's policies to include a new cop that detect this missing line.

### Result

Pipeline will fail and the developer will be aware of this required updated.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Introduce matching web direct data on domain to avoid duplicate accounts in SFDC

### Problem

The **initial** Web-Direct order from the portal does not attempt to match against an existing Salesforce account, and instead **always** creates a net-new account (sometimes a duplicate, sometimes not). This is problematic primarily in scenarios where we've:

1. Have existing `Sales-Assisted` accounts/hierarchies in place, as the closed won business now is duplicated somewhere else.
1. Have existing "greenfield" accounts already built out in Salesforce.

In both examples we're now creating duplicate accounts, as well as potentially breaking `new` vs `connected new` business metrics - as these web direct accounts aren't tied to existing Acct Hierarchies in Salesforce.

The subsequent renewal web direct order already has the Account ID, and therefore pushes to the existing Account it already created, **unless possibly** it was merged on Salesforce side already as a dupe (would need to validate this example).

In a perfect world the portal would attempt to first do some sort of matching logic to find an existing account in Salesforce prior to generating a new one. Examples of what I've seen in other applications would be a search on:

1. `Domain/Website` Match
1. `Company Name` Match
1. Combinations of fuzzy `Company Name`, `Domain`, `Address` matches (probably more complicated)
>>>

[per slack thread](https://gitlab.slack.com/archives/GEMFSJ94L/p1594916606133400)

cc @jbrennan1 @tav_scott @jrabbits @annapiaseczna 

### Proposal

Match on domain match (labeled website in Salesforce) prior to new account creation is fine by me, and would be a good way to 80/20 it from an improvement perspective.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Add missing destroy_zuora_records in specs

<!-- 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

Some spec does not have `destroy_zuora_records` method which removes created records after the spec passes.

### Proposal

We should check and add it to required places.

### Result

No more orphaned records in our Sandbox.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Show error message on failed namespace change

### Problem

When a namespace change is not allowed we just redirect back to the subscription's page. It would be nice to show an error message to let the user know what's going on. With https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1635 there will be a general error message in case of an error that could be shown.

### Proposal

Process error in frontend to inform the user about an error.

### Result

User knows about the error.

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Follow-up from "WIP: Move add-ons on namespace change"

The following discussion from !1635 should be addressed:

- [ ] @vshumilo started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1635#note_379456815):  (+5 comments)

    > I want to make sure I am understanding correctly this update.
    > 
    > Will this mean we are choosing GitLab to be our source of truth indirectly? 
    > 
    > Wondering about this scenario:
    > - `CreateOrderService` succeeds (as in a transaction things are not yet commited but all looking good
    > - Sync with `GitLab` succeeds
    > - (no raised exceptions so far) but the commit of the transaction fails, can this happen? can be a lock on the table or something that makes this happen? leaving this in a state where out truth in the customers portal is not GitLab truth because it has been updated?
    > 
    > I apologize for thinking out loud :)

Story points: 3.0
Follow-up from "Move add-ons on namespace change"

The following discussion from !1635 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1635#note_380158242):  (+1 comment)

    > **Question (non-blocking):** Not for this MR, but just wondering if the `Gitlab::HostedPlans::ExtraAddOnService` should actually be absorbed into the `NamespaceParamsGenerator`.  Either the logic could be moved into the `NamespaceParamsGenerator`, or the `NamespaceParamsGenerator` could call that service as needed.  The purpose of the `ExtraAddOnService` as I understand it is to basically generate the values to be used in the namespace params anyway so it seems pretty related and the purpose of `ExtraAddOnService` is tough to understand based on the current name.  Just something to consider for a future issue maybe.

Check if this is a valid approach due to the fact that the `ExtraAddOnService` is also used later in the class to update the Order.

Story points: 2.0
Follow-up from "WIP: Move add-ons on namespace change"

The following discussion from !1635 should be addressed:

- [ ] @vshumilo started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1635#note_379456813):  (+3 comments)

    > I know this logic was already here but I am trying to understand why the `params[:subscription_id]` is merged back into the params and named the same?
    > 
    > Based on the code the `params` have a attr called `:subscription_id`
    > 
    > And we are creating this value `subscription_id: params[:subscription_id]`
    > 
    > just to merge it back into the params.
    > 
    > I am probably missing something but it is like this is not changing anything but overwriting what is already there with the same value it already has?

Story points: 1.0
Let's remove these order columns after a while

We added billing_rate_adjusted_at and billing_rate_last_action to the orders table, and we're doing this to have some better insights into how orders are being renewed, but we don't expect these to give us extensive value long term, so we should come back and make sure we clean them up.

The following discussion from !1591 should be addressed:

- [ ] @jejacks0n started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1591#note_376164306):  (+4 comments)

    > @jayswain, would you make sure I have this correct please? I've changed the columns around a bit, and we clear out the notified_at value when we process the renewal -- since we can process it with either an increase, decrease, or no change now.
    > 
    > At 2 weeks before renewal we start processing an order and check it every day leading up to renewal. If at any point in those 2 weeks you exceed your available seats with users, you'll get the notification and we track that we sent it. We won't send it again for the remaining days leading up until renewal, which happens when the order is processed on the same day as its end_date.
    > 
    > At renewal we clear out when we sent the notification, and track that we either created an amendment or took no action. This logic would also now work for monthly or quarterly renewal. I would like to make sure that when things come back from zuora, this logic will still work how you initially intended -- I wasn't entirely sure about it.

Story points: 1.0
When Signing in with GitLab customers do not need to provide a password

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem

When users get redirected to `Sign In with GitLab` and end in the registration page, the form contains the password field as a required field to complete the process.

However, if the user is signing in with GitLab they shouldn't be asked to provide a password.

### Proposal

Only render the password field if the user trying to register has empty `provider` and `uid` fields. The way it's done in  [app/views/shared/customer/_sign_up_form.html.haml](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/views/shared/customer/_sign_up_form.html.haml#L2). 

Relevant thread: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1484#note_371285508

### Result

The customer will be required to provide only the missing information in the registration form. 

After #1176 is addressed, customers will only need to provide their billing info (city, zip code, country) to complete the registration.

### Next steps (if any)

:warning: Removing this as a next step because users can add a password after signing in with GitLab via the `Forgot Password` form and they'll need a way to update it from their Account Details page.

~~Update the `Account Details` page so that the `Update Password` section is not displayed for users that register from `Sign In with GitLab`.~~

### How will we measure success?

Story points: 2.0
GitLab.com new paid subscription purchase flow throwing error

## Summary

User has reported receiving `Failed to confirm your order! Please try again.` when attempting to by a paid subscription within GitLab.com.

![failurepic](/uploads/f1ec8dd4067c708f8fb3f835a0c19384/failurepic.png)


## Possible Root Cause
The new registration with checkout flow creates a group name from the company name automatically, but doesn't validate or sanitize the Group Name input. The save fails and we get a cryptic error message

## Workaround
Avoid commas and other disallowed characters in the company name


## Solution Suggestion
Sanitize the Group Name input, in such a way that it conforms to the rules set in the original group creation screen, as partially seen in the screenshot.

![screenshot-2020-07-13-22-50-53](/uploads/c8c3948be55c53caf43e8ce940680bd7/screenshot-2020-07-13-22-50-53.png)

Story points: 2.0
Lock date-sensitive spec

<!-- 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/

-->

We're seeing `spec/frontend/lib/datetime_spec.js` fail locally for on some machines.

We should lock the timezone this spec runs in so it's consistent `const start = DateTime.fromISO(startDate, { zone: 'utc' });`

Story points: 1.0