Tyson

Allowing multiple daemon's per location sounds good to me, although I am less-enthused with comma-separated values. I'd much rather have configurable options support a one-to-many type that can be used for a select/multi-select field, for example, to choose one, or some, of the values. That would accomplish the same thing here, but it would be a completely different task. IP management is a little more complex. I'm not sure how Multicraft chooses what port to use, but I imagine that it starts at one port (from a config setting in the Multicraft panel) and increments from there for additional servers, while checking to make sure the port is unused. This last part is what Blesta and the Multicraft API can't determine. Sure, we could have the module support a hard-coded or user-defined port range for a daemon, then randomly choose a port to use from the range, but that port could be in use by another multicraft server or a different service altogether. I don't see a way for us to determine whether a port we choose is actually available for use. Similarly for daemon IP addresses--it doesn't look like the Multicraft API allows us to determine what IP addresses are available to a daemon. If you take a look at the Multicraft Settings, there is an option to choose how an IP is chosen when a server is created ("All Interfaces (0.0.0.0)", "Daemon IP", "Daemon FTP IP"; default "Daemon IP"). I think that Multicraft should allow the kind of IP/port management configuration you suggest, rather than Blesta. All Blesta really needs to tell Multicraft is to "create a server for me" (as it currently does), and the IP:port associated with that server should be determined by Multicraft and your configured settings.

The ajax order template doesn't have a cart template file. Did you install version 3.2.1 of Blesta and the included Order plugin?

Modules from other systems are incompatible with Blesta. It will need to be re-written specifically for Blesta. You can take a look at the module documentation on how to create a module.

Have you checked the module log for a reference to that event? Blesta will make any module calls necessary before unsuspending the service, unless you unsuspended the service manually and did not have "Use Module" checked.

I think Cody responded to a ticket you've opened with us regarding this issue. Others experiencing this issue might find this helpful. We're currently looking into this as apart of the CORE-1321 task. In the meantime, you'll probably want to set the URL yourself in the CMS plugin (under [settings] -> [Company] -> [Plugins] -> [installed] -> [Portal] -> (Manage)). Find: <a href="{blesta_url}order/"> and change it to the URL of your default order form, e.g. <a href="http://modbox.com/clients/order/main/index/hosting">

Based on the module logs you included, Blesta specified no daemon ID, and so Multicraft determined one to use instead. I don't know why Multicraft would choose an invalid daemon ID. Blesta only sets a daemon ID if specified as a configurable option, or if you are using one of your explicitly-defined dedicated IPs set in the module, but it looks like you've done neither.

I think you want to use {module.host_name}. {service.ip} is not a valid tag for the cPanel module.

Thanks. What is a URL to one of your order forms?

Closing as a duplicate of the other thread.

Whether you see a currency drop-down depends on whether your order form has multiple currencies selected, and what step of the order form you're on for the specific order template type.

Yes. The email tags you see listed for that package's email template are all that are accepted, and {service.domain-field} is the only one set by Logicboxes.

What URL does the order button take you to from the portal?

Each module sets its own accepted email template fields, so it is valid that one might be {service.domain_name} while another would be {service.domain-name}. You can take a look at each module's documentation for a list of all the welcome email template tags.

We really need more information to help determine what's going on with your system. How many cron jobs do you have setup for Blesta? Have you checked your cron logs to see what tasks have been run and what they've done? What emails have been sent that you think should not have been? The client mail log shows emails the client has received. You can check the company email templates for a list of templates, and determine which templates were used to send those emails.

Don't use {ticket} as a tag by itself. It should be obvious a ticket has many fields, such as {ticket.code} and {ticket.summary}, which you should use instead. Until we come up with a better way to display supported tags in the interface, you can check out the documentation for a list of all supported tags.

There are no modules that are installed automatically since Blesta doesn't know what types of products you want to sell, if any. You encountered that error because you clicked the Install button more than once very quickly, and multiple requests were sent to Blesta to install the module. You could cause the same error when installing gateways or plugins. This is a very minor issue, and wouldn't cause any issues in the system other than you seeing that stack trace error, but I've created a task to look into fixing that in CORE-1313.

Probably useful to note that the forum does not consider the OP of a thread to be a possible solution, and so no Mark Solved button is available on that post. You have to create a follow-up post and then mark that one solved instead. But it looks like you've already figured that out.

3.2.1 blast off toward 3.3!

I think he wants an option to also filter reports by client group. Reports specify their own filtering options individually, so each would need to be updated with this option. I'm curious if others would find this useful.

We currently have no plan to allow services to be moved between clients. But you could create a feature request in the appropriate forum. I wouldn't consider this a basic feature, though. I might classify it as a possible security vulnerability instead, as assigning a service to a client means they have access to that service, and so with something like a cPanel service, that client will have login information and account access. By then moving this service to another client, you would need to update, at minimum, the login credentials of that account so that the other client does not have access to this service anymore. And some modules, be it from the API or otherwise, do not allow user credentials to be changed. So for those kinds of services, you would need to delete and re-add it anyway. There is no work-around.

There is no method by which you can move services between clients. If it's still Pending, then you can delete it outright, otherwise you'll need to cancel it. Then recreate it on the correct client.

I would think if we displayed that field, it would only be shown when adding a service. Since we show the date the service was created to the user, it may make sense to allow thes field to be set. However, I don't see a scenario where it would be necessary to edit the creation date after the service was created. Dates in the database are stored in UTC, so unless you set the date in UTC, you probably inserted the date in your local timezone, which would be incorrect.

This is fixed in CORE-1309

I know that it won't update locally unless you use the module. I'll see if I can get this fixed before we build v3.2.1. CORE-1309

The Support Manager attempts to create the directory when installed, yes. However, if you have an invalid uploads directory set (under [settings] -> [Company] -> [General] -> [basic Setup]) at the time you install the plugin, or your user does not have permissions enabled to create a directory at that path on the server, it could fail to do so.