Please bring back the functionality of the "renewal date"

[craigh]

Sergey,

By focusing on Dave's characterising this as an issue only "for people hosting a small number of 'personal/private' websites", you're missing the point completely.

Consider these facts:

• You have taken one existing function that has been in and behaved the same way in Plesk for years and completely changed how it works. What you have done should have been introduced as a completely separate function. That said, I actually don't see the point of the change that Parallels has made here, so I don't see the need for such a new and/or separate function. If all hosting under a "service plan" is going to expire some defined period after the creation of the initial subscription (the creation being an event that only happens once, not on a recurring basis), what point does it serve now if we set it to anything except "unlimited"? What is the point of syncing a subscription, if doing so sets the renewal date back five years? If there is actually some logic or benefit of this to us, could you please explain the point of this new function to us?
  
• We've been in the hosting business for 17 years -- and using Plesk for 8 of those years -- and we're not hosting a "small number" of clients. With the exception of some sponsored hosting for non-profits, all of our hosting is paid for by clients, and it's paid for in defined periods, periods defined by an expiry date of their hosting plan, not a date in the "service plan" that defined their initial set-up. The defined period changes, of course, with each billing cycle, and should not be linked to the "service plan" template that created the initial hosting environment.
  
• We use an in-house billing system that tracks (or used to track) the expiry/renewal date in Plesk. Hosting is (or used to be) suspended automatically by Plesk on the expiry date if hosting has not been paid for. This is the whole point of an expiry date, and being forced to make the hosting term unlimited creates more manual work by requiring a human to suspend an account rather than letting the control panel do it automatically.
  
• On the "permissions" tab of the "service plan" function it reads:
  
  

  "Some of the privileges let a subscribed customer modify settings of the provided services (that is, properties of Hosting, Mail and so on). To preserve the modifications made by customers, the Panel does not sync a plan property if a related permission is granted. In such a case, the property acts as a preset: it is applied only once -- when a subscription is created -- and then it is not synced any more."

  
  If there is some valid reason that many Parallels customers are not aware of for the logic of the new action of this old function, why not leave it in place and then just (as described above) make it a "preset" and apply it only once when a new subscription is created, and then not sync it any more? That would seem to me to be the most logical action here. The initial setting is certainly useful for us in our business, because we expect to have been paid by the new client by the time the initial period we set has passed. If we haven't been paid, the hosting is suspended. If it has been paid, we update the expiry date and continue to do so after each invoice is paid.

Here's an example of a not-so-small hosting company (Media Temple) -- that hosts more than just a few websites for friends -- who still have the following instructions in their knowledge base "To renew an expired subscription":

1. Select subscription.
2. Activate.
3. Customise.
4. Set new expiry date.
5. Update & Lock.
6. Unlock & Sync.

While this is convoluted and requires a lot of unnecessary clicking (when compared to earlier versions where you simply updated the expiry/renewal date), I'd rather go back to this than live with the current situation.

Parallels, please do one of the following in the next micro-update:

• Restore the former functionality of the "renewal date" , or
• Make it a "preset" that is applied only on the creation of a subscription and not synced at any point after the initial creation of the subscription.

Anything else just doesn't make any sense.

Thank-you for considering your customers' point of view.


Craig

 

[DaveKay]

100% AGREE!!!

This is such important functionality that is missing!

 

[Sergey L]

Hi, the problem is recognized. However it might be a bigger change than the ones which go in microupdates.

We had a reason to make this change - many people needed to switch from "1 year" expiration period to Unlimited and were unable to do so through Service Plans. Unfortunately the change broke "renew" scenario. If we just revert it back - we will break life of those customers again. Instead we need to develop proper solution - considering both scenarios.

 

[craigh]

Hi, the problem is recognized. However it might be a bigger change than the ones which go in microupdates.

Thank-you. I'm glad that you now recognise the problem.

We had a reason to make this change - many people needed to switch from "1 year" expiration period to Unlimited and were unable to do so through Service Plans. Unfortunately the change broke "renew" scenario. If we just revert it back - we will break life of those customers again. Instead we need to develop proper solution - considering both scenarios.

I still don't get how the new functionality is useful, especially as the ability to make hosting unlimited was always there too, but I recognise that I don't know everything and perhaps this change was useful to other hosting providers. But it's a good example of why you shouldn't take an existing function and change the way it works. If you want to introduce new functionality, introduce a new function. I just hope we don't have to wait until version 27 before it's fixed.

That said, this is a newly-broken function. Therefore I think there would be far more people who would be made happier by reverting than there would be people who are made unhappy. The unhappy people would have a good reason to be unhappy -- poorly thought out implementation of new functionality -- but in my mind you'd just be fixing something that broke and shouldn't have been broken in the first place. Are you even sure that anyone is actually using this broken function, especially as there seem to be a number of us who don't even understand how it can possibly be of any use?