giseldo/neodataset huggingface dataset:
Remove AdminMailer code for notifying of EULA acceptance

### Problem

As mentioned in [the epic](https://gitlab.com/groups/gitlab-org/-/epics/4225), we no longer require the manual EULA process. As a result, we no longer need to notify admins when a customer has accepted a EULA.

### Proposal

We should remove [the `eula_notification` mailer from `AdminMailer`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/4ee96946d6358b1768ecb60a70edd27cde352b0d/app/mailers/admin_mailer.rb#L10), as well as related views and other references (e.g. https://gitlab.com/gitlab-org/customers-gitlab-com/blob/a0caa37649a5701a805b6c82caa458852d542438/app/controllers/eula_requests_controller.rb#L53).

**Important Note: This issue is blocked until the new terms have been live for at least 90 days (e.g. 90 days after [the `stop_eula_requests` feature flag was enabled](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1882)).  [That occurred on 2020-10-13](https://gitlab.slack.com/archives/CMJ8JR0RH/p1602599797469400).  The exact date is TBD.**

Story points: 1.0
Notify admins of license delivery error in the ZuoraCallbacksController

### Problem

As mentioned in [the epic](https://gitlab.com/groups/gitlab-org/-/epics/4225), we no longer require the manual EULA process. This means in `ZuoraCallbackController#subscription_update` we will no longer deliver emails asking customers to accept terms before sending a license key.  Instead, the license key will be delivered immediately (for EE).  

It appears we send an error notification to admins in the event a key is not created successfully (and therefore not delivered to the customer) when accepting the EULA ([here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/a0caa37649a5701a805b6c82caa458852d542438/app/controllers/eula_requests_controller.rb#L42)).  However, we do not send this notification for the same operation in `ZuoraCallbackController#subscription_update` ([here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/fe3d569fbe4e1f5e9b23bafe91bca8fb860200c0/app/controllers/zuora_callbacks_controller.rb#L145)).

### Proposal

Update the `ZuoraCallbackController#subscription_update` [here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/fe3d569fbe4e1f5e9b23bafe91bca8fb860200c0/app/controllers/zuora_callbacks_controller.rb#L145) to send this notification if an error occurs when generating the license key, in a similar manner to [the EULA acceptance logic here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/a0caa37649a5701a805b6c82caa458852d542438/app/controllers/eula_requests_controller.rb#L42).

Story points: 1.0
Remove CustomerMailer for accepting terms

### Problem

As mentioned in [the epic](https://gitlab.com/groups/gitlab-org/-/epics/4225), we no longer require the manual EULA process. As part of this work, we no longer need mailers for asking customers to accept terms.

### Proposal

Remove [the `accept_terms_request` mailer](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/fe3d569fbe4e1f5e9b23bafe91bca8fb860200c0/app/mailers/customer_mailer.rb#L20) in `CustomerMailer` (and related views) for allowing customers to accept terms.

This should no longer be used and can safely be removed once https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1830, https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1836, and https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1882 are resolved and the legacy EULA process has been sunset (see below note).

**Important Note: This issue is blocked until the new terms have been live for 90 days (e.g. 90 days after [the `stop_eula_requests` feature flag was enabled](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1882)).  [That occurred on 2020-10-13](https://gitlab.slack.com/archives/CMJ8JR0RH/p1602599797469400).  The exact date is TBD.**

Story points: 1.0
Put ability to resend EULA from admin panel behind a feature flag

### Problem

As mentioned in [the epic](https://gitlab.com/groups/gitlab-org/-/epics/4225), we no longer require the manual EULA process. As part of this work, we should not need to resend EULA request email from the Admin panel.

### Proposal

Remove the components related to resending EULAs via the admin panel.  This will be put behind the feature flag, `:stop_eula_requests`, until the new EULA workflow is adopted.  Once it is live, we can remove this code altogether (as part of [this issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1882)).

Story points: 1.0
Ensure change namespace button is disabled while operation is in progress

Suggested by @chris_baus to investigate.


### Problem

In the "Change namespace" page, the confirm button wasn't being disabled when the AJAX request is sent to the server, which could lead to the user being able to click it again.

### Proposal

We need to ensure the submit button is being disabled while the AJAX request is being made, then make it enabled once the AJAX request is finished, so if the request fails the user can click the button again.

Story points: 1.0
SPIKE: Force association often not working because of new validation

### Summary

Support has a ["force associate" function](https://gitlab.com/gitlab-com/support/toolbox/console-training-wheels/-/blob/master/lib/support_team.rb#L133-139) which we frequently use.

However, recently, we've seen the following error crop up:

```
W, [2020-08-20T00:10:39.100108 #130878]  WARN -- : You are setting a key that conflicts with a built-in method Hashie::Mash#default defined in Hash. This can cause unexpected behavior when accessing the key as a property. You can still access the key via the #[] method.
Traceback (most recent call last):
        2: from (irb):13
        1: from app/services/gitlab/namespace/update_plan_info_service.rb:30:in `execute'
Errors::ActionNotAllowed (Namespace change to 12345 is not allowed)
```

### Validation Issue

This line has the validation which is causing the error: https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/master/app/services/gitlab/namespace/update_plan_info_service.rb#L30

> raise(::Errors::ActionNotAllowed, "Namespace change to #{order_gl_namespace_id} is not allowed") unless namespace_transaction_validator.valid?

According to the description in the [relevant commit](https://gitlab.com/gitlab-org/customers-gitlab-com/-/commit/a51b25ca85662460bb2d00f8592728aea7b4c125), this validation was added for this reason:

> Please note that subscriptions with add-ons can
only be moved when the new namespace does not have a subscription yet,
also subscriptions containing legacy CI minutes only are not moveable.

However, we're seeing orders with the `amendment_type: "UpdateProduct"` where there are no add-ons and we cannot force associate the order.

### Current workaround

Our workaround right now is to change the `amendment_type` temporarily and change it back after we run the function.

### Ask

I'd like to know what Support can do here. I'd really prefer not to be messing around with the order data to make our function work but we also need this function to work, especially when there are no add-ons attached.

1. Why are we hitting this validation error for orders that don't have add-ons?
1. In the short term, the workaround is to force the sync anyway. Is it a problem if there are add-ons?

### Some examples

1. https://gitlab.com/gitlab-com/support/internal-requests/-/issues/2757#note_387042141
1. https://gitlab.com/gitlab-com/support/internal-requests/-/issues/2933
1. https://gitlab.com/gitlab-com/support/internal-requests/-/issues/2955
1. https://gitlab.com/gitlab-com/support/internal-requests/-/issues/2983#note_432262992
1. https://gitlab.zendesk.com/agent/tickets/200673

Story points: 5.0
Stop sending EULA requests for new purchases

### Problem
As mentioned in [the epic](https://gitlab.com/groups/gitlab-org/-/epics/4225), we no longer require the manual EULA process.  In order to move away from this process, we must stop the generation of new EULA requests.

### Proposal

Update the `ZuoraCallbacksController` to remove references to EULAs.  This means we will no longer send a EULA Request email to the customer and will send the license key directly to the customer instead (for EE plans).

We should also be able to remove [the EULA question in the SKU Issue template](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/938c94efbaaf6cbd50acd6b6d6ed87ceba7e7c03/.gitlab/issue_templates/Sku.md#L26), as this is no longer relevant.

**Important Note: We need to sync this issue of stopping the current EULA request process with the introduction of [the new EULA acceptance process](https://gitlab.com/gitlab-org/gitlab/-/issues/224712).**

Story points: 1.0
Updating company VAT number field fails to save

## UPDATE 2020-09-23

1. This failure occurs when no customer record exists in Zuora
1. The customer record does not exist because no purchase has been made

### Actions

1. Remove the VAT from Account Details page if no Customer exists in Zuora - work for this issue
1. Introduce VAT on all purchase flows for applicable countries #2022 
1. Prefill VAT where available from Zuora and allow customer to overwrite #2023 



---

## Summary

Entering a VAT number under **account details** > **your company details** >> **VAT Number** returns a `Your account has been updated successfully.` message, but the VAT Number input box remains empty. Sounds like it updates the VAT internally, but continues to show an empty field to the customer, causing confusion.

### Steps to reproduce

Set your Country location under Personal Details to any country that would have a VAT number (primarily those within the EU) in order for the VAT number box to appear under company details. Enter a valid VAT number and save the form.

### What is the current *bug* behavior?

Customer portal does not show updated VAT number

### What is the expected *correct* behavior?

VAT should be updated and the input box should reflect the change

### Relevant logs and/or screenshots

No sentry errors that I can find.

Form data looks correct; POST 302s

```
utf8: ✓
_method: patch
authenticity_token: [redacted]
customer[company]: GitLab
customer[vat_code]: 12345678
customer[company_size]: 1-99
```
Server replies with 200.

Appears to be frontend only.

### Reported examples

1. [ZD 169097](https://gitlab.zendesk.com/agent/tickets/169097) (internal only)
1. [ZD 168953](https://gitlab.zendesk.com/agent/tickets/168953) (internal only)
1. [My own test customer portal account](https://customers.gitlab.com/admin/customer/194288)
1. [ZD 173364](https://gitlab.zendesk.com/agent/tickets/173364)

Story points: 3.0
Error when calling namespace change for customer's subscription who does not have a linked GitLab account

### Summary

While conducting some testing for another issue with @vshumilo, we found a 500 error. It happens when clicking the button to `change linked namespace` of a subscription that was created manually in Zuora (sales-assisted purchase) for a customer that has not linked their account to GitLab yet. This results in a `nil` object [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/views/subscriptions/_edit_gitlab_com_plan.html.haml#L7).

### Steps to reproduce

- Have a customer account that has not linked their account to GitLab
- Create a subscription in Zuora for that customer
- Look for subscription in the Customers Portal and click `change linked namespace` for it
- See error

### What is the current *bug* behavior?

A 500 error is raised when clicking on the `change linked namespace` button or calling its page directly via url.

### What is the expected *correct* behavior?

Page for change linked namespace is successfully rendered.

### 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

None

### Possible solutions

Add safe nav (`&`) to the line that raised the error ([here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/views/subscriptions/_edit_gitlab_com_plan.html.haml#L7)).

**But a cleaner overall solution would be:**
Always return an array for the [`GitLab::Namespace::ListService`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/services/gitlab/namespace/list_service.rb) which is used in the a lot of helper methods in [`GitLabPlansHelper`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/helpers/gitlab_plans_helper.rb) with a safe nav (`&`). Although it has to be checked if this affects anything else if an empty Array is returned instead of `nil`.


### Reported examples

1. [Raised error](https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1678514/?query=is%3Aunresolved) for this [subscription](https://www.zuora.com/apps/Subscription.do?method=view&id=2c92a00e73ed8d8701740207ccec6bfd)

Story points: 2.0
Unable to change linked namespace for subscriptions when the quantity is the same AND reconciliations feature flag is enabled

### Summary

Environment: Staging 
Pre conditions: [`reconciliations` feature flag](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags) is enabled

### Steps to reproduce

For any .com subscription that has enabled the `Change linked namespace` action.

1. Check the Subscription quantity.
1. Try linking the subscription to another namespace OR group that has the same quantity via "Change linked namespace" action.

### What is the current *bug* behavior?

The initial selection of such namespace will result on a `422 (Unprocessable Entity)`

### What is the expected *correct* behavior?

We should be able to updated the linked namespace for a subscription when the conditions for such a change [are valid](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/9157567e4f93a4ba9a3412e9aaa849a97c1f37ac/doc/subscription_namespace_change.md) not affected by the quantity.

### Relevant logs and/or screenshots

The issue seems to be related to the `AmendSubscriptionService`.

The `AmendSubscriptionService` will [error](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/b769f1a499cc793a674462f092734d00429201bd/app/services/amend_subscription_service.rb#L17) if it is not able to generate and amendment for the requested action.

The issue seems related to [this check](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/9157567e4f93a4ba9a3412e9aaa849a97c1f37ac/app/services/amend_subscription_service.rb#L42) for when:

- The quantities match
- The subscription is not autorenew and there is not an increase in quantity. 

![Screen_Shot_2020-08-19_at_7.44.35_AM](/uploads/efb727027e96e7b8d0f9325db7f0f3a1/Screen_Shot_2020-08-19_at_7.44.35_AM.png)

![Screen_Shot_2020-08-19_at_7.38.12_AM](/uploads/2089e3c247cf55f98b6c316dd52ab338/Screen_Shot_2020-08-19_at_7.38.12_AM.png)

### Workarounds

This is not affecting production atm because the `reconciliations` feature flag is not turned on for production.

@cwiesner would you please check / highlight anything else to leverage our pairing looking over this and add as much context by combining our brain power! :) Thank you :pray: 

<!---
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
Add SKU for migration +

# SKU Request Summary

The SKU description and official approval process is here: https://gitlab.com/gitlab-com/Finance-Division/finance/-/issues/2803
<!---
Provide a brief description of what this SKU will be used for.
--->



## SKU Requirements

In order to expedite your request, please complete all of the following information. 
Any questions about this template or this request can be directed to @amandarueda in the comments of this issue.

1. [x] SKU Name: Professional Services and Training
1. [x] SKU Code/ID: SKU-00000016 | 2c92a0fc57fb750d0157fe16b0d75e7a
1. [x] Zuora Plan Name: Migration+
1. [x] Zuora Plan ID: 2c92a00c74356b8001744ed8056a4064
1. [x] Service type: `add-on`
1. [x] Does this need to be purchase-able via the customers portal? `No`
1. [x] Does this service renew? `No`
     * [ ] If yes, what is the renewal cadence? `monthly | annually | other`
1. [x] Should an email be sent indicating the subscription is coming to an end?: `N/A` or `no`
1. [x] Is there a unit of measure, if so what? `No`  `Users | Qty | other`
1. [x] Does this service provision anything? `other`
     * [x] If yes, please describe in detail what should be provisioned including the systems affected: Data from legacy systems (bitbucket, github) will be migrated into the destination gitlab system under this service. No infrastructure is provisioned. Wasn't sure if this qualified
1. [x] Does this service require a EULA to be sent? `No`
1. [x] How soon do you need this SKU ? Timeline: As soon as [approval](https://gitlab.com/gitlab-com/Finance-Division/finance/-/issues/2803) clears - Likely in the next 2-3 weeks. 
1. [ ] Who in Sales-Ops approved this request: See approval :point_up: @username
1. [ ] Link to originating Finance issue: https://gitlab.com/gitlab-com/Finance-Division/finance/-/issues/2803
1. [ ] Apply the appropriate `BTG Priority` label to this issue.

Story points: 1.0
Verify Pajamas Update: Portal "Manage Purchases/Add More Seats" Page

This is a follow-up to #954, to verify it's working as expected.

@amandarueda has these notes:

> I found two issues:
> 
> 1. The remaining % appears to be wrong. In the example I've used, the start date is May 6th, so there should be about 10 months of the subscription left, but the % displayed is 17%.
> 1. The amount being charged is definitely off. Not sure if this is related to what @rhardarson posted?
> 
> Here's a video of my test: https://www.loom.com/share/d69935f071664d69a756d58f1bdbec51

Story points: 2.0
Move Zuora callback related logic into a Job

### Problem
In the context of the Subscription Portal, we want to move Zuora interactions to jobs whenever asynchronous execution is a possibility.

### Proposal
Move the logic that executes on `ZuoraCallbacksController#subscription_update` to a job.

### Result
Whenever a callout happens from Zuora regarding a subscription update: Amendments, New Subscriptions, Refunds.
Instead of executing the `subscription_update` logic inline we will enqueue a Job that will take care of the further required:
- Zuora queries
- Gitlab sync

### How will we measure success?
- We expect to see more successful codes in the Zuora Notification Callout History (meaning the Jobs have been enqueued on our end)
- We will have more control on retries for the sync to happen if it is on our end.

Story points: 2.0
Replace begin block with strong memoize

Change blocks of code that are currently defined like:

```ruby
 def z_subscription
    @z_subscription ||= begin
      Zuora::Subscription.active_find_by(name: callback_attrs[:subscription_name]) ||
        Zuora::Subscription.find_by(id: callback_attrs[:subscription_id])
    end
  end
```

to this:

```ruby
 def z_subscription
    strong_memoize(:z_subscription) do
      Zuora::Subscription.active_find_by(name: callback_attrs[:subscription_name]) ||
        Zuora::Subscription.find_by(id: callback_attrs[:subscription_id])
    end
  end

```

The following discussion from !1777 should be addressed:

- [ ] @cwiesner started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1777#note_393904099):  (+3 comments)

    > **nitpick:** Since we're already touching this file, what do you think about replacing `begin` with `strong_memoize`? It was introduced a while back.

Story points: 2.0
Document Salesforce flow and understanding around it

In regards to discussion happening around [this issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1758#note_394200743), it would really be nice to have a document dedicated around understanding of what Salesforce is and how customers portal is making use of it. 

This include understanding as how the Sales team is making use of it and also the flow happening from the customers portal to SF including the parameters send and the parameters received.

Story points: 1.0
Investigate Zuora callback failure

### Problem
Zuora callbacks are failing and being logged in Sentry, and no action is take on them. This could result in other problems such as [CI minutes not being provisioned correctly](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1740)

@djparker notes that we should return a HTTP body on failure because Zuora logs these responses.

Story points: 5.0
Migrate feature flags to new version

<!-- 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

We've got ~20 [feature flags active now](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags) which will be set to read-only as of 13.4

For example: https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/19/edit

![image](/uploads/e23eab610f502c4837f21541129ed1a0/image.png)

### Proposal

Migrate our feature flags to the new shiny feature flags :)

It'll be a bit of manual process. To minimize risk we can adopt this pattern @ogolowinski suggested

```
I have a flag "A", create new flag "new_A". Verify "new_A" is correct. Delete old flag "A", Rename "new_A to "A".
```

Story points: 1.0
Sync with Zuora's local product data during deployment

After !1762 is merged, Zuora's product data can be cached locally to avoid API calls. Currently it is done manually by asking someone with production console access.

Since currently a refresh would also require a server restart, we should trigger the refresh during deployment.

- [ ] @jameslopez started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1762#note_393098608):  (+2 comments)

Story points: 1.0
Validation error on Gitlab::Namespace::UpdatePlanInfoService

### Problem

There is a validation error that's happening in some scenarios when this service is invoked and it's affecting the sync to GL.com.

Sentry:

https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1712530/events

https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1713125/events

REF: https://gitlab.com/gitlab-com/support/internal-requests/-/issues/2868

### Proposal

Provide a fix.

### Result

The sync to GL.com can be completed

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Improve Digital Signature raise clauses

The following discussion from !1766 should be addressed:

- [ ] @dstull started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1766#note_391997523):  (+1 comment)

    > this area could likely benefit in a diff MR from some methods made around these conditionals to make them more readable...  something like
    > 
    > ```ruby
    > def invalid_page_id?
    >   page_id != payment_page_id(payment_type)
    > end
    > ```

Story points: 2.0
Resolve misspelling of GitLab

The following discussion from !1766 should be addressed:

- [ ] @a_akgun started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1766#note_392225696):  (+1 comment)

    > @dstull there's a typo here  `eligible_to_purchase_gilab_plan`, for another issue.

Story points: 1.0