How to configure upgrade/downgrade options for packages


In this guide, we will examine how to configure packages into a group that can be upgradeable/downgradeable between each other.


Package’s Extensions and Service Limits

First of all,from a function perspective ,especially in hosting package cases, in order for a package to seamlessly be changed by another package through upgrade/downgrade option and the customer to retain functionality, it should be noted that interchangable packages could share same services and/or have the ability to utilize the same package extensions (eg.Extra MsSQL,etc.).


The reason for that is maintaining functionality, so in case you downgrade for example from one webhosting package to another “poorer” version of that, functionality of the customer should be maintained and as such the lost services (eg.difference in Email accounts) could be balanced with adding said extension before doing the downgrade,so customer doesn’t lose functionality over certain aspects of his services.


This is not the case, though for DNS package where website services aren’t the case. So, it’s more something to keep in mind when configuring said packages and what you want from them from a business perspective.


Guides on service limits inside a package,configuring packages and package extensions can be found in the links below.



Note! Additionally , note you can downgrade/upgrade to products with same renewal period if one exists.

Setting up the upgrade/downgrade group

After, everything is set as it should based on our needs and the above, we can move onto the actual configuration of the upgrade options.


This is done through MsSQL (or more recently PostgreSQL) with Atomia’s Database.More specifically, we need to make changes to the tables upgrade_group and upgrade_group_member , both of which can be found inside AtomiaBilling Database.


Upgrade_group

Our first stop will be here, where we can either make a new group for the packages we want to share the same upgrade/downgrade options or use one of the existing ones.


In the case of using one of the existing, we don’t need to do more here, since we have a group configured already. In the case, where we want to setup a new group we will create a new entry for that table assigning it a Unique Identifier and giving it a desired name.


For example:

Log in Atomia’s database, open the ‘New Query’ option,type and execute one command at a time (basic SQL Commands depending on your knowledge level):


begin transaction;


insert into [AtomiaBilling].[dbo].[upgrade_group] (id, name) values (NEWID(), 'TestUpgrade');


--where ‘TestUpgrade’ can be anything we want our group to be named


SELECT [id], [name]

 FROM [AtomiaBilling].[dbo].[upgrade_group];

 

--to inspect the result

 

commit;

-- to apply the aforementioned change


(  rollback; -- to revert the changes)


Upgrade_group_member

Here, we will configure the list of packages that can be upgraded from and to another package.

The values of this table:

  • Id : uniqueidetifier for this entry

  • Fk_group_id : foreign key referencing the group in which the packages will be able to upgrade/downgrade from

  • Fk_item_id : foreign key referencing the products that will be taking part in this group.It takes it’s values from the table [items] where that value is used as id(see,uniqueidentifier).

  • Upgrade_level : This value shows, logically, on what step of the “ladder” is a product in that group.Meaning, a product with a higher number has more services (or higher service limits) than one with smaller.Numbers are of the integer type and are increased by 1 step (eg.1,2,3). Certain values can be shared between 2 products in the case , we want them to be somewhat equivalent and not be configured to switch between one another.

  • upgradeable/downgradeable: These values  are of boolean type (0,1) and show whether a package can be upgraded/downgraded or not respectively.

  • Upgradeable_from/downgradeable_from : These values are, again, of boolean type and dictate whether a product has the ability to be switched with something else inside that group.(eg. We may want to be able to upgrade from one package to another but not the reverse.In the case, we would set the 1st of them with upgradeable_from=’1’,downgradeable_from=’0’).



By using inserts as above with cast as Uniqueidentifier for the foreign keys inserting with proper referencing to tables :

  • upgrade_group for fk_group_id , in order for products to be part of an upgrade group

  • item for fk_item_id for defining the product taking part in this group


For example a query for a product that has the ability to get downgraded and upgraded to upgrade_level 2 items or upgrade_level 4 respectively would look like this:


--to insert the item into the group
begin transaction;
  insert into [AtomiaBilling].[dbo].[upgrade_group_member] (id, fk_group_id, fk_item_id, upgrade_level, upgradeable, downgradeable, upgradeable_from, downgradeable_from)
  values (NEWID(), 'AD745339-9651-40B5-8F14-E9ED25318358', '8E8E00EC-A78F-4635-8787-2EBF9DE62106', 3, 1, 1, 1, 1);

--to inspect the result
SELECT *
 FROM [AtomiaBilling].[dbo].[upgrade_group_member]
 where fk_group_id='AD745339-9651-40B5-8F14-E9ED25318358'
 order by upgrade_level asc;

--to apply changes
commit;


We have managed,so far, to create a scenario where certain products can be upgraded/downgraded to others and vice versa ( or part of those options depending on our needs ).


After, we have configured the upgrade group to our liking based on the changes made on tables upgrade_group and upgrade_group_member, all that is left is to run iisrseset, which will refresh the cache and apply the changes.


Functionality/Use of feature


In order  to test the functionality of the feature, all we need is, go to Billing Customer Panel for a customer that has one of the included products and under “Subscriptions” tab, we will find the available options for downgrade and upgrade for that package.


As a final note, in case of downgrade and depending on the customer’s already used services, there is the case when we will be notified that the desired action moves from one package to another that doesn’t support the number of resources already in use by that customer.


In that case, we can either add the respective amount of Addons to cover the limitations of moving to the new package and afterwards ,proceed with the downgrade.


Or, if maintaining all resources the customer has already in use isn’t the case, then simply pick which services should be terminated and proceed to do so,in order for services to be able to fit in the new package’s limits.


In case ,that the new limits aren’t in correspondence with what is used by the customer at the moment, we’ll be notified to further alter them, until they reach the desired amount.