Paul

The thought crossed my mind as well, but this is a much more complex feature for config options that could be implemented in the future while maintaining backwards compatibility. CORE-1329 solves this for now.

Glad that solved it for you, and thanks for letting us know it worked!

After discussing with Cody, I've added task CORE-1330 to address the display value for dropdown, checkbox, and radio fields within the client area. In these cases, the name and not the value should be displayed. This will correct the issue you describe where the Daemon ID is displayed, rather than the location name. It's a change to the core, and should be included in 3.2.2 (If there is one), and 3.3.0.

Or perhaps where configurable options are displayed, the name of the field should be shown instead for drop downs. This has more to do with the configurable options than the multicraft module so we'll need to evaluate. The result would be as you describe, showing the friendly location name rather than the Daemon ID, but the question is whether this is an acceptable solution across various other modules and uses of configurable options. I suspect it is.

You just started a trial? I'll PM you a key also.

I sent you a PM with a new trial key, let me know if it gives you any trouble!

A feature like this would need to be built into the specific module, for example a configurable option available to cPanel, or Interworx, etc. What module are you using?

The layout is fluid, so the amount of real estate in the header varies, and in terms of UX I prefer to keep things clutter free. A dashboard widget would be preferable, and also.. plugins can create overlay menus which could appear on every page, for example in the bottom right of the browser window. There's a lot of options but the important thing is that the branding for each company is completely independent and customizable.

Communications are completely branded yes, as each company has its own set of email templates. Each company/brand in Blesta is completely unique in terms of branding and settings, they are as close to separate installations as you can get without having separate installations. You would need to switch from Company A to Company B to see tickets in Company B with Blesta multi-company. It's possible to have different support departments, different email addresses for those departments, different ticket importing (pop/imap/piping), different staff access levels to departments, and more, across companies. Different predefined responses, and different staff signatures for tickets too. It sounds like you want a sort of hybrid between multi-company and multi-brand. It would be possible, with changes to the code, to allow the support manager to display tickets across companies but not without compromise. Perhaps a sort of "Company Overview" widget would be useful, where you could see an overview from any company of all the support tickets open in each company, and click to switch companies to view them. This would give you a birds eye view without having to switch companies to see what's going on. This could be implemented as a plugin, and we are open to these kinds of ideas. We see multi-company as so much more than multi-brand and it's been very popular so far among those displeased with the existing half baked multi-brand options out there.

When you create a Universal Module product, you just have to give it a name. Then select Universal Module, and the product name when creating a package. In the future, we're going to streamline the process of package creation so that you don't have to go create a universal module product first.

As Mike said, you can switch companies as an admin with a simple dropdown at the same URL. Each company is very much separate in terms of the UI, so you'll only see Company A when Company A is selected for example. One other major advantage is that your staff members can have different roles at different companies. Let's say you have a staff member named John, and you want him to handle support in Company A, Billing in Company B, full access to Company C, and NO access to Company D, E, and F. You can do that, and they can switch between companies they have access to, having just those ACL permissions you set for them, and the permission options are extensive. This goes beyond what most people see as "multi-brand" because of the separation and ACL permissions. When you are "in" a particular company, you see only that companies clients, services, transactions, reports,.. everything. And, you can customize your dashboard, and billing overview widgets separately too.

Ah, yeah proforma invoices are done and ready to ship with 3.3. Still, Blesta is fully multi-currency, and VAT is supported.

Also, since you came to us looking for multi-company support I'm happy to add a few companies to a trial license for you. PM or email sales your trial key (You can find it under Settings > System > General > License Key) and I'll add some so you can try it out. Multi-company in Blesta is magnitudes better than the multi-brand option they have over there. It's something that really needs to be included from the ground up, which is what we did. Original multi-company announcement + video is here - http://www.blesta.com/2013/05/02/blesta-3-0-multi-whaaat-video/

Mike, why do you say UK currency and VAT are not supported? VAT can be set up under Tax settings, though it's not referred to as VAT specifically there. WebsitePanel and SagePay are on our radar. SagePay is assigned to CORE-141, but we haven't implemented it yet because there hasn't been a lot of demand. No task currently for WebsitePanel, but we've had some requests for it lately. All extensions we ship with Blesta are listed here - http://docs.blesta.com/display/user/Extensions, click Gateways, Modules, or Plugins to drill down and see what is supported for each type. We've been focusing on solidifying the core set of features, and development of additional gateways and modules will speed up soon.. but, WebsitePanel and SagePay don't look like they would be very difficult to implement. For Kayako and shared login, this plugin may help -- http://docs.blesta.com/display/user/Shared+Login, though I'm not sure exactly how it would need to be implemented for Kayako.

I added the multiple Daemon ID improvement to CORE-1329. I'd like to discuss the multiple IP address / port provisioning recommendations with Tyson before I create a task on that. If anyone has anything to add, please chime in. As for the Multicraft account (And FTP), the account is created when the first server is provisioned for the account, and this email should contain the login details for Multicraft. Subsequent servers are added to the same account, and the Multicraft login details are unknown by the service so they are not included. This can be handled in the welcome email by using a conditional statement or a note to say that it's the same login as the previous servers. We are working on a feature where modules may share information between services, and I hope to have this in 3.3. This would allow a 2nd, 3rd, etc server to include the same login details as the first.

With configurable options, it would be possible to add multiple Daemon ID's to the config option, ie "1,3,5,7" as the value, but then the module would need to look for that, and parse out the ID's, choosing from one of them to provision. Do you see this as a viable solution? It should be fairly easy to implement. I believe Multicraft determines the port number to use, so a couple questions for you as I try to understand the reasoning behind this. 1. Is there a benefit for selecting a random port number between 10,000 and 65,000, other than making it difficult for someone to guess what port the minecraft servers are on without doing a port scan? 2. With 50,000+ possible port numbers, why would additional IP addresses be used on each Daemon ID for shared (not-dedicated) purposes? Thanks! We appreciate your feedback.

This should help with creating configurable options also -- http://docs.blesta.com/display/user/Creating+Configurable+Options

I do like the email staff + cancellation requests field on billing overview. Not sure we can do that *and* open a ticket, as the billing overview tracking the requests would necessitate a separate area for managing them besides tickets. User Action: Request Cancellation, enter reason Email Staff the cancellation request with reason, including details about the service and the reason Display the cancellation requests in the billing overview widget Provide an interface in the staff area for staff to review and approve or reject cancellation requests (Optionally, now or in the future) Allow a department to be set for cancellation requests to additionally open a ticket. These tickets would not replace the review and approve/reject section. Thoughts?

I have replied to your PM. The dedicated IP option does appear for the service.

Thanks for the information, it would not make sense for us to implement this considering it will be discontinued. We would want to implement the next most popular option, or the option which will be most popular when Maxmind retires the service.

Has Maxmind announced that they are retiring their phone verification service? What is the most popular alternative for voice verification?

I'm happy to take a look at your install if you want to PM or email me login details, and advise the package ID in question and configurable option in question.

Please see CORE-590 (It's been planned for some time) and related CORE-1267. Initially I believe some people requested this to open a ticket with the reason, however the support manager may not be installed. We are open to suggestions on how this will work, and where admins will go to review.

I had an idea that if you're logged in as an admin, the order forms have a special button or action where you can "Save Cart", which will create a special link directly to that part in the checkout process. It would be able to store coupon codes, configurable options, etc to drop the user directly into the same step of the order form with the same details filled out. It may be a lot of work though, so not sure if/when we will do this.

I sent them a note through their contact form.