giseldo/neodataset huggingface dataset:
Follow-up from "Update expired subscription downgrade process"

The following discussion from !3379 should be addressed:

- [ ] @rcobb started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3379#note_613651926):  (+1 comment)

    > Random thought: Not related to this MR but IMO having these checks here is a bit unintuitive. I think moving them to their own method makes their intent more clear.
    > 
    > ```ruby
    > def end_date_in_sync_with_zuora?
    >   return true unless check_zuora_end_date?
    > 
    >   order_end_date.to_s == zuora_subscription_end_date.to_s
    > end
    > 
    > def check_zuora_end_date?
    >   return false if order.trial?
    >   return false if end_date_before_expiration...
    >   ...
    > end
    > ```

Story points: 2.0
Remove collapse component from subscription card

## Proposal

- Remove the collapse component that wraps the subscription card, as [suggested](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3374#note_604989438) by @timnoah.

- Removing the collapse also removes the thick border around the subscription card.

- Replace the thin border between cards with a thick gray 4px border.

## Design

**[Figma Specs](https://www.figma.com/file/yjusTZF6Qgr4DzXkvE5bK2/Customers-Portal-Templates?node-id=1113%3A4023)**

![Manage_purchases_-_Updated](/uploads/69ffb582aa55e4163040d78270791e37/Manage_purchases_-_Updated.png)

Related to #3140 and !3374.

Story points: 2.0
Downloading licenses can lead to LicenseOutOfSyncError

### Problem

[Tom Houston reported](https://gitlab.slack.com/archives/CMJ8JR0RH/p1624288923284200) earlier today that he came across 2 customers who are getting 500 errors when trying to download their license.  The system shows an error when trying to display the license in CustomersDot.  

He's seeing the following errors in both cases:
```
ObtainLicenseService::LicenseOutOfSyncError: ObtainLicenseService::LicenseOutOfSyncError License and subscription are out of sync
```

#### Links to Customer accounts and tickets:
- https://gitlab.zendesk.com/agent/tickets/219463
- https://gitlab.zendesk.com/agent/tickets/219343
- https://customers.gitlab.com/admin/customer/291084/edit
- https://customers.gitlab.com/admin/customer/184727/edit

### Proposal

This appears to be related to a recent change in the way licenses are downloaded in CustomersDot, introduced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3315.  After a cursory look, this seems to be happening in the `ObtainLicenseService` where the license is being compared to the current subscription.  However, this code should not be used yet as it should be behind the `cloud_license_sync` feature flag.

Story points: 2.0
Conditionally create a license in CustomersDot if missing using feature flag

### Problem

As described in [this Slack thread](https://gitlab.slack.com/archives/CMJ8JR0RH/p1623853191158300), we realized that a handful of licenses were being created in CustomersDot rather than LicenseDot before the `cloud_license_sync` feature flag was enabled.  It turns out this began after we merged https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3315 which creates a license if one doesn't exist when users attempt to download or copy a license.  This feature creates the license using CustomersDot rather than LicenseDot, which wasn't expected until the `cloud_license_sync` is enabled.

### Proposal

Update the `ObtainLicenseService` to avoid creating a license in CustomersDot if the `cloud_license_sync` feature is disabled.  Instead we should fallback to the old behavior of raising an error instead.

Story points: 2.0
Customers should only be able to renew 15 days before subscription expiration date

### Problem

Today, customers are able to renew their subscription early via the Customer Portal. This can create various downstream issues, like the following:

1. [Early renewal can cause issues for reconciliations](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3182)
1. [Prevent users from accidentally renewing multiple times
](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1099) 
1. [Renewing subscription multiple times will cause trueup error when its count is changed](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3268)

Sales Assisted renewals have already been aligned to the [FY22 Booking Policy](https://about.gitlab.com/handbook/sales/field-operations/order-processing/#renewal-opportunities), which states that we wait to close the renewal till 15 days from renewal date.  We now need to align self-service renewals to the same policy.

Original issue thread: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3182#note_599340590

### Proposal

Prevent early renewals by hiding "Renew" button 15 days before Subscription End Date, and add a related check in the backend. 

~backend specific tasks:

- Lock down the `/renew` route from the backend. Hiding the `renew` button isn't sufficient since we're linking to the renew route from multiple places (CustomersDot, Billing page)

~frontend specific tasks:

- Disable the "Renew" button 15 days before Subscription End Date
- Add a tooltip explaining why it's disabled (perhaps `Ability to renew will be available in X days`)

### Result

Customers can only renew their subscription 15 days before renewal date.

### Next steps (if any)

### How will we measure success?

Story points: 3.0
Add Invoice Item Charge Amount and Invoice Data and Entity to Data Packet

<!-- 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
While reviewing the Data we receive from Web Directs we found 2 additional fields that will be needed to fully automate our reconcile process and 1 that is blocking us from getting the correct charged Amount on prorated add-ons.

### Proposal
Please add the following fields to the Rate Plan Charge payload pointed at the corresponding Salesforce fields:

| Salesforce Field                      | Zuora Object chain                     |
|---------------------------------------|----------------------------------------|
| Webstore_Zuora_Invoice_Entity__c      | Invoice Item: Invoice: Account: Entity |
| Webstore_Zuora_Invoice_Date__c        | Invoice Item: Invoice: Invoice Date    |
| Webstore_Zuora_Invoice_item_Charge__c | Invoice Item: Charge Amount            |


### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Expired subscriptions downgrade - modify Plan scope

### Summary

The expired subscription downgrade process is based on this following query:

```
orders = Order.saas_subscriptions.full.where('end_date < ?', expiration_date)
```

The use of the `saas_subscriptions` scope means that we're limiting our query so that only orders related to specific Plan are  retrieved.

### What is the current *bug* behavior?

The retrieved `Order` objects are related to one of the following plan:
- Ultimate Saas 1 Year plan: `2c92a0ff76f0d5250176f2f8c86f305a`
- Premium Saas 1 Year plan: `2c92a00d76f0d5060176f2fb0a5029ff`
- (Deprecated) Gold plan: `2c92a0fc5a83f01d015aa6db83c45aac`
- (Deprecated) Silver plan: `2c92a0fd5a840403015aa6d9ea2c46d6`
- (Deprecated) Bronze plan: `2c92a0ff5a840412015aa3cde86f2ba6`

### What is the expected *correct* behavior?

Orders should be retrieved regardless of related plan. Ensure at least that it is a Saas plan.

Story points: 2.0
Refactor condition to be easier comprehensible

The following discussion from !3366 should be addressed:

- [ ] @cwiesner started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3366#note_600340545): 

    > `return unless current_customer && !params.key?(:edit_namespace) && gitlab_com_lead`
    >
    > **nitpick (non-blocking):** Not for this merge request but we should refactor this condition to make it easier comprehensible.

### Proposal

This can be done by using an `if` instead of an `unless` which is easier to understand on a quick look.

Story points: 1.0
Validate Customer's License File

## User Story

As product owner, I want to examine the customer's license file, when available, so that I can determine whether the file is valid or not and understand whether that is causing the 401 HTTP response.

## Acceptance Criteria
- [License file](https://gitlab.com/gitlab-com/account-management/eastern-north-america/ihs-markit/-/issues/69#note_601131184) is validated and a determination is made on whether its validity is causing the 401 error.

> SyncSeatLinkRequestWorker::RequestError: Seat Link request failed! Code:401 Body:{"success":false}



## Customer Issue Reference
- https://gitlab.com/gitlab-com/account-management/eastern-north-america/ihs-markit/-/issues/69

Story points: 3.0
Clean up wsdl file

<!-- 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/-/blob/70b04d0db1a918b1e8c803d943acab4776b391ec/config/application.yml#L169 we're referencing a WSDL file that's version 88. The newest version of this file is 109.

Moreover it looks like this file is no longer used since we moved away from SOAP https://gitlab.com/groups/gitlab-org/-/epics/1993


### Proposal

1. Confirm this is no longer used in our project and cookbooks.
1. Confirm this is not used in our 3rd party code like https://github.com/sportngin/active_zuora
1. Delete reference and record cassettes to remove the references - [example](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/spec/fixtures/vcr_cassettes/amendmentbaseservice/_amend_/with_2_line_items_e_g_adding_and_removing_product_/logs_sending_amendment_request.yml#L5)

Story points: 2.0
Self-Managed - Community Programs Self-Checkout - Coupon code input

As part of https://gitlab.com/groups/gitlab-org/-/epics/5068 users will be guided to CustomersDot need input the coupon code they've received.

[Designs](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2677/designs/Community_programs_checkout___Invalid_coupon_code_error.png)


![image](/uploads/196f6cc2c92d5541d007507af9f48688/image.png)


### TODO

1. Add input field for coupon code
1. Pass coupon code to API payload when purchasing subscription following https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2362
1. Render error message inline if code is consumed `This code has already been used.` or not valid `This code is not valid. Try re-entering the code from your email`

### How to see the pages

- Make sure you've the [`community_program_coupons`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/91/edit) enabled for your setup.
- Login to your CustomersDot
- Navigate to any of:
  - `/subscriptions/community_program/new?edition=self_managed&coupon_code=coupon_test&product=oss`
  - `/subscriptions/community_program/new?edition=saas&coupon_code=coupon_test&product=oss`

BE logic issue: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2362

Story points: 3.0
Extract Community Program Subscription Data loading out of the view layer

### Problem

Follow up from https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3292

We have data in the following views that relies on the `GitlabPlansHelper` for loading and formatting the data for the frontend:

1. `app/views/subscriptions/community_program/new_saas.html.haml`
1. `app/views/subscriptions/community_program/new_self_managed.html.haml`
1. `app/views/subscriptions/_new_gitlab_com_subscription.html.haml`
1. `app/views/subscriptions/_new_ee_subscription.html.haml`

We should extract the data loading out of this helper (into the controller?) ~~and move the presentation logic to a presenter so that it is easier to test~~. Helper methods are available across all controllers, so moving this logic to a presenter class will help us signal more clearly what it applies to.

### Proposal

1. ~~Create one or several presenters to format the data for the new subscription pages~~
1. Load and filter the eligible namespaces in the controller/services instead of the view helper
   - Currently this is happening in `GitlabPlansHelper#gitlab_namespaces`

**Note:** after extracting the data loading into the controllers, it didn't seem as important to create presenters so we've decided to leave this part for now.

Story points: 5.0
Remove report_date from LicenseSeatLink

### Problem

In https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3163, the `SeatLinkCreateService` was updated to always save `LicenseSeatLink` records with a `report_timestamp`, even when `timestamp` isn't provided in the request params.  If `timestamp` is missing, the `date` param is used to construct a timestamp instead (e.g. `date` + 3:00 UTC). This was added in https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3356.  Other MRs related to https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3163 were merged to remove the dependence on `report_date` like backfilling `report_timestamp`, along with transitioning DB constraints from `report_date` to `report_timestamp`.

With these changes, we no longer need to continue storing or referencing `report_date` on `LicenseSeatLink`.  All logic in CustomersDot should use `report_timestamp`.

### Proposal

In this issue, we should finish the steps to removing `report_date`.

- Remove any remaining references to `report_date`
- Ignore the column in the model.
- Remove the column from the database.

Story points: 2.0
Follow-up from "Execute Salesforce::CreateLeadService async"

The following discussion from !3347 should be addressed:

- [ ] @vij started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3347#note_594561479):  (+3 comments)

    > Do we need to call `set_logger` here? If I've traced it through correctly, without passing a filename arg, I think [it assigns the `Sidekiq::Logger`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/853bd226bc41167336b5cb5f739823da05088658/app/workers/concerns/loggable_worker.rb#L20), which is also the default? :thinking: 

Also it was noted that the name: `ZuoraWorker` was no longer accurate and misleading because this is too used for Salesforce interactions so we will rename it to something less specific.

This service specifically includes rescue / raise logic that relies on Zuora and Salesforce [error codes](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/01446ba03a7aa99f3fed1dec17fcfea87dd0a611/lib/errors.rb#L13) so will try with `IntegrationWorker` because we already have a `BaseWorker`.

### Proposal

- Update all workers that `include ZuoraWorker` to not call `set_logger` when the intention is to use the default `Sidekiq.logger`.

- Rename `ZuoraWorker` to `IntegrationWorker`

Story points: 2.0
Tooltips with seat-link info do not render properly for self-managed subscription cards

## Description

If there is more than a Self-Managed subscription on the page that is canceled, only the first one gets the tooltip displayed for the Resume button. This could happen because all rendered tooltips have the same target ID.

## Video

![Screen_Recording_2021-06-10_at_14.09.14](/uploads/a93ea52db6990e097d42be9bc139a32f/Screen_Recording_2021-06-10_at_14.09.14.mov)

Story points: 2.0
[UX] Cloud Licensing - Workflow for Expired Cloud License

### Problem

After a license expires, the GitLab instance becomes blocked and git features like pushes are blocked. Here's a link to the docs on this: https://docs.gitlab.com/ee/user/admin_area/license.html#what-happens-when-your-license-expires. When a customer is using a license file they will renew their subscription and upload a new license file to reinstate the features or remove the license file. This will be the same behaviour for cloud licenses, but there is currently no way for a customer to remove a cloud license from their self-managed instance. This issue is to design/investigate the removal of a cloud license. [Original discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3215#note_595998053).

I've created [this issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3512) to also discuss a better way to gracefully handle the downgrading of an expired license as I'm unsure whether we should be blocking git features like pushes.

### Proposal

- Add a remove license button to the Admin > Subscription page for cloud licenses
- Follow the same removal flow as legacy licenses
 
[**Figma design specs**](https://www.figma.com/file/0cuDNaL8iPZdUaMY8vtBzh/Workflow-for-Expired-Cloud-License?node-id=2%3A6791)

Story points: 2.0
Follow-up from "Add cleanup_groupless_subscriptions rake task"

The following discussion from !3361 should be addressed:

- [ ] @vij started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3361#note_596397219):  (+2 comments)

    > I think it's kind of nice having them defined in this file so you know what's going on at a glance, but there's an existing helper for stubbing this call, if you'd rather use it (apologies if you already know about it, but I just wanted to point it out incase you didn't):
    > 
    > https://gitlab.com/gitlab-org/customers-gitlab-com/blob/853bd226bc41167336b5cb5f739823da05088658/spec/support/stub_gitlab_calls.rb#L159

Story points: 2.0
Conditionally show address block in customer info

## Description

As entering the user address is optional, we have to make the component that displays the customer info conditionally show the address. At the moment, when the user hasn't entered an address, we display an empty HTML container that has spacing applied to it. This doesn't result in predictable vertical spacing and it hinders accessibility.

Maybe as part of this issue we can revisit the HTML elements that are shown inside of the customer info component so we make sure they're semantic.

The component is called `customer-information.vue`.

This issue is a follow-up from https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2089

## Screenshots

| User can leave out their address fields... | Empty containers rendered in DOM |
| --- | --- |
| ![Screenshot_2021-06-08_at_17.20.29](/uploads/a6f964bc77cd7ede9b0a74cc4a40bf09/Screenshot_2021-06-08_at_17.20.29.png) | ![Screenshot_2021-06-08_at_17.31.21](/uploads/a4f2069f470009ebd0edd733bb5e75c9/Screenshot_2021-06-08_at_17.31.21.png) |

Story points: 2.0
remove AutoRenew__c from the schema files

We have renamed the Custom Auto Renew Zuora custom field API name from `AutoRenew__c` to `TurnOnAutoRenew__c`(issue https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2947)

After renaming , `AutoRenew__c` is now useless. It should be removed.

We need to remove `AutoRenew__c` from the [schema files](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/5fe12ca3016abc4814fdf756afa6896869dfec53/config/zuora/production/schema/Subscription.xml#L53) as well. And then we can remove the Zuora custom field.


### Problem

`AutoRenew__c` is now useless. It should be removed.

### Proposal

remove `AutoRenew__c` from the schema files
- Production schema file https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/5fe12ca3016abc4814fdf756afa6896869dfec53/config/zuora/production/schema/Subscription.xml#L53
- Sandbox schema file https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/5fe12ca3016abc4814fdf756afa6896869dfec53/config/zuora/sandbox/schema/Subscription.xml#L53
- Staging schema file https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/def98ff782c5f26107bce05e2c3e3cb746654276/config/zuora/staging/schema/Subscription.xml#L145

### Result
`AutoRenew__c` is removed from the schema files

### Next steps (if any)

- [ ] Ask @mquitevis to remove the Zuora Subscription custom field `AutoRenew__c`

### How will we measure success?

Story points: 2.0
Download invoice link shows 404

<!-- 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

Sometimes on invoice page, a `download invoice` link shows up and is clickable, but results in a 404 page.

e.g. pipeline https://gitlab.com/gitlab-org/customers-gitlab-com/-/jobs/1262188785

![image](/uploads/322f10a4de1133201301d689718daec0/image.png)

We had [Slack discussion](https://gitlab.slack.com/archives/CMJ8JR0RH/p1618003253143800) identified root cause is a delay from Zuora when generating invoice for new subscription.

### Proposal

UI improvement proposed - a temporary text field showing `Processing...` on invoice page instead of providing a download link when invoice is not ready from Zuora :point_down: 

![image](/uploads/01f95706df9299ba8d08ad76ec65d4a8/image.png)

### Result

### Next steps (if any)

### How will we measure success?

Story points: 3.0
Perform amendment to update rate plan charge for EOA

As part of the main issue https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2783, we have worked on calling to [update the `rate_plan_charge`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/services/amendment_base_service.rb#L267) whenever the user has [accepted/declined the EOA offer](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/services/amendment_base_service.rb#L272). 

This callback is made after the renew has been amended and [via a background job](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/workers/update_subscription_eoa_starter_bronze_offer_worker.rb) which makes a call to update the custom value [`EoaStarterBronzeOfferAccepted__c`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/app/workers/update_subscription_eoa_starter_bronze_offer_worker.rb#L43) and then traverses though the rate_plans to find the rate_plan_charges which are part of PREMIUM plans and then make the changes to the `price_change_option`.

These changes can be resulted into an error by Zuora which is then just logged into the Sentry and no rescue of the error is then called in place.  

### Proposal

The amendment takes place in a batch and if one results in error then all of it is rolledback by Zuora. Instead of calling the update on `rate_plan_charges` after the amendment happens we can add another amendment to the batch to update the rate_plan_charges `price_change_option` itself. 

cc: @vshumilo

Story points: 5.0