giseldo/neodataset huggingface dataset:
Copy to clipboard or download license throws 404 error

<!---
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

- Given a customer with a self-managed subscription 
- And a valid license in license.gitlab.com
- When I click on download license on the subscription card in customers.gitlab.com
- Then I am redirected to `https://customers.gitlab.com/licenses/CCV%20Group%20B.V.-%2035%20Starter`
- And I see a 404 error with the following text: 

```
This customers.gitlab.com page can’t be found
No web page was found for the web address: https://customers.gitlab.com/licenses/CCV%20Group%20B.V.-%2035%20Starter
HTTP ERROR 404
```

- Given a customer with a self-managed subscription 
- And a valid license in license.gitlab.com
- When I click on `Copy license to clipboard` on the subscription card in customers.gitlab.com
- An error appears in the bottom left corner of the screen, with text:
```
An error occurred, please try again later
```

### What is the current *bug* behavior?

I suspect the cause is related to the special characters in the subscription name which is causing the error.

### What is the expected *correct* behavior?

The license should download or copy to clipboard

### Relevant logs and/or screenshots

- [Customers account](https://customers.gitlab.com/admin/customer/109681/edit)
- [Valid license](https://license.gitlab.com/licenses/154675)
- Screenshot:
![Screenshot_2021-02-02_at_13.51.06](/uploads/17a2021e801619d03e61ac74558944f5/Screenshot_2021-02-02_at_13.51.06.png)

### Workarounds

(Ways to get around the issue)

### Reported examples

1. https://gitlab.zendesk.com/agent/tickets/191611
1.
1.

<!---
Please add both severity and priority level according to: https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#severity-labels
--->

Story points: 2.0
Add route to purchase self-managed plan on the lowest tier

<!-- 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

For new purchases of self-managed plans we currently use the URL schema

`https://customers.gitlab.com/subscriptions/new?plan_id=[PLAN_ID]&test=capabilities`

This means that external routes like [a subscribable in-app banner](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2582) need to know the planId for the lowest tier in order to link to "lowest possible purchase"

### Proposal

Add a route like `/subscriptions/new?lowest_tier_plan_for=[self_managed|saas]` which puts the responsibility of knowing the planId on CustomerDot. This way the consumers (in-app banners) have a static URL they can consume.

Story points: 5.0
Follow-up: unify terminology - rename yearly to annual

### Problem

In #2618 we unified the terminology in the renew and upgrade pages.

### Proposal

Rename `yearly` to `annually` in:

- [x] `./app/frontend/javascripts/subscription/components/add_seats_invoice.vue`
- [x] `./app/frontend/javascripts/subscription/components/new_ee_subscription_form.vue`

![Screenshot_2022-01-25_at_12.42.41_PM](/uploads/5bca0390996d4e99bb3ca2a37779ba7f/Screenshot_2022-01-25_at_12.42.41_PM.png)

And update tests as needed.

### Result

Consistent terminology

### Next steps (if any)

Schedule

### How will we measure success?

Story points: 2.0
EoA: Cancelled subscription is not obvious

## Summary

We no longer show the autorenew toggle/cancel button since we updated all Bronze/Starter to autocancel. This has increased user confusion (pre-existing issue) over how to cancel their subscription.

In the subscription header, it states the expiration date which implies it will cancel but I think we need something more eye-catching.

In this iteration, I'd like to ship a quick solution to the CustomersDot subscription card for subscriptions set to cancel. This should be applicable to all subscriptions which are not set to autorenew, not just Bronze/Starter.

Perhaps a colored badged that says "cancelled" and when you hover over it there is text along the lines of "this subscription will not automatically renew and will cancel on the expiration date. Please select the renew button to continue your subscription for another year." ... ish?

I'm totally open to alternative ideas, whatever it is, would be good to ship asap.

![Screen_Shot_2021-01-28_at_9.11.43_a.m.](/uploads/40e3272e97b8461dc04fd6a18b9c3644/Screen_Shot_2021-01-28_at_9.11.43_a.m..png)

Story points: 1.0
Follow-up: Clean up old account settings page

## Cleaning up 🧹

In !2669 we cleaned up the old account settings, however, there are still some things that need to be done:

* [x] Remove the marked as deprecated route and controller for getting countries and states.
* [x] Remove the old JS code for toggling VAT field.
* [x] Ensure `vue_account_details_page` feature flag is cleaned-up from the source code
* [x] Verify then remove `vue_account_details_page` from feature flags
* [x] Ensure `pajamas_account_page` feature flag is cleaned-up from the source code
* [x] Verify then remove `pajamas_account_page` from feature flags

Story points: 2.0
Increase test coverage to include tax responses

<!-- 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

In https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2623 we identified that subtotal was showing total + tax.

This should have been caught by automated tests, not in production.

### Proposal

Cover this path with tests to guard the fix

Story points: 1.0
Add GraphQL support to send CI plans

As mentioned here https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2346#note_493198951, we need to send CI plans too to the GL.com to allow the GL.com show the plan and the values associated with it and extend the current implementation to include the CI minutes plan.

We need to have an GraphQL endpoint to send the CI plans.

Story points: 1.0
EoA: Free upgrade flow license doesn't generate with trueups

<!-- 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 the customer has a current Starter subscription with trueups
- And they choose the free upgrade to Premium (without renewal)
- Then the upgrade license generated doesn't include the trueups in their subscription

### Proposal

Upgrade licenses should include trueups from the original subscription

### Reported examples:
1. https://gitlab.zendesk.com/agent/tickets/190385
1. https://gitlab.zendesk.com/agent/tickets/190745
1. https://gitlab.zendesk.com/agent/tickets/190523
1. https://gitlab.zendesk.com/agent/tickets/190511
1. https://gitlab.zendesk.com/agent/tickets/190793
1. https://gitlab.zendesk.com/agent/tickets/190933
1. https://gitlab.zendesk.com/agent/tickets/191146

Story points: 2.0
Upgrade offer is visible for Bronze subscription not associated with a namespace

<!-- 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/

-->

# Q: I have a Bronze subscription and want to take this offer, however I'm blocked by this behaviour

You need to [Change the linked namespace](https://docs.gitlab.com/ee/subscriptions/#change-the-linked-namespace) to unblock yourself

1. Log in to the [Customers Portal](https://customers.gitlab.com/customers/sign_in) with a linked GitLab.com account.
1. Navigate to the Manage Purchases page.
1. Select Change linked namespace.
1. Select the desired group from the This subscription is for dropdown.
1. Select Proceed to checkout. 

If this doesn't work see below :point_down: 

# Q: I tried to Change the linked namespace however my intended group is greyed out

Then it's a data-integrity issue. Quickest way to resolve this is to open [a support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=360000071293)

---

# Development on UI bug

### Problem

![Screenshot_2021-01-27_at_08.22.34](/uploads/f14def69aa9eead0dbaec1cb878d3717/Screenshot_2021-01-27_at_08.22.34.png)

On the `/subscription` overview, we show the Upgrade offering for Bronze subscriptions.

However some subscriptions do not have namespaces associated with them, for example if the namespace was deleted.

### Proposal

Only show the upgrade offer banner if Subscription is associated and active. We can check this with `upgradeSubscriptionPath` for example.

### Result

We do not confuse our users with a banner prompting them to action and then they can't take action.

### Setting up local development for this case

Follow [How to create a subscription, generate an invoice and post the invoice in Zuora sandbox](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob)/staging/doc/resource_videos.md#resource-video-library

Story points: 1.0
Follow-up from "Allow users to manually renew subscription up to 30 days post expiration"

The following discussion from !2408 should be addressed:

- [ ] @asubramanian1 started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2408#note_485659990):  (+3 comments)

    > **question:** Should we also consider restricting in the ~backend api? If yes, I'm okay if you want to do it as a follow up.

Story points: 2.0
Inconsistent error response structure

<!-- 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

In our frontend [we look for a human-readable error to present to the user](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/c330e163096f2968413a4f76cd64c9c28ce248bf/app/frontend/javascripts/parse_responses.js#L15-26) so the user can correct what's erroring out if possible.

The format the frontend expects is

```
{ 
  gateway_response: "Insufficient funds" // this structure we inherit from Zuora
}

// OR
{
  errors : {
    message: "Can't renew for less than current user count",
    code: "RENEW_COUNT_FAILURE" // optional field if something special should be flagged on the frontend
  }
}

```

However we're not always following this structure. Below are instances of `{ error: "Something went wrong" }` in our codebase

```
~/workspace/customers-gitlab-com staging ⇣
❯ git grep "render json: { error:"
app/controllers/application_controller.rb:        render json: { error: 'We were unable to process this transaction.' }, status: :unprocessable_entity
app/controllers/orders_controller.rb:          render json: { error: "Error when processing subscription: #{params[:subscription_name]}" },
app/controllers/plans_controller.rb:        render json: { error: e.message }, status: :internal_server_error
app/controllers/subscriptions_controller.rb:    render json: { error: 'We were unable to process this transaction.' }, status: :unprocessable_entity
app/controllers/zuora_callbacks_controller.rb:      render json: { error: result[:error] }, status: :internal_server_error
```

### Proposal

Update the instances to the proper error structure.

### Result

Users do not get hit with a generic error message that will trigger a Support ticket.

Story points: 2.0
Follow-up - add EDU and OSS plans to gitlab_ee_edu_oss_plans

The following discussion from !2560 should be addressed:

- [ ] @ebaque started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2560#note_488467260):  (+7 comments)

    > @vij Can you please review this MR?

Story points: 2.0
Display of credit card iframe looks broken for narrow viewport widths





<!-- 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 Zuora credit card iframe layout breaks when the viewport (browser window) size gets narrower.

| Wide viewport width - looks good | Narrow viewport width - layout breaks |
| --- | --- |
| ![Screenshot_2021-01-18_at_12.23.09](/uploads/faa15172b94e10a6a463b78dcd53b411/Screenshot_2021-01-18_at_12.23.09.png) | ![Screenshot_2021-01-18_at_12.23.37](/uploads/98def1c9e039a75afd568d38e375699d/Screenshot_2021-01-18_at_12.23.37.png)|

### Proposal

We need to tweak the styles so the iframe looks good no matter the viewport width.

Story points: 2.0
Unhelpful error message: Could not purchase subscription, if the problem persists please contact support.

<!-- 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

From [our logs](https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1778206/?query=user%3A230063), we can see that the purchase is failing because of the credit card, however, the error message is not helpful.

![Screen_Shot_2021-02-08_at_10.55.45_a.m.](/uploads/72bd47b43f392094015e2a3717532718/Screen_Shot_2021-02-08_at_10.55.45_a.m..png)

[In the last 30 days, there has been 408 users affected by this message](https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/1896180/?query=user%3A230063)

### Proposal

When a card has insufficient funds or the card is declined, we should be a displaying an error message to indicate that the card being used is causing the purchase failure.

### When possible show the `message` from backend

We're throwing away the human readable error message we get from the backend and from Zuora.

Replace the instances of throwing away the error message with the following:

```
diff --git a/app/frontend/javascripts/subscription/components/add_seats_form.vue b/app/frontend/javascripts/subscription/components/add_seats_form.vue
index c18bf3c15..5eb3ba124 100644
--- a/app/frontend/javascripts/subscription/components/add_seats_form.vue
+++ b/app/frontend/javascripts/subscription/components/add_seats_form.vue
@@ -130,7 +130,7 @@ export default {
           Sentry.captureException(error);
           this.$emit(
             'error',
-            'Could not add seats for the subscriptions, if the problem persists please contact support.',
+            error.message
           );
         })
         .finally(() => {
```

### New error message text

We should replace the current message with the following text [received from technical writing](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2536#note_504340966)

>This credit card transaction could not be processed. Please verify the information or try another card.

### Reported examples:

1. https://gitlab.zendesk.com/agent/tickets/188236
1. https://gitlab.zendesk.com/agent/tickets/200402

Story points: 3.0
Follow-up: add tests to cover state in upgrade app

We want to add tests for the new vue upgrade app, covering any change in `isLoading` and in `purchaseButtonEnabled()`.

The following discussion from !2500 should be addressed:

- [ ] @agulina started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2500#note_484333481): 

    > **tests (non-blocking)**: we need a follow-up to add tests that cover the transitions of this state.

- [ ] @agulina started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2500#note_484333483): 

    > **tests (non-blocking)**: we need a follow-up to add tests that cover the transitions of this state.

Story points: 1.0
Follow-up from "Follow-up new upgrade app"

The following discussion from !2500 should be addressed:

- [ ] @agulina started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2500#note_484333448):  (+2 comments)

    > **suggestion (non-blocking)**: I'd like to follow-up on this as I think there's space for some simplification (e.g., separating the concern of having a `selectedUpgrade` and `updatingPreviewData`) and especially for leveraging Vue reactivity.
    > 
    > I will produce a patch for a later iteration, if you agree with it :smile:

Story points: 1.0
Exclude danger job from deployment stages

### Problem

We want the Danger job to run only in MRs, where it's the most useful, but not in other places like the deploy stages where it's just redundant and its feedback won't be used. 

Related Slack discussion: https://gitlab.slack.com/archives/CMJ8JR0RH/p1610355001054300

### Proposal

Make Danger job run only on MRs only.

Story points: 2.0
Investigate possibility of using GitLab UI variables in Rails mailers

The following discussion from !2439 should be addressed:

- [ ] @jakeburden started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2439#note_479902567): 

    > **nitpick (non-blocking)**:
    > 
    > We only have two variables defined, but there are a few more repeated values in the rest of the file.  Since this is a copy of the scss found in [LicenseDot](https://gitlab.com/gitlab-org/license-gitlab-com/-/blob/e5f92740731119d8236c53d571b06befba287ab5/app/assets/stylesheets/mailers/customer_mailer.scss), I don't think it should a blocker here, but rather we should open a follow-up issue to define specific values as scss variables.

Story points: 2.0
Purchase form stuck in processing when a payment is not completed

<!---
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

A customer report that when making a purchase on [customers portal](https://customers.gitlab.com/customers/sign_in), the payment was blocked because the bank thought the payment was suspicious which cause the payment page on customer portal to stuck as if it's still processing the payment.

### Steps to reproduce

(How one can reproduce the issue - this is very important)

1. Make a purchase on [customers portal](https://customers.gitlab.com/customers/sign_in)
1. Get the transaction to be blocked by the bank
1. See the payment form stuck in the processing state

### What is the current *bug* behavior?

The payment form stuck in processing state without providing any useful information

### What is the expected *correct* behavior?

If there's an error, we should provide an error message and reason why the error happened.

### 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.)

`payment_method:17 Uncaught SyntaxError: Unexpected token '&'`

The code is as follows:
```
<script>
window.parent.dispatchEvent(new CustomEvent('zuora-errors', {
detail: {
page: window.parent.document.body.dataset.page,
errors: [&quot;Transaction declined.do_not_honor - Your card was declined.&quot;]
}
}));
</script>
```

![gitlab-failed-payment](/uploads/ab5782a222d12ee4a96027f2e63f5b03/gitlab-failed-payment.png)


### Workarounds

(Ways to get around the issue)

### Reported examples

1. https://gitlab.zendesk.com/agent/tickets/187119
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
Combine FindCurrentSubscriptionVersionService logic into Subscription.current_subscription class method

# Purpose

In https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2460, we've introduced a way to find the current version of a subscription record via the `FindCurrentSubscriptionVersionService`.  In the past we also introduced a class method on the `Subscription` model called `current_subscription` which finds the current rate plans and rate plan charges for a given subscription (but didn't find the current subscription version).  It was our intention when that class method was introduced to go back when we were able to find the current subscription version and incorporate that logic.

The following discussion from !2460 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2460#note_481241444): 

    > I was thinking that once we had the strategy for getting the current version of the subscription, we could incorporate that into [the `Subscription.current_subscription` method](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/7db573eb22a7f877e9ea4eaa6a442499f16d7b11/app/models/subscription.rb#L31).  When we did that, we could use that here if we wanted (but not sure if it makes sense).  This sounds like a good candidate for a follow-up issue.  I'll go ahead and create it, assuming you are on-board with it, but let me know if you have concerns.

Story points: 2.0