Tyson

The template that displays that information is used in several places. I think it makes sense that it displays "Contact Information" since the field above it asks whether you want to "Copy Contact Information From" another contact anyway. But if you want to change it, you can update the language definition in the client_contacts file to update it in every location.

The issue appears to be dependant on the timezone. While your fix may work for you, it would be incorrect for other timezones where it may produce invalid results into the past, and so it should not be used either. e.g. from 2014-01-01 00:00:00 to 2013-12-31 23:59:59 Added as CORE-1487 for v3.3.2.

Thanks. This has been fixed in CORE-1486 for v3.3.2.

Invoices for services are generated based on the service's renew date, not any of the invoice dates. You could have multiple invoices open for the same service, so it wouldn't make sense to change invoice dates to adjust (skip) billing cycles. You should change the service renew date instead.

While the mail logs show the text version of the email, if there is no text version present, it will convert the HTML version to text, and store that in the log instead.

Blesta would renew a service if the service was a paid pending service ready to be renewed. You may want to check whether the service is still in a pending state, and if not, whether the service renew dates failed to get updated.

Yes, looks like this has been a bug since v3.3.0-b1. Fixed for v3.3.2 in CORE-1482.

Multicraft chooses the port based on the port setting you have set in your Multicraft account under [settings] -> (Base server port to use on new IPs). If your IP:25565 is currently in use, you're going to receive a different port number when you assign a server to that IP. But by adding more than one server to an IP, you can no longer call it dedicated. It looks like the module is handling the use of IPs properly, but either your settings in Multicraft are not set such that 25565 is the base server port, or Multicraft internally determined, for whatever reason, that a different port should be used.

No, we wouldn't change the scope of that method from private. It performs no data validation itself, as it is not open to being called outside of the Invoices model, and you shouldn't have a need to call it directly. You can call Invoices::edit to add more line items to an invoice.

So you're saying that: You have dedicated IPs available for a module row that are not currently in use, and they are set to the correct daemon ID in Multicraft as you have defined them in Blesta - as described in the docs You add a service, whose package uses that module row, and you select the config option for a dedicated IP as described in the docs The logs show that an IP and Daemon ID combination have been sent to Multicraft as the dedicated IP address - obfuscated as "my_PUBLIC_IP" in your logs, above All of that sounds like valid behavior. So the question, then, is what IP address did you expect to be set for the server? What incorrect IP did it set, and where did it get this incorrect IP address from? The module would only select an IP address that was available in the dedicated IP list, as described in #1.

When someone orders a dedicated IP using that config option, one of the IPs that you have set under [settings] -> [Modules] -> [Multicraft] (Manage) -> (edit) will be chosen if it is not currently in use. If none are available, it will instead choose the best daemon to use based on memory usage, and Multicraft will assign an appropriate IP. You could write a plugin that adds a cron task to perform that action on the module via cron.

Based on your logs, it looks like it's working correctly. Is the "my_PUBLIC_IP" not correct? You could create an addon that uses the config option, but I'm not sure that's what you're looking for here. Config options don't have limits, so as long as they are assigned to the package they will be available. You could set a limit on the package instead, and only set that config option for that package--kind of like a dedicated MC server only package. A suspended service in Blesta can be reactivated upon payment, or manually if you choose to do so. So it does not immediately delete the Multicraft server on suspension. You can, however, delete the server by cancelling the service instead. The directory for any saved files related to that server in Multicraft will not be deleted, though. Most people tend not to want automated cancellations to be done unless they are scheduled to be cancelled, or are cancelled manually, because there is no recovery from the action after it has been performed.

What is the date supposed to be? I'm not sure what I'm looking for. Does it appear to be CORE-1390? I'm not aware of a fix for that currently, but it may be the issue you're experiencing.

The Namecheap update to pass in custom nameservers on service creation will be in v3.3.1. I had an issue with the sandbox failing to create a service due to the custom nameservers, as it appears that unless those nameservers were actually added into the sandbox account, it would fail to add them. A live environment should be fine. Some feedback on your experiences would be great once v3.3.1 is out.

Blesta doesn't set a specific port when creating the server unless you provide that information (or it is already available from the package) when the service is created. Instead, Multicraft determines the next available port based off of your Multicraft settings and any other servers that are currently setup, in order to avoid duplicates. Perhaps your starting port number is not 25565 in Multicraft, or you have multiple Multicraft servers on that IP such that new servers get assigned a different port? I would need to see module log information to know more. Could you clarify? The log you've included looks correct--simply creating a server. There should also be several subsequent logs, and if you have an available dedicated IP setup under [settings] -> [Modules] -> [Multicraft] that was set for that service, you should also have a log entry regarding updating the server to use that dedicated IP. For example: http://domain.com/multicraft/api.php|updateServer a:3:{i:0;s:2:"78";i:1;a:2:{i:0;s:2:"ip";i:1;s:9:"daemon_id";}i:2;a:2:{i:0;s:13:"123.123.123.123";i:1;s:1:"1";}} That log shows the IP being set to 123.123.123.123 and the daemon ID set to 1. Search the page for ip and you should find that log entry indicating the dedicated IP was set. The last log in the list contains the information set for the server as given by Multicraft, which should contain the same IP. For example: http://domain.com/multicraft/api.php|getServer s:353:"{"success":true,"errors":[],"data":{"Server":{"memory":"256","start_memory":"0","port":"25580","id":"78","name":"Minecraft Server","ip":"123.123.123.123","dir":"server1","world":"","players":"10","jarfile":"","autostart":"1","default_level":"10","daemon_id":"1","announce_save":"1","kick_delay":"3000","suspended":"0","autosave":"1","jardir":"daemon"}}}";

I'll close this thread as not a bug.

Actually, the current behavior is correct. The issue you ran into is caused by the value you passed with 'packages'. As described in Services::add, 'packages' must be set to a numerically-indexed array of package IDs--not an integer. I'd recommend you update your API input to pass an array of package IDs, and undo the code change to Blesta, otherwise the system will not properly handle Inclusive coupons that apply only to multiple packages.

I think it is a request for a simple 'hello world' plugin.

Sounds like they didn't install Mailparse on the server, or it's not loaded in php. Have you checked phpinfo? After you're able to get passed that requirement, there's some more configuration info available in the email piping docs.

Ah, so a special price override specific to a client and package term combination. That makes more sense, but does add to the complexity of package pricing and management.

This would be better suited to its own support thread, but you can check the logs under [Tools] -> [Modules], and click the row of the request for more information. The API response may contain a more descriptive error.

I'm not sure I understand. If a reseller or potential user orders a service, and you have to go override the price for it, why is the package not setup at that price to begin with? And if there were an override package price option, where would that appear? I think you'd either have it on the package itself, which is redundant, or on the service, which already supports price overrides. So I'm not sure how this would be useful.

I'm not sure what you're asking? The service validation method accepts two parameters--the package and the input vars. If there is anything else you need, you would need to query for it directly, or otherwise implement a different solution. I think I looked into Pesapal recently and I had concerns with their IPN. The documentation appeared to suggest that Blesta must continuously request updates from Pesapal regarding a transaction rather than Pesapal sending those updates to Blesta after they update the transaction status. Most gateways I'm aware of don't work this way.

Hello PauloV

Client-side upgrading is not module-dependent. Whether the client can upgrade a service depends on company settings and whether other packages exist using the same module row that the client could upgrade to. But as Paul mentioned, we won't be adding features to the cPanel extended module to make any necessary remote requests to upgrade their cPanel account accordingly, if that is what you're expecting.