Tyson

Thanks for the report. I think this issue is as you described, an old state being re-used when none are available. I added this as CORE-2104. What was the original state set to?

If there are no states for a country, setting the country as the state doesn't really make sense. There simply is no state. It is unfortunate that LogicBoxes requires a country without a state to have a state, but that is out of our control. You can use my States & Countries plugin to update the states/countries, which allows you to define a state for the Isle of Man. That might work around that customer's issue, but there's no telling whether some other module might require the same customer to have no state.

I'd classify these as minor improvements.

The solution to this issue is to have the currency precision set to 0 for that currency. Since you set the precision to 0 after the invoice was created, you will also have to edit the invoice and re-save it before it will observe the new currency precision. Then the customer can make a payment via PayPal.

Thanks, this is CORE-2102.

The content you set in the Package Welcome Email needs to also be set in the Service Creation email template. Under [settings] -> [Emails], edit the 'Service Creation' template. Make sure that the HTML version of this template uses this tag: {package.email_html} That adds the HTML version of your package Welcome Email into the template. Similarly, the Text version should be set in the Text tab: {package.email_text} When a service is created, the client will receive this email, which will also include your package welcome email content in place of those tags. The service information page only lists common information. Information specific to the service module itself (like the IP address) can either appear on the service row as I mentioned above, or in a tab created by the module (like the Console tab). The root password is the user's password, correct? The user's password could be updated via the API. I'm not aware of whether Proxmox will require a reinstall because of it. You might try testing this by changing a user's password manually and restarting the server.

You should still store it in the session. What I am suggesting is that when you read it from the session, you set the configuration value afterward. // Selected language $language_code = $this->Session->read('language'); # # TODO: ensure the $language_code is a valid language in the system, # otherwise fall back to the default language # // Set the language Configure::set('Blesta.language', $language_code); Language::setLang(Configure::get('Blesta.language')); The end result is that these values are consistent: $this->Session->read('language') === Configure::get('Blesta.language')

This issue is fixed in CORE-2011 for v4.0.0 of Blesta.

The received date issue is resolved in CORE-2069 for v4.0.0 of Blesta.

You should be able to find the IP address by clicking on the service table row. As an admin, go to the client's profile page. In the Services widget is the list of services. Click on the table row (not the links) for that service. A section will appear below it that shows you the username and IP address. The same can be done in the client interface. I'm not sure if SSH credentials are available via the API for them to be displayed in the UI, but if so, the module would need to be updated to fetch them. Currently, only the VNC console information is fetched for the console page. For the email that the client receives, you'll need to set tags in your package welcome email template in order for them to be included with the Service Creation email. These are the tags with a brief description: {service.proxmox_vserver_id} - VM ID {service.proxmox_hostname} - The hostname {service.proxmox_node} - The node ID the VM is on {service.proxmox_type} - VM type [openvz, qemu (KVM)] {service.proxmox_username} - Account username {service.proxmox_password} - Account password {service.proxmox_cpu} - Number of CPUs {service.proxmox_memory} - RAM in megabytes {service.proxmox_hdd} - Storage in gigabytes {service.proxmox_netspeed} - Network speed in megabytes per second {module.host} - Proxmox server hostname {module.port} - Proxmox server port If you want the ip address to be available to the welcome email, you'll need to update the module. Open /components/modules/proxmox/proxmox.php and find this line: 'service' => array("proxmox_vserver_id", "proxmox_hostname", Update that line to: 'service' => array("proxmox_vserver_id", "proxmox_hostname", "proxmox_ip", Once that is updated, this tag will also be available to the welcome email template: {service.proxmox_ip} - The IP address

The company language will be the default when not logged in, and en_us will be the default if no other language is known. I haven't looked at the AdminTools plugin, but I think it should probably be setting the language like this: // Selected language $language_code = 'en_us'; // Set the language Configure::set('Blesta.language', $language_code); Language::setLang(Configure::get('Blesta.language')); Then the configuration value I mentioned above would be accurate. The system also uses this configuration value for various actions/queries and does not look at the session, so I think it's important that it be updated.

these this

What do you mean by this? Also, Form::fieldText is generic. While it defaults to 'text', you can override this with attributes, e.g. // Email field $this->Form->fieldText('name', 'value', array('type' => 'email'));

It's a nice addition. I just hate to see templates making calls to the session. I think you can use the configured language, no? // User's language $language = Configure::get('Blesta.language');

No new events yet. I don't think any methods are being removed for this version, but that could change. Any methods with the @deprecated annotation are on the chopping block.

This issue is resolved in CORE-1879 for v4.0.0 of Blesta.

This issue is resolved with CORE-1877 in v4.0.0 of Blesta.

This issue is fixed in CORE-1942 for v4.0.0 of Blesta. You can run the following query to fix the issue in the interim if you encounter it after adding a new company: UPDATE `company_settings` SET `inherit` = 0 WHERE `key` = 'tax_id';

It's a limitation of plugin actions. See CORE-1697. You can add as many as you want if you add it under a primary navigation link you create, similar to the Support Manager.

You should update those queries to encapsulate the values in quotes, otherwise running them will generate a syntax error. UPDATE `emails` SET `from`='billing@domain.com' WHERE `from`='billing@subdomain.domain.com';

We could use more info from How to Report a Bug, such as what the behavior you experience is, what error is received via the API, and preferably an example that illustrates the issue for us to duplicate it.

Blesta only marks orders as fraud if you have Maxmind configured in Blesta to reject them based on score, free emails, etc. Otherwise the order will require review (i.e. manual approval). Again, this depends on how you have these settings configured in Blesta under the [Packages] -> [Order Forms] -> [settings] tab. If an order is rejected, then I believe no payments could be accepted for the order because the customer is unable to get to the payment step.

Also make sure that the cron task that delivers the reports is enabled. Under [settings] -> [Company] -> [Automation], "Deliver Reports" should be enabled.

Here are the tags. The email subject is used as the ticket.summary, so you can reference that field in the email template.

Browser notifications are nice, but most browser support still requires the web site to be open. It's good to see that Firefox is implementing the W3C standard, but like with many new features, there is often a fair amount of time that has to go by before the standard is adopted in practice. And of course, people have to upgrade their browsers to make use of it. We're unlikely to include a feature that is not yet widely supported by multiple major browsers. Even if we do offer some desktop notifications (we have discussed this), it would be completely optional.