Darin

To make this work, I had to change :first-child to a:first-child

Resolved! I will explain how I fixed these email issues, but first I want to acknowledge that it was ultimately about my server’s configuration, not a problem with Blesta. I also thought I should give a lot of detail here, in case it helps anyone else experiencing these issues. For reference, I’m on a shared hosting reseller account using cPanel. Other systems are likely a bit different. Additionally, Blesta is installed in the webroot of the dev subdomain. Part 1 - Mail piping I think this is more of an issue for people who don’t fully control their server, such as shared hosting resellers, because our options for changing server defaults are limited. As Blesta’s manual states, “The Support Manager requires the MailParse PHP extension in order to parse tickets sent in through email.” Since Mailparse was not available on my server by default, I asked my provider to install Mailparse in my cPanel account and add a custom php.ini file in my dev directory, the path to which I then defined in the Blesta .htaccess file with SuPHP_ConfigPath. SuPHP_ConfigPath /home/username/public_html/dev/ This works fine for anything accessed in a browser, so when I set up a support department to use email, Blesta didn’t give me any errors. However, it doesn’t necessarily work for commands run via the command-line interface (aka CLI), such as the cron automation used for POP/IMAP retrieval, or the pipe.php script used for email piping. This all depends on your server’s PHP configuration. I had seen references to this in other posts, but I don’t recall seeing specific examples of potential solutions. Since I’d never had to deal with this particular issue in my other web applications, I dismissed it as being irrelevant to my situation. Wrong! My provider’s support team finally realized that my custom php.ini, and therefore Mailparse, wasn’t being used by the cron or pipe.php. For the cron job, I was able to rectify this by using php -c path to include the custom php.ini. New cron: /usr/local/bin/php -c /home/username/public_html/dev/myphp.ini -q /home/username/public_html/dev/index.php cron For pipe.php, it was a bit more challenging, because I continued to get a bounce error after I appended -c /home/username/public_html/dev/myphp.ini to the hashbang that cPanel had added to the beginning of the script when I set up the mail forwarder to pipe. Eventually, I found this post, which explained that PHP apparently only allows one argument in the hashbang. I finally got it to work by concatenating -q -c and path into one argument. New pipe.php hashbang: #!/usr/local/bin/php -qc/home/username/public_html/dev/myphp.ini Success with email piping! I had a working system, so I could have stopped there. But, I also wanted to figure out why POP/IMAP still wasn’t working, even though I didn’t really need it because I now had piping. Part 2 - POP/IMAP Retrieval The above cron tweak should have fixed my POP/IMAP retrieval issue, so I was surprised when Blesta still didn’t retrieve email. Again, my provider’s support team found the problem. This time, it was a mail hostname issue that appears to be due to a bug in cPanel. When I created the dev subdomain, cPanel’s mail client configuration page said to use mail.dev.mydomain.com for the incoming server. However, cPanel failed to create the corresponding DNS record, so checking mail using that hostname failed. I didn’t catch this earlier, because I was using a webmail client that accepted my username and password, but didn’t require the server/host name. All I had to do was switch Blesta's support department to use my main domain’s mail hostname (mail.mydomain.com) or the server’s generic one. Problem solved! All Blesta mail is now flowing as it should, whether incoming or outgoing, piped or retrieved via POP/IMAP.

+1 I'd like to add that I think clients should be able to renew any recurring service at any time on demand from their portal. Upon payment, the system would then send them an invoice marked paid, and the service term would be extended by the selected amount from their current renewal date. For those that need a bit more control over renewals, perhaps provide a new setting in the package to allow/disallow customers from renewing until they receive the renewal invoice. In other words, the ability to toggle each package between the current Blesta behavior and this new proposal.

I deleted support manager, then downloaded a fresh copy of 3.3 from the Blesta website and uploaded a new copy of support manager directly from it to my installation. I also deleted my mail forwarder and re-added it. cPanel automatically set permissions and added the correct hashbang to pipe.php I double checked that the path in Blesta settings was correct. Still, I get the same mail bounce error when trying to pipe, and no mail is retrieved when trying to use POP or IMAP. I do have mailparse, as per my first post. phpinfo confirms that mailparse is installed. But I will ask server support to double check mailparse, just in case there is an issue with it. I appreciate all your efforts to help me try to resolve this! I hope we find a solution.

+1

My my server support team sent me the following message: Does this mean that pipe.php is somehow including an incorrect path? I'm using Blesta 3.3 and pipe.php is unchanged, except for the required hashbang we've added at the top.

In addition to hiding the "Change this" text, it should disable the link to attempt the change. It's kind of strange right now that a client can click the link, only to be taken to a page where he can't actually change anything.

I don't mind having that invoice box tell the client what method is being used. However, I think Blesta should be smart enough to automatically hide the text about changing the invoice method, if there is only one choice or if we've disabled the client's ability to change the method.

I'm not on a VPS, just a reseller account. My cron runs fine. All other Blesta tasks appear to be happening as scheduled. I also have a handful of other cron jobs that run for another app on this account without issues. As far as I can tell, it's not a problem with cron. Piping also works in the other app on this account, so I'm thinking that it's got to be something specific to Blesta.

/usr/local/bin/php is definitely the correct path for my installation. It's the only way anything else works.

I have been unsuccessful in my attempts to get the support module to receive email. When I try piping, I get a bounce with the following error: A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: pipe to |/home/myusername/public_html/dev/index.php plugin/support_manager/ticket_pipe/index/1 generated by support@dev.mydomain.com local delivery failed When I try IMAP or POP retrieval, nothing is retrieved or marked as read/deleted. The various Blesta logs show nothing. No errors are logged on my server. Sending email from Blesta, including support responses for tickets submitted online, works fine. I’ve read every thread in these forums that I can find for email or piping, but nothing has proved a solution for me. cPanel WHM 11.42.1 (build 26) PHP 5.3.28 MySQL 5.1.67 CENTOS 5.11 I’ve made sure that my support address is correctly forwarded for piping in cPanel. I’ve tried piping using both pipe.php and index.php, with and without the hashbang. I’ve made sure that my php path (/usr/local/bin/php) is correct in the hashbang and cron. All other Blesta cron tasks are working fine. I’ve confirmed via phpinfo() that Mailparse is installed (and I didn’t get a mailparse error when I selected piping in the support department). FYI, in my situation I have to use SuPHP in the Blesta .htaccess file to include mailparse. I’ve tested that the given IMAP and POP credentials work in my mail client. I’ve tried manually running the cron. I’ve made sure that all related directory and file permissions are 755 or 777. I have another application installed on the same cPanel account as Blesta, and piping to it works perfectly. I’ve double checked that all permissions, php paths, piping settings, etc. are the same in both apps. This is driving me insane! I don’t know what to try next.

I didn't even think to check the log. The answer was right there. Log module output said "[...] Request failed validation: Name server 'ns1.mydomain.com' is not found at the registry. Please double check the nameserver and re-submit. [...]" I forgot that the OpenSRS test environment usually doesn't recognize our nameservers and recommends that we use theirs: default.opensrs.org default2.opensrs.org As soon as I changed this in my Blesta package, I was able to add the service and the test domain was successfully "registered"! Thanks! Looking forward to more of the features becoming available!

Do I still have to patch the two files if I don't use separate pricing for register/transfer/renew? I didn't do the patch and am getting an error "Invalid Domain" when I try to add the service in the admin panel. The service is not added to Blesta, but the domain appears in my OpenSRS test account (sandbox).

I'm going to try it later today!

Will do. Thanks for confirming.

I'm curious as to why you don't want to use the IP address for temporary access to both ftp and url? This has always worked great for me.

I wasn't able to make this work without manually modifying the css file. This vQmod inserts the .img-responsive class in structure.pdt, but isn't overwriting the .logo class in styles.css. According to About vQmod, "css & js files - These files are rendered at the browser level, not at the server level, so vQmod has no effect on these." Is that the case here, or do I need to hunt down a gremlin? I guess it doesn't really matter, because I can just continue to use my manually modified css file. But I'm curious.

Accounting integration or housekeeping? Or both? I'd love to see a plugin that would allow Blesta to integrate with, or export to, AccountEdge I appreciate your commitment to data integrity and I agree that it can be a selling point, especially for accountants. I can live with the data remaining in the database, but I'd really like to be able to delete (i.e. remove from the interface) invoices and such, if I know they aren't important to my audit trail. Perhaps you could deal with them the same way you deal with deleted tax rules (and maybe other stuff), where you remove them from the interface but leave them in the database. That way, I can clean house and keep the data intact in case it's required for audit purposes.

While I agree that every valid financial transaction should have an audit trail, it doesn't mean that every error or test entry should remain visible in the interface (or loiter in the database). Let's face it, we're working with quickly evolving software and every time there's a new or modified feature some of us will misunderstand how it works and make a mistake, or maybe just test it to see how it works. These things don't need to be indelibly recorded in our record books. If there's one thing I've learned from reading these forums, every jurisdiction in the world has different accounting rules and record keeping requirements. Blesta can't be expected to police users for every possible scenario. Besides, Blesta isn't accounting software; it doesn't do all of the things necessary to keep your financial records in order. Blesta is online billing software with resource management. Personally, I don't want to be restricted from doing some basic housekeeping simply because the rules/preferences are different for someone else. I want to have a choice about what information I delete (unless it breaks Blesta) and I'll live with the consequences.

I like this concept. I wish Blesta would allow customers to renew domains and other recurring items at any time, rather than waiting for a renewal invoice. To me, it's especially important for domains. I'd like to be able to send 90/60/30 day domain expiry/renewal reminders (like the big guys do) and actually let the customer renew at that time. Currently, I have to suppress any OpenSRS reminder emails to customers, because the customer won't be able to renew until my billing system issues the invoice only a few days prior to expiry. This is good news! OpenSRS/Tucows is the only registrar I resell, so this module is necessary before I can fully commit to Blesta.

I like the idea of an one-click option to create a new credit note (aka credit invoice) for the same amount as the original invoice, which essentially reverses the original invoice for accounting purposes. However, I don't believe this should be the default behavior for voiding/canceling an invoice, as I'm in a jurisdiction that will allow me to simply mark the invoice as void or canceled, unless the customer has already made a payment on it. This is okay, as long as it only shows the payment type(s) on paid invoices. I don't want unpaid invoices to show the default payment type, because customers may choose another type at time of payment.

In Canada, this special rounding only applies to cash transactions, because Canada eliminated the penny (0.01) in 2013, leaving the nickel (0.05) as the lowest currency denomination in production. Additionally, the rounding only applies on the final total, not on line items or tax calculations. According to the Royal Canadian Mint, "only cash transactions require rounding. Cheques and transactions using electronic payments—debit, credit and payments cards—do not need to be rounded, because they can be settled electronically to the exact amount." More info can be found here http://www.mint.ca/store/mint/about-the-mint/phasing-out-the-penny-6900002

I like Cody's suggestion to allow draft invoices to be manually sent from the client profile. Perhaps they can be flagged in some way, such as a pop-up asking you to confirm that you want to send a draft invoice. Personally, I don't need a whole quote system, as I only do this once every year or two. Sending a draft would work fine for me. Call it a quote, if you'd like, but the intent is the same, which is to mutually agree upon a final price. Once agreed, the draft is converted into a regular invoice for payment.

Found it! In components/email/email.php at line 90 private function newMessage() { $this->message = Swift_Message::newInstance(); $this->message->setMaxLineLength($this->max_line_length); $this->message->setCharset($this->charset); } add this line before the closing curly bracket: $this->message->setReturnPath('bounces@example.com'); so that you end up with this: private function newMessage() { $this->message = Swift_Message::newInstance(); $this->message->setMaxLineLength($this->max_line_length); $this->message->setCharset($this->charset); $this->message->setReturnPath('bounces@example.com'); } It will add your custom return-path to outgoing mail. It would be nice to see this as an option for each company in Settings.

If you're a reseller of shared hosting, it's possible that your provider has disabled your ability to sell reseller accounts.