Tyson

This has been added into the cPanel Extended module as CORE-1057, and the updated version will be added to the cPanel Extended module thread for v3.2 of Blesta when the beta comes around.

Is your Deliver Invoices cron task enabled and running? Any data in the cron log regarding this? I haven't had any interruptions in invoice delivery, so we'll need steps to duplicate this if it is indeed a bug.

Does this mean an admin activated it manually through Blesta, or the cron provisioned it after the service had been paid for? This sounds like a manual service provision that only added the service to Blesta, and did not attempt to provision the service on SolusVM. Can you confirm that you are activating the service with "Provision using the SolusVM module" checked? Unfortunately for some issues, correcting or debugging them cannot be accomplished through the user interface. The reason all of the service fields are not available for edit in the admin interface is because they may pose serious security risks. For example, allowing an admin to set the virtual server ID for the service from the interface may solve the problem you're having, but if they enter the wrong ID, such as for someone else's virtual server, then that client now has access to someone else's server. Maybe that is a risk we should let admins undertake to avoid the problem you're having, but it currently does not work this way. Yes, we've considered adding filtering/search options for the logs in a future release. I have the same problem finding certain logs I'm looking for sometimes.

Please limit 1 bug report per thread following the criteria on How to Report a Bug.

Closing thread as fixed.

I think so too. CORE-1059

Yes, the intended behavior is to only completely format the total, but this is based on the invoice template and how it decides to display quantities, unit prices, and costs. Other invoice templates could be created that display content differently.

We would wrap the email address to keep it in the box. Added as CORE-1058 for v3.1.2.

I think I may have emailed you earlier about this, but the exact terms to update are: $lang['DefaultInvoice.type_active'] = "INVOICE"; $lang['DefaultInvoice.type_draft'] = "INVOICE - DRAFT"; $lang['DefaultInvoice.type_void'] = "INVOICE - VOID"; in /components/invoice_templates/default_invoice/language/en_us/default_invoice.php Note that if you're using an AU language rather than the default US language, as set in Blesta, you will need to update (and create if it does not exist) an AU copy of the file under /components/invoice_templates/default_invoice/language/en_au/default_invoice.php

Was the service provisioned automatically by cron, or manually by you in Blesta? Did you uncheck the "Provision using the SolusVM module" checkbox if you provisioned it manually? What is in the module log? If there was an error, the service should not have been activated. However, if you provisioned the service manually, not through the SolusVM module, then the service would have only been setup in Blesta, and SolusVM fields would be unknown, like the virtual server ID and password. In that case, a simple {% if service.solusvm_password %} ... {% else %} ... {% endif %} would always execute the else statement in the email template because no password is known. The SolusVM module makes use of serveral fields besides the virtual server ID, so you may need to set more than just that field. You could either re-create the service altogether, provisioning it successfully through SolusVM, or update the database service fields. To update the database service fields, search for the service by ID under the `service_fields` table. The service ID is the integer at the end of the URL when you go to manage the service in Blesta. Then you can set the `service_field`.`value` for each key as appropriate. All of the available fields are described under the Welcome Email documentation, but the most important ones would be: solusvm_vserver_id, solusvm_username, solusvm_type, solusvm_template, solusvm_plan, solusvm_node, solusvm_main_ip_address, solusvm_hostname.

The cPanel Extended module needs to be updated for v3.2 of Blesta, so I may just add this in as well.

Yes, this is the intended behavior.

The navigation doesn't support those attributes. To add them, you would need to update the navigation to support them yourself in the structure.

No, email template tags are not available to signatures. You could make a feature request for this, though. Only the tags available to the email template to which you use the signature for could be used.

From your video, it looks like they should have access to List Accounts, but I'm not familiar with cPanel's privilege settings. Paul may have more insight.

The captcha determines the scheme to use (http or https) from the server. Is SSL setup and configured on your webserver?

Sounds like the reseller doesn't have sufficient privileges for "listaccts", then. However, we may be able to update the module to not require it.

What fixed it? Fixing privileges or disabling the validation check by updating the cPanel module code?

The "List Accounts" is what is needed to validate the connection, so it sounds like the connection details are simply not correct, or that privilege is not available via the API. You may want to take a look at their Reseller privileges from the root account as described in cPanel's documentation. If you think the credentials are correct, you can update the module to disable the connection validation check, and see if you can create cPanel packages/services anyway. To do this, update /components/modules/cpanel/cpanel.php (line 1594 for v3.1.0 of Blesta) and change: 'valid_connection'=>array( 'rule'=>array(array($this, "validateConnection"), $vars['host_name'], $vars['user_name'], $vars['use_ssl'], &$vars['account_count']), 'message'=>Language::_("Cpanel.!error.remote_key_valid_connection", true) ) to: /* 'valid_connection'=>array( 'rule'=>array(array($this, "validateConnection"), $vars['host_name'], $vars['user_name'], $vars['use_ssl'], $vars['account_count']), 'message'=>Language::_("Cpanel.!error.remote_key_valid_connection", true) ) */

Fixed in CORE-1040. Seconds are optional for the 'time' field.

Have you been able to check whether the reseller account has privileges for "listaccts" via the API? Resellers need to be granted some privileges in order to run commands.

That information is not available to the structure. However, $logged_in contains the user ID, if any.

I'm not sure what you were doing, but you may want to use the date format "Y-m-d H:i:s".

We have several ideas to improve that plugin, but just wanted to get it out there to you guys. You try zipping the file?

We have a task to add that feature, CORE-702, currently scheduled for v3.2.