Provide all sub types and how they relate

[beck]

Problem

When trying to determine the possible options for an available subscription, if I already have a subscription of a certain type, is a related type a downgrade or an upgrade?

Example:
I have wl_ecommerce_professional and the partner also provides wl_ecommerce_basic, wl_ecommerce_professional, and wl_advertising_starter. I would expect to see:

subscription	available actions
wl_ecommerce_basic	downgrade
wl_ecommerce_professional [active]	cancel
wl_ecommerce_professional	upgrade
wl_advertising_starter	add

How does one determine downgrade/upgrade, vs add? Are there other actions?

At minimum what is needed is documentation of all subscription types, grouped and prioritized.

ping @RayeN

[RayeN]

If you need upgrade/downgrade relations between subs - you can get them from appropriate products from COS. Just for example product with subscription type == wl_ecommerce_professional has the following meta:

downgrades: ["wl_ecommerce_basic", "wl_ecommerce_demo"]
upgrades: ["wl_ecommerce_unlimited"]

[RayeN]

So, if there is no active ecommerce add-on - then the action is add
if there is one and new subscription type is in current product's upgrades list - action == upgrade otherwise downgrade. if new type == old type, nothing is done.

[beck]

if there is no active ecommerce add-on

How does one determine if there is an active ecom add-on?

[RayeN]

You can get current user's subs and check if there is one with type in [list of ecommerce add-on types].

[beck]

list of ecommerce add-on types

This is the info that I am missing. How does one build that list?

[RayeN]

I don't think we have it somewhere, except for COS DB. They are:
wl_ecommerce_demo
wl_ecommerce_basic
wl_ecommerce_professional
wl_ecommerce_unlimited

[beck]

Reviewing the bottomline implementation:

Right now:
I'm querying for the partner's available subtypes and displaying a list that the user can select from.

Problem:
It is not possible to programmatically group these available subtypes.

Do we care about this?

If no - I'll stop using the client to get the partner's available subtypes and hardcode this grouping:

• Hosting
  • wl_ultra_lite
  • wl_lite
  • wl_premium
  • wl_basic
• Ecommerce
  • wl_ecommerce_demo
  • wl_ecommerce_basic
  • wl_ecommerce_professional
  • wl_ecommerce_unlimited
• Advertising
  • wl_advertising_starter
  • wl_advertising_growth
  • wl_advertising_pro

If yes - then we need a way to build ☝️ using data sourced from yolapy.

[RayeN]

We can probably make a hack in yolapy to group partner's available subscription types as you mentioned - if name contains ecommerce put it to Ecommerce group, the same for advertising. Everything else should go to hosting :) I know that's a dirty hack - but if we need that grouping we can do that instead of hard-coding.

Either with our without grouping - we should take into account partner's available_subscription_types or I didn't understand you?

[beck]

or I didn't understand you?

I believe you understood :)

we should take into account partner's available_subscription_types

It would be most convenient (arguably necessary?) if available_subscription_types were returned grouped

We can probably make a hack in yolapy

@blaix might have some opinion on this.

We don't want to use yolapy to mask deficiencies of the platform

[RayeN]

I think we could add a new endpoint to COS and expose it via wlproxy to return all possible WL subscription types grouped. And yolapy could use it along with partner's available_subscription_types to build grouped available subscription types list.

[beck]

Sounds good to me.

[blaix]

me too

[blaix]

DIscussed in meeting with @thomasw and @RayeN and we decided for now to hard-code this, since it is what partners are doing now anyway.

[blaix]

@beck go ahead and consider hardcoding these relationships as part of the requirement for closing out https://github.com/yola/bottomline/issues/13