Paul

I'm pretty sure neither HB or WHMCS allow contacts to login to multiple different client accounts. We were thinking ahead when we architected the authentication system, so it would be possible in a future release without too much work for a client to have access to multiple companies with the same login. The same may be true of contacts.. but it's not a feature that is widely requested, and nobody else does it to my knowledge. If someone else does do that, I'd love to check it out.

Your phpinfo does seem to know the correct path. The company hostname should not contain the directory path. Interesting

It shouldn't no, though that may be a separate issue. Check if any are hung in Tools > Logs > Module Log. You could put a PHP file in a sub-directory in the server with the following PHP code in it: <?php phpinfo(); ?> and then load up the file in your browser to see if it detected its location. That's effectively what Blesta does, is check the path and determine what the full URL ought to be. Might need some feedback from Cody or Tyson on this, maybe they have an idea of what may be causing the issue. More details about your server environment would be helpful though. OS, Web Server, MySQL, PHP versions.

The forward slash should indeed be included at the end. So the paths are all correct there, but the links have the wrong path? Since those emails are likely being sent out via cron, I wonder if it can't detect the path via CLI. Try testing this out, via your browser. If you find an invoice on a clients profile page, click the check box and have it sent to yourself, does the correct URL appear or is it the same?

You should also click the cog/gear icon on the Billing > Overview page for the Orders widget. You can subscribe to order emails so that you are notified for new orders. Each staff member who has access to this widget can access this and receive new order emails. While getting payment notices may be good, this is probably what you want.

You should update the email templates to set https:// for your links where necessary. Under Settings > System > General for "Root Web Directory", is this path correct? If it's not, please correct it. It should be the full server path to your Blesta installation directory, ie /home/username/public_html/ -- wherever Blesta is installed.

Thanks for your help on this @Max, glad this has been resolved. I have mentioned this in the documentation at http://docs.blesta.com/display/user/Installing+Blesta#InstallingBlesta-Errors as well. If you have any comments/suggestions on how this can be worded better, please let me know.

You should restore the files back to the same version you were running also. It's trying to access a database schema you haven't upgraded to yet.

Settings > Company > Look & Feel, Staff Tab. Click edit next to the theme. If you are using the default them, click the "export" option, then import as a new theme, then edit and change logo.

We have plans to have a Blesta importer to go from an identical version to an addon company. This would be useful in consolidating when hosting providers acquire other hosting providers. Demand has been low, so I don't have an ETA at the moment.

That looks really great! What are your plans with the module?

Sounds like it was a very captivating, interesting movie.. ? lol

I saw the latest Hobbit movie the other day, Kate (Evangeline Lilly) from Lost plays Tauriel. Awesome series. And it's 2015 here now. Hope everyone has an awesome year!

I can provide a virtualmin VPS for testing, if you want.

It's 10:30am here right now, we got a long ways to go. You guys are in the future.

I don't mind taking a look at it. It's a good idea to install Blesta on a VPS though, separate from vulnerable shared hosting accounts. If you have a fresh VPS with say CentOS 6.x on it with root access I can get it working for you.

Are you having trouble with POP or IMAP also? If pipe.php is getting the email via stdin, as with any email piping, it should work. Try what I suggested with sending the output of an email in a text file to pipe.php. If that works, you've narrowed down the issue to the mail server. If worse comes to worse, and you're willing to give me access.. I'm happy to dig into it and see what I can find out. Edit, also enable error reporting in config/blesta.php. piping a text file via a shell to pipe.php, or a bounce email may then have more information about the error.

No, mailparse is required. "pecl install mailparse" will usually do it. via a shell, "php -i | grep mailparse" shows it's available? Anything in /var/log/maillog (or your mail log pertaining to this?) I've seen cases where 777 causes issues, try 755 instead. You may try piping an a copy of the email directly to pipe.php.. ie Where file.txt is a copy of the email, including headers. To get this, send yourself an email, view the source, and copy the entire source to the file.txt file. If you must, change the to address to the proper department. This will bypass the mail server entirely.

What's your path to PHP? Is there a hashbang in pipe.php that matches? Really there should be no difference between Blesta and anyone else in terms of piping. pipe.php needs to receive the email as standard input, if it does, then it should work. The only other thing is that Blesta requires mailparse, so you should verify that mailparse is available both in your CLI and through your web server.

755 should work, that's executable for all. You could try chmod +x pipe.php to be certain, but that's probably not the issue. Where does DA store the forwarder file? You've probably seen this page http://docs.blesta.com/display/user/Support+Manager#SupportManager-EmailPiping On a fresh CentOS/RHEL install, it would be in /etc/aliases. This page from the docs gives an example of what to use. Also, you may need to create the symlinks as described in /etc/smrsh to php and pipe.php.

Well said @PauloV. Cheers.

Happy New Year! 2015 should be a good one!

Since you are using Blesta Future it's hard to say as I'm stuck in 2014 at the moment. Good to know there will be a 5.4, I hope it's awesome. In all seriousness, you need to find the module row. In MySQL check the "modules" table for your module. Note the "id". Search the "modules_row" table where modules.id=modules_row.module_id to find the module_row.id for all module_rows related to that module. Then, for each module_rows.id that matches that module, search the "services" table, services.module_row_id. That should help you identify which services are using that module. If you can remove those services, then you should be able to remove the module. I hope that helps!

Domain Management is a big priority, it's also a big feature. The new domain management is large enough to basically require its own full release, and then some. Since we have quite a few high priority items, and since some of them are much quicker to implement, we are trying to knock those out of the way so we can put our full efforts into domains.

Yeah, if you have ACL perms to it, it should show up under Support > Knowledge Base