Add support for perpetual licenses

[lilith]

ImageResizer subscriptions that are cancelled after 3 years should become Perpetual use licenses for builds released before the cancel date.

ImageResizer subscriptions purchased with the perpetual add-on, or tagged perpetual should also.

[VikiAnn]

@lilith could we chat sometime this week to go over how this should work?

[lilith]

Perpetual add-ons have JSON meta data like

{
    "perpetual": true,
    "features": [
        "R_Elite",
        "R_Creative",
        "R_Performance"
    ],
    "allowed_ids": ["enterprise-wide-elite-edition-yearly"]
}

or

{
    "perpetual": true,
    "features": ["R_Performance"],
    "allowed_ids": ["enterprise-wide-performance-edition-yearly"]
}

[lilith]

For subscriptions that are in a canceled state, we need to set two fields:

SubscriptionExpirationDate: iso8601 date Message: Your subscription has expired; please renew to access newer product releases.

[lilith]

You can see the licenses we test the client against here: https://github.com/imazen/resizer/blob/8d258da2b7d700a3320e7e8397e2002956cc5a76/Tests/ImageResizer.Plugins.LicenseVerifier.Tests/LicenseStrings.cs

[lilith]

Calculating the start date for the 3-year period is difficult, as activated_at is reset whenever the subscription is changed

[VikiAnn]

Gah, I meant to reply, not edit your comment! So for subscriptions with a perpetual add-on, do we just need to remove/not set the expires date? Is there anything else we need to do to make them behave like a perpetual license?

For subscriptions that are in a canceled state, we set two fields:

SubscriptionExpirationDate: iso8601 date Message: Your subscription has expired; please renew to access newer product releases.

I'm a little confused, is that something that's happening already or is that something I need to add?

Calculating the start date for the 3-year period is difficult, as activated_at is reset whenever the subscription is changed

Could we use the created_at from the ChargeBee subscription?

[lilith]

Created_at would be okay to use as a stopgap solution. We need to add both fields and remove the expires date.

[VikiAnn]

Do regular licenses with a perpetual add-on get SubscriptionExpirationDate and the same Message too?

[VikiAnn]

Oh, looks like we have a issued date on licenses, which is derived from the subscription created_at for ID licenses and from the subscription started_at for regular licenses. Is one of those preferable?

[lilith]

Created_at is preferable for determining the 3 years I think.

On Wed, Aug 21, 2019, 11:35 AM Viki Harrod notifications@github.com wrote:

Oh, looks like we have a issued date on licenses, which is derived from the subscription created_at for ID licenses and from the subscription started_at for regular licenses. Is one of those preferable?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/imazen/licensing/issues/9?email_source=notifications&email_token=AAA2LH47GLORIJVSRTZUOATQFV4H7A5CNFSM4HZLXO22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD42QMSQ#issuecomment-523568714, or mute the thread https://github.com/notifications/unsubscribe-auth/AAA2LHYZBGDMLHNQDQCJWTTQFV4H7ANCNFSM4HZLXO2Q .

[lilith]

Yes, perpetual licenses of both kinds get the subscriptionexpirationdate and message.

On Wed, Aug 21, 2019, 11:31 AM Viki Harrod notifications@github.com wrote:

Do regular licenses with a perpetual add-on get SubscriptionExpirationDate and the same Message too?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/imazen/licensing/issues/9?email_source=notifications&email_token=AAA2LH5UPDG7CWCF2XJHQPLQFV3X7A5CNFSM4HZLXO22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD42P5UY#issuecomment-523566803, or mute the thread https://github.com/notifications/unsubscribe-auth/AAA2LH5MV4X2BQLRKXY4BJTQFV3X7ANCNFSM4HZLXO2Q .

[VikiAnn]

OK, so to recap/make sure I'm doing the right stuff:

Cancelled subscriptions after 3 years are subscriptions with:

• status of "cancelled", and
• created_at 3 years or more in the past

Perpetual licenses are subscriptions with:

• Any add-on that has perpetual: true in its meta data

Both kinds should get the subscription_expiration_date and message fields set on their licenses, and the expires date should be removed.

For cancelled subscriptions after 3 years: subscription_expiration_date => subscription cancelled_at date (iso8601) expires => nil message => "Your subscription has expired; please renew to access newer product releases."

For perpetual licenses: subscription_expiration_date => subscription started_at date? (iso8601) expires => nil message => "Your subscription has expired; please renew to access newer product releases."

Do you want a different message for the perpetual add-on licenses? Seems like telling someone who bought a perpetual add-on that their license is expired might be confusing, maybe something like "This license includes the perpetual add-on, and is valid for product releases through [started_at date]"?

Do we care which webhook event it was that hit the endpoint?

[lilith]

Subscriptionexpirationdate and message should only be set if the subscription is canceled. The assumption is that perpetual licenses are usually canceled by the end of the first year, but we wait until then to display the message.

[lilith]

We don't care which event triggers the update as long as the update happens on time.

[lilith]

I agree the message should also reflect that it is valid for releases prior to [date]

[VikiAnn]

Ohhh ok. So perpetual licenses would be more like:

1. Subscription with perpetual add-on purchased
2. Subscription created webhook hits our endpoint
3. We generate the license as usual, except that the expires is lifted
4. Usual behavior for any other endpoints until cancellation
5. Subscription cancellation webhook (or whatever webhook with that subscription) hits our endpoint
6. We update the license with the subscription_expiration_date and message fields