Paul

In general Blesta doesn't require more than 512MB of memory itself. Is that memory for Blesta only, or for the system/account? It's possible some installations of Blesta may require more memory than others, based on the extensions you have installed, the process that's running (if it's the cron), and what your data set looks like.

I added this to our "short term" bucket, and bumped it up in our back log. I assume the task, as described sounds good to you and you have nothing to add?

I got your email and have replied. There is a file attachment, so if you don't see the email please check your spam folder.

If you're on Linkedin, you can follow the new Blesta company page at https://www.linkedin.com/company/blesta Thanks guys!

Rather than allowing modules to register their own automation tasks, I wonder if it might make more sense to have a single automation task built into the system that can run tasks modules want to run periodically. I've created CORE-2435 to look at this.

Modules creating automation tasks? I could get on board with that. What are some use cases?

If you've changed the endpoint and it doesn't work, it may not behave identically to Amazon S3.

To enable error reporting, edit /config/blesta.php and change Configure::errorReporting(0); to Configure::errorReporting(-1); You may also wish to enable System Debug. To do so, change Configure::set("System.debug", false); to Configure::set("System.debug", true); If you are not running 4.0+, there is no System.debug. Switch both options back when done testing.

Enable error reporting and debugging. Disable your cron, and try running it manually. Hopefully you'll be able to see where it's getting hung up. Do you have any custom or 3rd party extensions that register automation tasks?

So just in the 2 areas highlighted here? Instead of showing the internal renew date we could do something like this: 1. If there are any open invoices for this service, display the oldest invoice's due date as the Renew Date 2. If there are no open invoices, display the internal renew date (Which should match the most recently closed invoice) Thoughts? Should the admin be updated some how to show both dates?

Just FYI, additional events were added in CORE-2364 that were mentioned in this thread for the CERB integration. A complete list of Events can be found at https://docs.blesta.com/display/dev/Event+Handlers New ones as part of this release are designated as "4.1" in the last column, "Since".

If the renew date is not updated until the invoice is paid, then a late payment would prevent the next invoice from being generated. The renew date is used by Blesta internally. Any change to this would have to impact what is *displayed* only to the client. I assume if they pay late, you still want the next month to be invoiced?

I think a fix would be required in the nvd3 library. I'm not sure if they have a pending task for this or not, I don't recall.

Thanks!

We have a new importer for Clientexec 5.5. To install, download the attached clientexec.zip and unzip the file. Upload the clientexec directory to ~/plugins/import_manager/components/migrators/ and go to Settings > Company > Plugins to install it the Import Manager. Then, manage the plugin and click on the Clientexec 5.5 link to start. Be sure to import into a fresh Blesta install. clientexec.zip What's imported? If you want to import user passwords, it's necessary to make a couple changes: Edit ~/app/models/users.php around line 715, add a new case statement: case 'clientexec-sha256': $temp = explode(':', $stored_hash); $algo = isset($temp[0]) ? $temp[0] : 'sha256'; $iterations = isset($temp[1]) ? $temp[1] : 1000; $salt = isset($temp[2]) ? $temp[2] : null; $hash = isset($temp[3]) ? $temp[3] : null; $new_hash = hash_pbkdf2($algo, $password, $salt, $iterations, 0, true); return substr(base64_encode($new_hash), 0, 32) == $hash; Edit ~/config/blesta.php and change: // Set to true to enable support for legacy passwords (plain md5). Set to false for improved security Configure::set("Blesta.auth_legacy_passwords", false); // The legacy password algorithm to use if legacy passwords are enabled Configure::set("Blesta.auth_legacy_passwords_algo", "md5"); to: // Set to true to enable support for legacy passwords (plain md5). Set to false for improved security Configure::set("Blesta.auth_legacy_passwords", true); // The legacy password algorithm to use if legacy passwords are enabled Configure::set("Blesta.auth_legacy_passwords_algo", "clientexec-sha256"); Then, continue with the import. If you don't care about user passwords, you can import anyway and users can reset their passwords using the password reset feature in Blesta. Did you give the importer a try? Let us know what you think below.

What would Xero integration look like? It's something we would consider implementing with more details. Do you just want all your transactions to be sync'd with Xero? Or is it more involved than that?

Ok good, so it's working now? I thought it was not allowing you to change the permissions to 777. 777 is probably necessary because your web server runs as a different user than your FTP/cPanel user. Should be fine as long as your uploads directory is above your document root.

What was the problem?

See if you can in cPanels file manager, maybe the files are owned by a different user?

How are you creating the file? FTP? Sounds like you don't have permissions to it. Try setting it to 777 and try again.

You could also set the package price to $2, then change it after your promo assuming that the promo is shorter than (1 month - days in advance you bill). After you change the package price, existing services will renew at the new price.

I believe CORE-861 is intended to address this. Please review and advise if you have any suggestions/clarifications. I've bumped it toward the top of the backlog, so we'll review and discuss as we plan the next release.

We are working on domain management, but it's a big task and we didn't want it to prevent us from releasing other smaller items. We'll continue pushing out regular updates, and include the domain management system as soon as it's ready. We'll reach out to all of you for testing once we get to that point.

Sounds good, and I'm curious why MXroute is refusing to send for the root domain. Thanks for filling us in if you get answers from them!

If email at those sub-domains work, but not the root domain, and both instances you were using MXroute, I think we can assume that the connection details are correct. I think we can also assume that it's likely MXroute is rejecting the email. Do they provide logs in their panel? Some do, like Mailgun. You can do a simple test by signing up for a free Mailgun account - https://www.mailgun.com, they allow something like 12k emails/month for free. Your Blesta settings would be something like: Delivery Method: SMTP SMTP Security: TLS SMTP Host: smtp.mailgun.org SMTP Port: 587 SMTP User: Your user, usually something like postmaster@mg.yourdomain.com SMTP Pass: Your password If it works, then you've narrowed it down to an issue with MXroute, and can use it as evidence in your ticket with them. Or, you can just continue to use Mailgun.