Leaderboard

I'm just going to toss this out there - CORE-639 would allow for percentage discounts based on client group. The potential issue I see in this case, is that the discount would apply globally across all packages at the same rate.

and a school bus

We are switching from SVN to Git soon, though it's unlikely at least for now, that there will be public access. We have a build process, and part of that process is to pull in externals. All extensions have their own version numbers and belong to their own repositories. So, even if we did allow public access, there's more you'd need to do in order to have everything that's in a build. We'll be announcing more details about this and more as we get closer to a 4.0 release.

I saw a picture of a polling station inside a shipping container lol

Hi Razva, Thanks for stopping by, I recall seeing that thread. To answer your questions - 1. Blesta does not currently support config option logic, however I do see us implementing this in a future release. We fully plan to provide better support for dedicated servers. 2. We do include a Proxmox module with Blesta, and a 3rd party developer has released a modification of it here - http://www.blesta.com/forums/index.php?/topic/4037-module-proxmox-reloaded-beta-release/. I don't believe our version includes support for configurable options, and it has noot been updated since we introduced config options in Blesta. 3. Blesta does have multi-lingual support, and in many areas where you define the language you can enter a custom language definition. One example is Contact Types which you can define in the interface. See http://docs.blesta.com/display/user/Company+%3E+General#Company>General-CreatinganewContactType There may be other areas that could benefit from this.

Take a look at the order form by editing it under [Packages] -> [Order Forms] and see if you have a checkbox checked for "Require Manual Review and Approval of All Orders". If so, all orders placed on the order form will not be created until you manually approve them for activation. To manually approve an order, you must have the Orders widget installed, which is available under [billing] -> [Overview]. If you do not see an Orders section when you go to that page, you need to add it to the page by clicking "Manage Widgets" on the left. A pop-up will appear. Drag the "Order System" box to the left side of the pop-up, then close it. The page will refresh and the Orders widget will appear on the page. A table listing will show all orders. A green check icon indicates the order was approved, and a red X icon indicates it has not been approved. To approve an order, click the checkbox next to the order in the table listing. At the bottom of the table, to the right, an option will appear called "Mark as:" which will allow you to mark the checked orders as a different status (Accepted, Fraud, or Canceled). Setting it to "Accepted" and clicking "Update Orders" will mark the checked order as approved. Once it is approved, the service will be provisioned automatically when 1) the invoice for that service is paid and 2) when the cron runs to provision paid pending services.

There seems to be confusion on what the username affects. On an order form, when a customer is asked to register for an account, that is for a client account in Blesta--not for cPanel. When ordering a cPanel package from the order form, a customer is only asked for a domain. The cPanel username and password is automatically generated and created in cPanel if it does not already exist. If you're having trouble getting a cPanel service to be synced up in Blesta, try adding the service as an admin from a test client you have in the system. Click the Add Service link as shown in this screenshot under Actions on the left. You can set it to "Do not invoice" for the service, and then create it. The service should be provisioned immediately, and appear as an "Active" service in Blesta. If that occurs, then your cPanel settings are correct. In that case, the issue you're probably having is that the orders from the order form are set to require manual approval, and you simply have not manually approved them yet, as Paul mentioned earlier.

it's in his signature in red .

This is what restricted packages really are for. The issue however, is that we have not yet made restricted packages show on order forms. If added to an order form, restricted packages should only appear to users who have access to those packages under their client profile > Actions > Set Packages and whom are authenticated. Without the ability for clients to order restricted packages they have access to, restricted packages can only be administered by staff. Price overrides work well for one off price reductions that are unique per client, and Restricted Packages work for selling in tiers (Once we can get it working with the order form). Our Blesta reseller plugin that we use internally adds monthly licenses as "one time" services and handles the billing for them via its own automation task. It allows clients to be added as resellers, and pricing tiers to be assigned to them. This is similar in a sense to the other methods, and what you describe, but it requires the plugin to take over invoicing, which is currently only possible for one-time package options. I mention this as it's a unique way of handling tier based recurring billing using a single package. I think we were considering an event or feature where a package could get its pricing from a module or plugin. Such a case would allow the plugin to determine the pricing within itself.