GLVSC-593: Check expiration of paid accounts offline

[sergiolms]

Description

Paid licenses can expire while offline, so with this PR we introduce some checks and a new Paid expired state to users that own an expired license, so we can customize messages and promotions for them if we want to.

Adding @justinrobots as CC to this PR because I'd like him to review the messages I set in case we want to change them or if I made a typo. 😄

Here's a screenshot of how it would look like for users that have a pro/enterprise account that has expired:

Checklist

• I have followed the guidelines in the Contributing document
• My changes follow the coding style of this project
• My changes build without any errors or warnings
• My changes have been formatted and linted
• My changes include any required corresponding changes to the documentation (including CHANGELOG.md and README.md)
• My changes have been rebased and squashed to the minimal number (typically 1) of relevant commits
• My changes have a descriptive commit message with a short title, including a Fixes $XXX - or Closes #XXX - prefix to auto-close the issue that your PR addresses

[axosoft-ramint]

Some initial things I noticed. Will test e2e next week (will take a bit to set up/mimic an account with a paid expired license).

[axosoft-ramint]

Looks good. I can only really simulate having an expired license in testing, but it showed the right messaging for me on Pro features and account view. Only suggestion would be to apply this state to our default pro50 promo as well.

[axosoft-ramint]

Heads-up: Just noticed after talking with @eamodio that we're currently filtering out expired paid licenses during the check-in computations: https://github.com/gitkraken/vscode-gitlens/blob/main/src/plus/gk/checkin.ts#L69-L71

This might mean that those paid licenses with expired date never make it into someone's license data, which means they would never enter the new state being set up here.

We might need to update those computations:

1. If the best license available is an expired paid license, we should probably let it through so that we can recognize this "expired paid" state rather than defaulting to "free", which may offer options like "start trial" that the user isn't eligible for yet.
2. But we should be careful not to have the paid, expired license data replace the trial data, in case someone does reactivate trial with an expired license: https://github.com/gitkraken/vscode-gitlens/blob/main/src/plus/gk/checkin.ts#L179-L181

[sergiolms]

Heads-up: Just noticed after talking with @eamodio that we're currently filtering out expired paid licenses during the check-in computations: https://github.com/gitkraken/vscode-gitlens/blob/main/src/plus/gk/checkin.ts#L69-L71

This might mean that those paid licenses with expired date never make it into someone's license data, which means they would never enter the new state being set up here.

That's right, they get filtered out when you log in. My changes only apply if you were already logged in and while offline your account expires.

We might need to update those computations:

1. If the best license available is an expired paid license, we should probably let it through so that we can recognize this "expired paid" state rather than defaulting to "free", which may offer options like "start trial" that the user isn't eligible for yet.
2. But we should be careful not to have the paid, expired license data replace the trial data, in case someone does reactivate trial with an expired license: https://github.com/gitkraken/vscode-gitlens/blob/main/src/plus/gk/checkin.ts#L179-L181

Gotcha, so instead of filtering out now we will take it into account and only replace the effective license if the actual license isn't a paid expired.

Good catch

[axosoft-ramint]

One other issue I am seeing with computeSubscriptionState that could happen if we let expired subscriptions through:

1. You have a paid, but expired, Pro license.
2. You are on a (reactivated) Pro trial.

Note that this conditional is not triggered so effective = { ...actual } does not happen, but...

effective is still set in 171 to a trial license with effective.id === SubscriptionPlanId.Pro. And actual is an expired license with actual.id === SubscriptionPlanId.Pro.

So when we hit computeSubscriptionState, it will match the actual.id === effective.idcheck (which previously wouldn't happen unless we hit thiseffective = { ...actual }` line, and that would only happen if it was an active paid license since we were filtering out paid licenses that were expired.

Ultimately, this would cause your license to show as a paid Pro license rather than an active Pro trial.

To avoid that regression, I suggest we just attach an isTrial property to these and we can add that to the condition in computeSubscriptionState.

[sergiolms]

Updated with all feedback except this one

[axosoft-ramint]

This is probably fine, but I'm not 100% sure if we can rely on latestStatus coming through as 'trial' for trial licenses the way we are hoping for it to here. Since effective licenses from the api check-in response were always intended to be for trials, and paid licenses were always intended to be non-trial, we could probably just get away with using true in effective licenses and false for paid ones when setting them up from the check-in response.

[sergiolms]

hmmm, okay, I just uploaded a commit with this

[axosoft-ramint]

Going to give this one more review/test pass today and we can merge if it looks good.

[axosoft-ramint]

When I am in the "expired paid" state, the account view is confusing:

There is no indication here that my license is expired. Furthermore, it provides links to sign in/sign up, when it should be asking me to renew my license.

Any chance you can take a pass at the content here for this state?

[d13]

Let's pause on this PR until after the 16.0 release, so we can spend more time and focus on the priority 16.0 items. Going to bump this back to draft in the meantime.