Paul

Email has to come into the same server you're running Blesta on. That means you need to have a mail server running on that server. The mail server would be configured to pipe email to Blesta for those addresses. This is set up differently depending on the system and whether you're using a control panel. Most panels like cPanel, Plesk, Interworx make it easy to set up the piping. If you haven't already, take a look at http://docs.blesta.com/display/user/Support+Manager#SupportManager-email-pipingEmailPiping It describes how you might configure your server manually. If you have a panel though, you should use that instead.

I created this task to address this - CORE-1593 In the meantime, I suggest setting up a forwarder for each action, and have the actions go to the forwarders. For example, service-add@, service-edit@, service-suspend@ This will allow you to indentify them until a tag can be added to the template.

Ah, there should probably be some better documentation on this. Have you tried adding the {% debug %} tag to the email notification for the Universal Module Product? It should contain the action, and if it doesn't we'll need to correct that. I'll see if I can take a deeper look at it in a little bit. Right now someone in the building must be spraying perfume in the vents because I can taste it.

I just came across this today - http://blog.idevaffiliate.com/affiliate-tracking-for-blesta-new-plugin/

Have you looked at notifications? http://docs.blesta.com/display/user/Universal+Module#UniversalModule-Notifications This would allow you to be notified, by putting in your email, or URL to a separate system when an action occurs on the service.

Your example highlights a problem I have seen myself. The "solution" thus far has been to create a separate account for the client that does not have auto debit set up for manual invoices they wish to pay by check. So, a way to tag or categorize services and manual invoices to omit them from auto debit would be very nice. Perhaps an option that can be enabled on an invoice to omit it from auto-debit. A similar option could be added to a service or recurring invoice to set this flag on invoice creation. Then, at anytime the option could be added or removed from any specific invoice.

Thanks for the kind words and glad we could help!

Great! If you want to write a how to guide that would be fantastic. I'd say, post in on the forums here in a new thread and we'll link to it from the documentation.

Thanks for the update, glad it's working now!

Hey, welcome! Does your .htaccess file exist - are you using mod_rewrite for pretty URL's? If you can see index.php in the URL anywhere, then you aren't and you may need to prepend it to the path to the order form. If you are, then I wonder if you have mod_security or anything running that may be blocking requests to that resource.

Please see CORE-1589. Open to suggestions and comments if you feel the feature should work differently than described.

Ok, pretty straight forward. So, what if we allow any staff assigned to the department to send a ticket to the trash bin, and then made a setting available to each staff so they can access and empty the trash bin? (This would probably apply to any/all tickets in the trash that belonged to departments for which they had access.) What does everyone think?

How would you suggest we implement it? I don't think we would want to allow any staff to delete tickets, maybe a staff setting for that? If you have any suggestions based on Kayako's implementation, may be worth exploring those.

We appreciate your feedback @snake and best of luck.

If it's trying to provision and that is where it's failing, check the module log under Tools > Logs > Module Log. The cron provisions paid pending services, and on average it works out to 2.5 minutes to wait.

Tell your friends! It would have no impact on the time/speed at which things are accomplished. Blesta uses its own internal scheduling, and the most frequently anything will run is 5 minutes. There are hacks to get around this, but we don't recommend it. A configurable option, or better yet the order form option "Require Agreement to Terms of Service", where you could include any other EULA's. You can select the directory from the Package, see http://docs.blesta.com/display/user/Multicraft?preview=/3833872/3899418/module-options.png "Look for JARs in the following directory", if that helps? Tyson may be more helpful on this one.

I've confirmed that it's in Blesta 3.4.2 from https://account.blesta.com/client/plugin/download_manager/client_main/download/61/blesta-3.4.2.zip /blesta/.htaccess Here's the content: ######################################################## # package: minPHP # filename: .htaccess ######################################################## <Files ~ "\.(pdt)$"> order deny,allow deny from all </Files> # Protect against Clickjacking #Header append X-Frame-Options "SAMEORIGIN" RewriteEngine on # Force HTTPS #RewriteCond %{HTTPS} !=on #RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=307,NE,L] RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ index.php RewriteCond %{REQUEST_URI} ^(.*)/install.php$ RewriteRule install.php %1/install/ [R=301,L] You can uncomment #Header append X-Frame-Options "SAMEORIGIN" to protect against click jacking, and the 2 lines under # Force HTTPS to force an https:// connection

Mike, I think the test may be flawed. nxs_cURLTest("https://account.blesta.com/", "HTTPS to Blesta", "Blesta Servers"); The third parameter is "Blesta Servers" that's the text that the test is looking for in the page to confirm it was able to fetch the page. Change this to "Client Portal", and see if it comes back with a success. Did the IP, domain, or install path change? If you have multiple web servers behind a load balancer or something, then that is likely the cause. We need the IP for each of those servers.

Download tickets won't try again until it's no longer hung or it's been 6 hours. If it's disabled though, it won't try to run. My suggestion is to enable error reporting in your config file, disable your automatic cron, and then run the cron manually. If there are errors, it would spit them out and hopefully give you more information about the issue. 1. To enable error reporting, edit /config/blesta.php and change Configure::errorReporting(0); to Configure::errorReporting(-1); 2. Disable your cron 3. Run the cron manually under Settings > System > Automation.

A lot of the VPS providers have guides on LEMP and LAMP stacks, see https://www.linode.com/docs/websites/lemp/ and https://www.linode.com/docs/websites/lamp/lamp-server-on-centos-7 For ionCube, their loader wizard works great for detailed instructions on getting ionCube loaded, but aside from that almost any modern LEMP/LAMP stack will work fine without modification. If there's a dependency missing, the Blesta installer will say so. Usually it's just a simple package manager update to install the necessary extensions via yum, apt-get, etc. But, I see what you're saying, it would be nice if we have some of our own tutorials on configuring the LAMP/LEMP stack.

That is unusual. Was there a transaction applied that you unapplied? I wonder if it may be some obscure rounding issue. Did you enter 1277.01 for the invoice, or did you use fractions or quantities that may be resulted in a number to the 3rd or 4th decimal?. If it came out to 1277.0111 or something, and the transaction was for 1277.01, it may be possible that it thinks there is a tiny amount applied to the invoice which prevented it from being re-opened. The only way to know for sure is to check the database.

Do you have a firewall? Is port 110 egress open? If it stalls, it may be timing out trying to make the connection. If you have SSH on the server, you can test by running: telnet mail.yourmailserver.com 110 If you get no reply, then it's unable to connect due to a firewall, dns, or other issue on the server. A screenshot of your configuration, with the hostname and username masked may also help us determine if anything looks out of the ordinary with your settings.

So running the command via SSH worked, but not so much within Blesta? Does your cron run as the same user as your SSH user? Unusual

Great, thanks for the update!

That's the way to go. Each patch contains all previous ones, so everyone can use the same file to patch the minor release rather than having to apply a 3.4.1 patch, and then a 3.4.2 patch in the correct order. Simpler.