Tyson

If what Paul described is not the issue, could you elaborate on the problem? "blesta module not work" is not very descriptive, and I'm left just as helpless as you in determining why that's the case.

I'm not sure why the email is blank for you. Perhaps you added the {% debug %} statement into the wrong type (HTML/Text)? This appears to work fine for me, so to clarify: Navigate to [settings] -> [Company] -> [Emails] -> . Edit the "Invoice Delivery (Paid)" template Replace both the HTML and Text versions of the email with simply "{% debug %}" Navigate to a client that has paid invoices under [Clients] From the Invoices listing, click the "Closed" link to view only the closed invoices Check one of the checkboxes to the left of an invoice Make sure "Deliver via Email" is selected, along with your email address, and click to Submit Check your email. Sample output: [invoices] => Array ( [0] => stdClass Object ( [id] => 328 [id_format] => {num} [id_value] => 22 [client_id] => 1 [date_billed] => 2014-07-21 19:39:44 [date_due] => 2014-07-21 19:39:44 [date_closed] => 2014-07-21 19:39:46 [date_autodebit] => [status] => active [subtotal] => 1.3900 [total] => 1.4000 [paid] => 1.4000 [previous_due] => 2.8000 [currency] => USD [note_public] => [note_private] => [id_code] => PD-22 [delivery_date_sent] => 2014-07-21 19:39:51 [due] => 0 [line_items] => Array ( [0] => stdClass Object ( [id] => 542 [invoice_id] => 328 [service_id] => 222 [description] => Product 1 - Test (Apr 02, 2014 - Jul 02, 2014) [qty] => 1.0000 [amount] => 0.3900 [subtotal] => 0.39000000 [taxes] => Array ( [0] => stdClass Object ( [id] => 1 [company_id] => 1 [level] => 1 [name] => Sales [amount] => 1.0000 [type] => inclusive [country] => US [state] => [status] => active [cascade] => 0 [tax_total] => 0.01 ) ) [taxes_applied] => Array ( [0] => Array ( [id] => 1 [name] => Sales [percentage] => 1.0000 [amount] => 0 ) ) [tax_subtotal] => 0 [tax_total] => 0 [total] => 0.39 [total_w_tax] => 0.39 ) [1] => stdClass Object ( [id] => 543 [invoice_id] => 328 [service_id] => 222 [description] => Product 2 - Test (Apr 02, 2014 - Aug 02, 2014) [qty] => 1.0000 [amount] => 1.0000 [subtotal] => 1.00000000 [taxes] => Array ( [0] => stdClass Object ( [id] => 1 [company_id] => 1 [level] => 1 [name] => Sales [amount] => 1.0000 [type] => inclusive [country] => US [state] => [status] => active [cascade] => 0 ) ) [taxes_applied] => Array ( [0] => Array ( [id] => 1 [name] => Sales [percentage] => 1.0000 [amount] => 0.01 ) ) [tax_subtotal] => 0.01 [tax_total] => 0.01 [total] => 1.01 [total_w_tax] => 1.01 ) ) [delivery] => Array ( [0] => stdClass Object ( [id] => 321 [invoice_id] => 328 [method] => email [date_sent] => 2014-07-21 19:39:51 ) ) [meta] => Array ( ) [tax_subtotal] => 0.01 [tax_total] => 0.01 [taxes] => Array ( [0] => stdClass Object ( [id] => 1 [company_id] => 1 [level] => 1 [name] => Sales [amount] => 1.0000 [type] => inclusive [country] => US [state] => [status] => active [cascade] => 0 [tax_total] => 0.01 ) ) [billing] => stdClass Object ( [id] => 1 [client_id] => 1 [user_id] => [contact_type] => primary [contact_type_id] => [first_name] => First Name [last_name] => Last Name [title] => [company] => Company [email] => me@myemail.com [address1] => 123 Test St. [address2] => [city] => Testville [state] => AK [zip] => 38181 [country] => stdClass Object ( [alpha2] => US [alpha3] => USA [name] => United States [alt_name] => ) [date_added] => 2014-05-08 21:35:13 [contact_type_name] => [contact_type_is_lang] => ) [client] => stdClass Object ( [id] => 1 [id_format] => {num} [id_value] => 1500 [user_id] => 2 [client_group_id] => 1 [primary_account_id] => [primary_account_type] => [status] => active [id_code] => 1500 [contact_id] => 1 [first_name] => First Name [last_name] => Last Name [company] => Company [email] => me@myemail.com [address1] => 123 Test St. [address2] => [city] => Testville [state] => AK [zip] => 38181 [country] => US [group_name] => General [company_id] => 1 [username] => me@myemail.com [two_factor_mode] => none [two_factor_key] => [two_factor_pin] => [date_added] => 2014-05-08 21:35:13 [settings] => Array ( ... [client_set_lang] => true [client_view_dir] => bootstrap ... ) ) [payment_url] => mydomain.com/clients/client/pay/method/328/?sid=NdMxFyn8bABZeuJeKxEIvG%2FXAvTifTRRYLtbtheHExW4%3D [autodebit_date] => ) ) Sample usage in the email template: {% for invoice in invoices %} Invoice #: {invoice.id_code} Pay here: {invoice.payment_url}{% endfor %}

That looks like an expected error when Blesta checks with the module to see if an account already exists before deciding whether to add one or not. If the cron task continuously fails when adding a service, there may be a fatal error that is halting execution. If that's the case, you can find out what the error is by either checking your server/php logs, or by running the cron manually when there is a service pending to be added.

That's correct. You can verify by running the first query I posted above and having no records returned.

Pending orders differ from pending services, which is why those numbers are not identical. Compare the dashboard System Overview with the Order widget under Billing Overview instead. If you have to clear a task lock, then there is an issue with a service, module, or some related configuration that is preventing the cron task from completing. For example, Blesta could tell cPanel to activate the service, but cPanel may never respond back to Blesta to say that it has created the account, in which case the account would exist in cPanel, but not be activated in Blesta. What you should do is check the cron and module logs for more information to identify the cause. What happens if you try to provision it manually instead?

Blesta uses the ISO 3166-2 standard for subdivisions, and is not necessarily limited to a simple list of counties.

The uploads directory should go somewhere above your web directory (where it's not web accessible), and it doesn't really matter where exactly so long as the path set in Blesta points to it. The setting can be found in Blesta under [settings] -> [system] -> [General] -> [basic Setup]. Since you're performing an upgrade, you probably already have the /uploads directory on your server from the initial installation. The php5.5 hotfix is only used if your server is running php 5.5. If you are running php 5.5, then you would overwrite the files in /blesta with the files in /hotfix-php5.5 when you perform the upgrade.

Where does Blesta say the username is the email address when it's not? And are you trying to login using the log in link in Blesta, or directly in Inteworx? Maybe Inteworx has changed the login in some recent update, but this is working properly for me on v5.0.14. The login clearly expects email address, password, and domain.

Closing as not a bug.

There aren't any routes that would conflict with /portal/ by default. I've just tested this on one of my installations and haven't had an issue with any of the URLs. Do you encounter this issue when the cron runs, when you send that email manually, or both? What version of Blesta are you running? You may want to check that your root web directory setting is correct under [settings] -> [system] -> [General] -> [basic Setup].

Sounds like it may have been a problem with your browser. You should only see the client's selected language if you're explicitly logged in as a client.

I'm not able to duplicate the issues you receive, but that would be better described in a separate thread. There are several issues with translating on your own computer and uploading them somewhere--I don't see this as something that can (or necessarily should) be supported. I understand the translator doesn't currently support all of the features you may desire, but it can be improved. I reject the idea that it is easier to translate all of the files outside of the translator, unless you are translating only for yourself. Most people seem to have a hard time finding the language files they're looking for, so I wouldn't expect them to update the thousands of definitions in over a hundred separate files. Unless you're having a similar issue as hadzo with the translator, then you should be able to write and submit a translation in a few seconds, using only your keyboard. Please create a new thread if you want to discuss other issues with translating definitions.

I have seen a feature request for Digital Ocean, but we have nothing in the works at the moment. Perhaps a third-party developer could create it. How do you imagine hourly billing would work? There are a couple discussions about it here and here, but it is a feature we haven't hashed out yet.

As I mentioned in the first post, the translator is updated periodically, so the translations you write are not immediately available for download. One reason you may receive the message that you successfully completed the translations when they are not 100% complete is if you are translating for confirmation. That is, you're translating the subset of translations that others have already contributed. You can change that by clicking the change link or updating your account in the translator... "Showing terms FOR CONFIRMATION Change?" ...and changing the "Show Terms" option to randomly or in order.

Are you logged in as the client? And I don't mean being an admin and clicking to "Log in as Client" from the interface. If you're an admin, you always see content in your language, even if you go into the client interface. If you log out as admin and explicitly login as a client, then you see content in the client's language. And this is how it is working for me. Does it work differently than I described for you?

Which email template is not working? All should be using the same logic to set the URL.

Thanks. CORE-1355

By removing all records from the `invoice_delivery` table, you would be clearing the queue of all invoices set to be sent, and all invoices that have been sent in the past. There are two downsides which may already be obvious: Any invoices that were queued to be delivered will not be delivered The system will no longer have a record of when previously-queued invoices were marked as sent If you were to empty the `invoice_delivery` table, I see no reason not to then enable the cron task to deliver invoices. Since no invoices would be queued to be delivered, nothing would get sent automatically. If you have existing invoices that should be sent, then you will need to send them manually. Sending them manually will send them immediately, effectively bypassing the queue.

I think that problem has been resolved in CORE-1354.You can wait for the next version for the fix, or add the autodebit setting with a value of 'true' to that clients' settings. I think you can simply click the link on their profile page to enable auto debit, or instead add that setting to the `client_settings` table.

So the deamon ID was erroneously set to 'localhost', and so it defaulted to the Multicraft default daemon? Where was the daemon ID set to 'localhost' at?

The cron sends invoices that are queued for delivery. The status of the invoice is irrelevant. For instance, if you create an invoice that you want to be automatically delivered to the client for their records, but the client pays for it immediately after you've created it, it will then be closed. Five minutes later when the cron runs, it will still deliver that closed invoice to the client. If it didn't do this, then the client wouldn't have a copy of the invoice which you explicitly said you wanted done when you created it. The query I included above does not delete closed invoices, rather it removes them from the delivery queue. Those invoices will simply not be queued for delivery anymore, and thus, a copy of them won't be sent to the client when the cron runs. Based on the issue you've described, this sounds like what you want.

You can send it over to me or link to it in this thread. As I recall, CCAvenue does not provide test accounts, so we would have no way to test changes made to this gateway. It would be great if you could help confirm any changes we make to the gateway as working properly.

If you want to remove closed invoices that are still scheduled for delivery, then you can: Backup your database Run this query to delete them DELETE `invoice_delivery`.* FROM `invoice_delivery` INNER JOIN `invoices` ON `invoices`.`id` = `invoice_delivery`.`invoice_id` WHERE `invoice_delivery`.`method` != 'paper' AND `invoice_delivery`.`date_sent` IS NULL AND `invoices`.`date_closed` IS NOT NULL AND `invoices`.`date_billed` <= UTC_TIMESTAMP() AND `invoices`.`status` = 'active';

Could you provide a link to the API documentation? If what you say is true, then I am deeply saddened by their lack of backwards compatibility. I can only imagine the number of customers they lost as a result of that.

There should be more to the module logs than that. If Blesta created that VPS via the API, then it has been logged. You brought up this issue a week ago, so perhaps you're not looking at the right log, or the logs may have been deleted based on the log retention policy, which defaults to deleting logs older than 10 days. You can create another VPS from Blesta and then immediately check the module logs. They would be useful in checking what operating system Blesta is sending to SolusVM.