Squidix Web Hosting

We should be able to do this when a service is created. We can't invoice with the wrong price, and if we don't invoice, we have to change the due date to generate a new invoice with the correct price. Pricing is an integral part of service creation and provisioning, the ability to change it after the fact doesn't cut it. We have a patch for this which we will post shortly.

From a business standpoint, this is a very strange way to do things. I don't think any of the other hosting billing systems I've worked with do this, and definitely not as default behavior. Packages and package pricing change all the time - but the vast majority of companies will leave customers on the old pricing when this is done. At the very least, there needs to be an option to override this somehow. It could consist of a setting to automatically establish a price override when a service is ordered (using pricing from the package), and ideally a way to traverse old services and lock their pricing down with an override before changing a package pricing.

Patched: Replace if ($vars['use_module'] == "true") block in editService method on cpanel module. // Only update the service if 'use_module' is true if ($vars['use_module'] == "true") { // Update password (if present) if (isset($vars['cpanel_password'])) { $this->log($row->meta->host_name . "|passwd", "***", "input", true); $result = $this->parseResponse($api->passwd($service_fields->cpanel_username, $vars['cpanel_password'])); } // Update username and domain $params = array('newuser' => $vars['cpanel_username'], 'domain' => $vars['cpanel_domain']); $this->log($row->meta->host_name . "|modifyacct", serialize($params), "input", true); $result = $this->parseResponse($api->modifyacct($service_fields->cpanel_username, $params)); }

$fields->setHtml(" <script src=\"SCRIPTPATH\"></script> <script type=\"text/javascript\"> $(document).ready(function() { $(\"#cpanel_password\").after(\" <button id=\\\"cpanel_unmask\\\" onclick=\\\"return(false);\\\">Toggle Visibility</button>\"); $(\"#cpanel_password\").passwordMask($(\"#cpanel_unmask\")); }); </script> "); In components/modules/cpanel/cpanels.php in the getAdminEditFields function, starting on 5th line. SCRIPTPATH points to a copy of this - aduth.github.io/jquery.passwordMask/js/jquery.passwordMask.min.js

How about just hide the box and have a button to show it, or mask by default with a button to unmask it? Honestly - even if I had a generator, modal, etc - I would still want to be able to see the old password in some cases. An option to show the field plus a generator gives me that and removes the extra work of doing a modal which I'm sure would be the most time consuming part of this.

That's what I've been doing. Basically I'd like to be able to pull up the service, hit the "save" button once and close it out not having to wonder if everything if in sync. 2 seconds vs 1 minute. Note - this should apply to packages as well (that's probably even more important than service fields). Perfect example, just did a migration, if I was using Blesta I would have had to go change the package manually or I would have to go through multiple steps to make sure the account was on the proper package.

I think a very basic generator (no modal) that puts it into the field as plain text would be no worse, honestly. Nobody's going to be using this from a public library with people looking over their shoulder, it's not a public sign in page, masking the password really isn't necessary IMO. WHMCS doesn't even have a generator for this like it does for client passwords - it just shows plain text. Doesn't hurt that it's an easy change.

We've written a patch to allow price override on creation.

I would like a generate password myself - that's what led me to this. Showing it is a decent alternative.

I'm talking about the welcome email. It should be a template, so it can be re-used. And somehow, despite all of that, WHMCS still dominates the market. Because they do plenty of things right. This is one of them. I can update an email template associated with 10 packages in WHMCS in one go. I can't do that in Blesta. I have to update every package individually (which breaks package ordering thanks to the package ordering bug - although that may be fixed in 3.5). We make changes to our emails regularly for technical and marketing reasons. If you want to use a per-package email, fine, but you should have the option to reuse a template if you want to. I'm not seeing the problem here. "Don't repeat yourself" is a universal principle, and it's not exactly controversial.

I just gave you 3 valid reasons. I can assure you I have a brain, have been doing this for a few years and have thousands of customers, so I know as well as anyone what a hosting company might need to do. My WHT coupons are mostly indefinite, because not every promotion is set to end at a specific time (one that will be known upon creation). I'm not the only one, either. Not quite understanding your objection here. It's not like you'd have to use it. It adds more flexibility to the system, with no downsides.

Looks like this has been discussed but this was in 2014 - http://dev.blesta.com/browse/CORE-1358 Once this is done, linking them up would be simple, presumably.

I'm saying that sometimes the data will be out of sync, so data should be propagated to the module regardless of whether or not it matches the current local data. The only downside is a slight performance hit... but this is an explicit manual action and can be easily avoided by unchecking "use module" anyway.

We're working on this now, PM if interested.

You're kidding, right? The whole point of a billing system is to make things that used to be hard work easier. You could apply this argument to a discussion over whether Blesta should automatically send invoices, or allow customers to place orders on the web, or whether it should do, well, anything. Telling me "don't offer 10 packages" is not any type of solution. That's crazy. I can in WHMCS.

That's for your uses - we're not talking about food here. As indicated by the fact that Blesta's largest competitors all have this, people do need and use it. What about source specific coupons that should continue indefinitely? What about the future potential for coupon based affiliate tracking? What about permanent promotions simply used for technical reasons, such as discounting the 1st billing cycle? These are not quirky edge cases. There are many uses for indefinite coupons.

There are situations in which Blesta's data may not change, but you still want to send that data to the module to make an update. Right now, data is only sent to the module when it's different from the old Blesta data. However, in the case of a migration for instance, the data in Blesta (cPanel package, password) will not and should not be expected to match the data in the module. Only downside to this is a slight performance penalty when "use module" is checked. If the user checks "use module" it is not unreasonable to expect that changes will be sent to the module and a penalty will be incurred. The more foundational issue here is that Blesta should not always make the assumption that its data is always correct (meaning in sync with any external systems used by a module), which it seems to have a tendency to do in this situation as well as others. Billing and order processing can and does get messy. The current approach assumes ideal circumstances and makes anything else very difficult.

We have numerous indefinite coupons. 1. They might not have a time period 2. We might want to manually control the time period, since we don't know when they'll end. WHMCS and ClientExec both have this.

That's not really a solution...

I don't want to edit 10 packages every time there's a tiny change to the welcome email.

Who says a coupon has to stop working? 75% of ours are indefinite.

Self explanatory.

Okay, and we have ~10 cpanel packages - all need to use the same welcome email.

What? I'm talking about package welcome emails that are entered on each package.

The fact that the password is masked here gets very annoying, especially when combined with the fact that Blesta will only call the module for a password change if the password doesn't match the old one in Blesta (something else that should probably be changed). No real benefit to masking it considering the typical usage of a billing platform like this.