giseldo/neodataset huggingface dataset:
Community Programs - Allow for purchases with no payment methods

## Problem

When purchasing Community Programs on an account with no payment methods (which the majority of our Community consumers will do) the purchase will fail with `Can not have Account with Auto-Pay enabled if Payment Method is null`

It's expected that Zuora will not allow this [since CustomersDot sets auto_pay: true](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3392#note_635762121) on purchases.

## Expected result

Users with new accounts and no payment methods should be able to purchase a community program


## Proposal

Update parameters (for free Community subscriptions only) to not process payments and to not set account to auto-pay.

1. [ ] Update `auto_pay` to false

```
:account=>{                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             │
            :auto_pay=>false,
```

2. [ ] Update `process_payments` to false

```
:subscribe_options=>{                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             │
            :process_payments=>false,
```

Ensure we have test coverage for "purchase of community programs with no payment methods"

Story points: 3.0
Old orders and customers throwing errors on staging

### Problem

Due to [switch to new Zuora server](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2848) the previous data within the Customers and the Orders table became redundant and due to presence of `zuora_account_id` within the customers table lead to error `Account ID is invalid` while purchasing orders within the staging gitlab.com 

### Proposal

Delete the old customers and their corresponding orders from the database right before the switch happened. 

### Result

It would ask the customers again to register to buy a new subscription.

### How will we measure success?

It should not throw `Account ID is invalid.` error on the buy new subscription page.

Story points: 1.0
Validate Zuora subscription name and ID when creating licenses

### Problem

As mentioned in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3379, we have instances where licenses have been manually created with a typo in the `zuora_subscription_name` field.  For example, it might include a leading or trailing whitespace by mistake.  This is a problem because this field is commonly used as a lookup to find the subscription associated with the licenses (e.g. Seat Link Service) but with the typo, the association is not found.

This was only found in about 13 licenses as of 2021-07-23 in LicenseDot production so it's a small problem but does lead to some noisy Sentry errors.  You can find the list of licenses in [this comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3585#note_634371978).

### Proposal

Add a validation to CustomersDot when licenses are created to verify the `zuora_subscription_name` and `zuora_subscription_id` are valid by querying Zuora.  It's probably not worth adding this same validation to LicenseDot given it's a very small problem and would be more effort to connect to Zuora for validation in that application.

Story points: 2.0
Manually created licenses with typo causing Seat Link failures

### Problem

I noticed when verifying the changes from https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3563 that some errors have been occurring in the SeatLinkCreateService when the license received in the request contains a `zuora_subscription_name` with a typo.  Specifically, in the cases I've seen (see Sentry links below), the `zuora_subscription_name` contains and extra whitespace character at the end of the string which causes `Zuora::Subscription` not to be found when queried.  In both cases, the licenses were created manually in LicenseDot.

Sentry Issues:
- https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/2735681/events/f0637a1b406b436eb2c8568cb3dc16ee/
- https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/2735681/events/484f4cd8ace848558c4bd802b93aee4e/

### Proposal

A simple solution could be to trim the trailing whitespace characters when processing the seat link request.

Story points: 1.0
Proof of Delivery


## Background

This issue describes the smallest and simplest changes we can start iterating on to help our internal teams confirm that the provisioning email was sent.

## Proposal

#### MVC - 14.8
- Capture and set the date and time when the confirmation email with provisioning info was generated and sent.
- Display this information for each active subscription in Customers Admin Portal.
  - Option 1: within the Basic Info tab, add a field "Delivery Confirmation" This new line will display the date and time when the confirmation email containing the license was sent and the email address of who it was sent to
  - Option 2: add a new tab next to Show tab with label "Delivery Confirmation" This new tab will display the date and time when the confirmation email with the license was sent and the email address of who it was sent to
  - Option 3: Leverage Papertrail (version tracking gem) to store the email the license was sent to and the timestamp when it was sent. Use the History tab of a license object to display it - [Proposal](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3370#note_804551801)

:rocket: The decision was to implement option 3 - See https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3370#note_817042324. 

#### Post MVC
- Capture delivery information for each outgoing message that contains a license 
- Display all deliveries related to the license in some delivery history table/dashboard

## Related Problems

- as defined [here](https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/273)
- as described [here](https://gitlab.com/gitlab-com/sales-team/field-operations/deal-desk/-/issues/156)

Story points: 2.0
Use strong_memoize for SeatLinksController#license_data

The following discussion from !3553 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3553#note_630280185): 

    > **Question (non-blocking):** As I look at this code again, I'm wondering if we should use `strong_memoize` here to avoid `license_data` logic being executed twice in event it is `nil`?  No need to block this MR on that point though given it was using the `||=` strategy before.  Let me know your thoughts on it though.  I'll probably go ahead and create a follow-up issue for it.

Story points: 1.0
Community Program - Glue SaaS form

### Problem

Similar to #3331, we need to make sure all parts of SaaS subscription form are well integrated.

### Proposal

- [x] Duplicate `community_ee_subscription_form.vue` to `community_saas_subscription_form.vue`
- [x] Replace SaaS placeholder in `new_community_subscription.vue` with the newly duplicated file `community_saas_subscription_form.vue`
- [x] Duplicate `community_ee_subscription_form_spec.js` to `community_saas_subscription_form_spec.js`
- [x] Update `community_saas_subscription_form.vue` to use `namespace-select` from #3015 (send selected namespace with request payload and make sure "claim" button is disabled if no namespace is selected)
- [x] Make sure `community_saas_subscription_form_spec.js` is covering all changes
- [x] Run full purchase workflow locally to ensure everything is working as expected

Story points: 3.0
Switch impersonate and group icons

### Problem

It seems strange that we annotate the impersonate option with `icon-home` while:

![image](/uploads/f2d8c523b06407c70a77aa8399906a61/image.png)

All other icons describe their function well, but these two often trip me up. Esp. in the search results overview: I usually want to view a user's group, but I often point instinctively towards the `icon-home`.

### Proposal

Switch those icons around. I `grep` through the code just now for those icon names, but didn't find an obvious place to change. Are such design elements pulled in from another repo?

### Result

Less accidental impersonation events

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Verify sentry-rails gem

### Description of the changes

Blocking production deployments until the `sentry-rails gem` update, introduced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3513, is verified in stg.  This MR  removes the deprecated `sentry-raven` gem and replaces it with `sentry-rails` to avoid missing features and security patches.

### Potentially breaking changes checklist

* [x] Follow the regular process to create the MR. Make sure this issue is Public.
* [x] Make sure the maintainer adds the ~"production::blocker" label to this issue once the MR is ready to be merged
* [ ] Once the MR lands in Staging, announce the changes in [#s_fulfillment](https://gitlab.slack.com/archives/CMJ8JR0RH) and request help for testing all the different flows affected
* [ ] Announce the changes in [#support_licensing-subscription](https://gitlab.slack.com/archives/C018C623KBJ)
* [ ] Create a revert MR targeting `master` to quickly deploy to production should anything go wrong
* [ ] Inform the `@sre-oncall` about the potentially breaking changes
* [ ] Remove the ~"production::blocker" label if testing has completed successfully, wait for production deployment
* [ ] If everything looks good after a few hours/days (depending on the change), close the revert MR
* [ ] If there has been a problem, merge the revert MR into `master`, inform Infrastructure/`@sre-oncall` to trigger a `chef` deploy (if urgent) and push the changes to the `staging` branch last

Story points: 0.0
Community subscriptions should be able to renew up to 3 months before expiration date

### Problem

In this issue https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3268 we have limited customers' ability to renew early. They can now only renew starting at 15 days before subscription expiration date.

Community Program subscriptions (with $0 revenue) need to be renewable starting at 3 months before expiration date, because it takes some time to go through the re-approval process.

The renew button (https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3575+) on community programs subscription card (EDU and OSS) and renewal banner (https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3574+) for community programs (EDU and OSS) should be shown 3 months before expiration date.

[Community Program Subscription Renewal Setup instructions](https://gitlab.com/groups/gitlab-org/-/epics/5711#steps-to-setup)

### Proposal

Allow Community Program subscriptions with $0 SKUs to renew 3 months before expiration date.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Community Programs Self-Checkout - Start/End Date

<!-- 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 need to get the Start and End Dates to inform in the Self-Checkout. The current implementation is adding via JS (https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3456#note_624247786)

### Proposal

Implement the necessary ~backend to retrieve Start/End Dates for the Community Program new Subscription and inform it in `app/frontend/packs/pages/subscriptions/community_program/new.js`

### Result

Data is coming from the backend

### Next steps (if any)

### How will we measure success?

Ensuring that this data is coming from the backend, when going to Community Program Self-checkout

Story points: 1.0
Addons purchase info seem redundant and not so clear

<!-- 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

With gitlab-org/customers-gitlab-com#2876:
- `Price` and `Subtotal` lines in the Addons purchase will necessarily display the same values (there are no other products to purchase)
- the Unit Price of the product is not so evident and placed in a line that's not even so clear

| |||
|-|-|-|
| Simple | ![Screenshot_2021-07-13_at_09.04.43](/uploads/372c4527876ba894d9feb3799047e565/Screenshot_2021-07-13_at_09.04.43.png)| This should be fixed with gitlab-org/customers-gitlab-com#2876. Also, the line for quantity is a bit weird.
| with Proration credit | ![Screenshot_2021-07-15_at_07.08.26](/uploads/d5ce956a4661d281c25964f5d0a7a9fb/Screenshot_2021-07-15_at_07.08.26.png) | The info here are correctly displayed and the difference between `Price` and `Subtotal` clearly makes sense

### Proposal

To solve this, I'm proposing to make the line for the quantity a bit more readable.

| | | |
|-|-|-|
| Price per Unit (clearer quantity)|![Screenshot_2021-07-13_at_09.11.03](/uploads/9359bcc242573db548b6e275240dd792/Screenshot_2021-07-13_at_09.11.03.png)| If we want to keep the Price as a total, we can at least improve the line for the quantity a bit. |

Story points: 1.0
Previous user count is incorrect when changing products and seat count during renewal

### Problem

When a subscription is renewed, and the user changes the product and the number of active users at the same time, the `previous_user_count` is the same as the new `user_count`.

This is because `Subscription#previous` finds the last version of the subscription and we use the result of this to get the `previous_user_count`. This is an issue when changing products and seats, because we generate an amendment of the subscription with the new product and the new seat count before processing the renewal amendment. This means the previous version at that point is the version with the new product and the new user count.

##### Example

![Screen_Shot_2021-07-13_at_3.10.22_PM](/uploads/d701cb402d3ee4a38b3353e051b77556/Screen_Shot_2021-07-13_at_3.10.22_PM.png)

^ In this example, we renew the initial subscription (V1) and change the product from premium to ultimate. We also change the user count (which was 10 in V1 and is then 15 in V3). When we process the renewal, we look for the most recent previous version and this is returning V3 currently. This means we're creating the license with `user_count: 15, previous_user_count: 15` but it should be `user_count: 15, previous_user_count: 10`

#### 🐛 Steps to reproduce

1. Create a new self-managed license via CustomersDot
1. Navigate to the renewal page for that license
1. Renew the license with:
   1. Changed product (ie Premium -> Ultimate)
   1. Changed number of users
1. View the license in the db: `previous_users_count == user_count`

#### 📸 Screenshots

![Example](/uploads/9e44db1ba9601d91dc6464efa7ccce22/count_present.mp4)


### Proposal

I'm not entirely sure how to address this, it will likely require some investigation. We need to get the version of the subscription before we made the renewal amendments, or we need to store the `previous_user_count` somewhere else and look it up from there.

### Reported Examples

1. https://gitlab.com/gitlab-com/support/internal-requests/-/issues/11348
1.

Story points: 3.0
Allow users to manually renew subscription up to 45 days post expiration (change from 30 days)

## Summary

The following issue https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1393 introduced the limitation of showing 'Renew' button up to 30 days after subscription expiration, but hiding it after 30 days.

Per comment here https://gitlab.com/gitlab-com/sales-team/field-operations/deal-desk/-/issues/102#note_622857803 from @jrabbits [The foundational policy](https://about.gitlab.com/handbook/sales/field-operations/order-processing/#late-renewals) now states that renewals can be closed up to 45 days after the renewal date. This requires a modification of the logic from 30 days to 45 days.

## Proposal

Make an update to logic introduced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/1393 to use 45 days instead of 30 days.

Story points: 2.0
Make use of SubscriptionCurrentVersionFinder redundant

Continuing the discussion from the MR https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3484 here, we are introducing a new class `SubscriptionVersionFinder` to find subscriptions which were active/present in a given period of time. 

The `SubscriptionCurrentVersionFinder` makes the use of `SubscriptionVersionFinder` and finds the subscriptions which were active on `Date.current`. 

We can simply make a call to `SubscriptionVersionFinder` and use the method current_version which will make use of `Date.current` without having to use the whole calls being inherited from `SubscriptionVersionFinder`.

Update: In addition to the above, we will also update the logic where `SubscriptionCurrentVersionFinder` is used to use the new POC logic introduced in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4246+ instead.

### How will we measure success?

We should not need to update VCR after the change has been made as the query to Zuora still has to be the same.

Story points: 2.0
Community Program - Glue self-managed form

### Problem

We have all the parts of the self-managed form in the main component, but they're not integrated together.

### Proposal

Glue all parts to send confirmed request to backend and handle error/success.

### Details

- [x] When the purchase succeed, we'll show success modal with "View your subscription" button.
- [x] If there's a coupon code error, we'll show it below coupon code input field.
- [x] If there are other errors, we'll show it on top of the form.

### To do

- [x] Once !3456 is merged, send seats count alongside the request

Story points: 3.0
Update wrapper to find GlTooltip using data-testId

The following discussion from !3467 should be addressed:

- [ ] @aalakkad started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3467#note_616282898):  (+6 comments)

    > **suggestion (non-blocking):** I think it's better if we added data-testid to the tooltips, since we're having 2 of them instead of one.
    > 
    > Then we can choose which tooltip are we targeting in the tests rather than finding a tooltip and hope it's the correct one.
    > 
    > I'm marking this as non-blocking to be done in a follow-up, but will defer to the maintainer to decide if it's ok.

cc: @rhardarson

Story points: 1.0
Rename occurrences of `user` to `customer` in purchase flow

When talking about out application, we rarely use the term `user` but prefer `customer`. To keep our application vocabulary consistent with the usage, let's replace the references to `user` with `customer`, at least for the purchase experience. This will help us keeping a shared language between all team members.


The following discussion from !3490 should be addressed:

- [ ] @agulina started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3490#note_617304689):  (+1 comment)

    > **question**: I struggle a bit here because CDot is sometimes inconsistent with names.
    > 
    > Should it be `customer` or `user`?

Story points: 2.0
IronBank Gem version(4.4.1, used by current CustomersDot ) does not connect to Zuora Central Sandbox

IronBank Gem version(4.4.1, used by current CustomersDot ) does not connect to Zuora Central Sandbox.


### Problem

Since CustomersDot rely on IronBank to connect to Zuora, this prevent CustomersDot from working with Zuora central sandbox. This blocks issue https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2848

Details in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2848#note_616941950

### Proposal

Two options so far:
1. Bump iron_bank gem version to [v5.2.3](https://github.com/zendesk/iron_bank/releases/tag/v5.2.3), which contains the [fix exactly for this issue](https://github.com/zendesk/iron_bank/pull/74).
2. Monkey patch the fix in CustomersDot, on top of existing iron_bank gem 4.4.1

In local environment, with monkey patch, I have verified IronBank can query from Central Sandbox(`rest.test.zuora.com`) successfully.

Option 1 is preferred. Asked in slack to see whether people have concern to bump iron_bank gem version https://gitlab.slack.com/archives/CMJ8JR0RH/p1625186996057700

Thanks @jameslopez to suggest a nice checklist in MR https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3504 - we should follow the checklist.
* [x] Follow the regular process to create the MR. Make sure this issue is Public.
* [x] Make sure the maintainer adds the ~"production::blocker" label to this issue once the MR is ready to be merged
* [x] Once the MR lands in Staging, announce the changes in `#s_fulfillment` and request help for testing all the different flows affected
* [x] Announce the changes in `#support_licensing-subscription`
* [x] Create a revert MR targeting `master` to quickly deploy to production should anything go wrong
* [ ] Inform the `@sre-oncall` about the potentially breaking changes
* [x] Remove the ~"production::blocker" label if tested has completed succesfully, wait for production deployment
* [x] If everything looks good after a few hours/days (depending on the change), close the revert MR
* [ ] If there has been a problem, merge the revert MR into `master`, inform Infrastructure/`@sre-oncall` to trigger a `chef` deploy (if urgent) and push the changes to the `staging` branch last


### How will we measure success?

CustomersDot can connect to `rest.test.zuora.com`

Story points: 2.0
Follow-up from "Use current_subscription when checking for last_quarter reconciliation"

The following discussion from !3468 should be addressed:

- [ ] @tyleramos started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3468#note_614688188): 

    > **Suggestion for follow-up:** I'm seeing we have similar logic of `order.current_subscription || order.subscription` in at least 3 other places now.  What do you think about defining as a method on `Order` and using that method in those references to DRY it up a bit?

Story points: 1.0