dait Posted October 5, 2013 Report Posted October 5, 2013 Hello, Describe the issue you're experiencing. Support Management system is connected to IMAP account and works quite well with Blesta when the client or staff uses Gmail web interface for the communication. Works quite well means that Blesta is able to download new mails using IMAP and the new replies to the existing tickets. However, when SeaMonkey email client is used (http://www.seamonkey-project.org/ - using Firefox core for browser and Thunderbird core for email client) for client or staff replies, the replies are not parsed properly and do not appear properly under the relevant opened tickets in Blesta. However, Blesta does recognize those mails and does include them to its database, but does not show them under any open tickets. Instead, Blesta probably creates new partial tickets, but does not show them. The result is that we have some open tickets in Blesta but no ticket is seen there - please see the screenshot below. Although it might be the case that SeaMonkey email client is not used by many, it is built on the sources of Thunderbird, which is a well known client and probably used by many. Although not tested in Thunderbird, it is not unlikely that it would suffer too. Hence I think this might be a serious problem in Support Management plugin. Provide detailed steps necessary to reproduce the issue. I believe it should be enough to install SeaMonkey and set up an email account in it. Then use SeaMonkey to reply to a ticket, either as staff or client. List any generated errors. (The "Oh Noes" error pages are very helpful.) N/A Include the URL the error occurred on, relative to the installation path, ie "/admin/login". The screenshot below is from /admin/plugin/support_manager/admin_tickets/ Attach screenshots. Note that the number of Open tickets is 6, but "There are currently no tickets with this status." The number of Closed tickets is 5 and this is correct as well as zero numbers of Awaiting Reply and In Progress tickets. Include your configuration settings, i.e. OS, version of Blesta, PHP & MySQL. Client: SeaMonkey 2.21 Windows Vista SP2 Server: Windows Server 2008 R2 Datacenter Blesta 3.0.3 PHP Version 5.4.10 MySQL 5.5.29 Thank you!
dait Posted October 5, 2013 Author Report Posted October 5, 2013 We've got only one department and the answer is yes. As mentioned in my report it does not matter if you are trying as a stuff member or as a client. Emails that come from SeaMonkey email client are not handled. If I use www interface of mail email provider, it does work.
dait Posted October 5, 2013 Author Report Posted October 5, 2013 We've got only one department and the answer is yes. As mentioned in my report it does not matter if you are trying as a stuff member or as a client. Emails that come from SeaMonkey email client are not handled. If I use www interface of mail email provider, it does work. * of my email provider
Tyson Posted October 5, 2013 Report Posted October 5, 2013 Have you taken a look at this thread? It may be that the ticket exists, but the ticket reply (that contains the email) does not, possibly due to an error experienced when Blesta received the email. If you can confirm whether that's the case, it'd be useful for us in pursuing the issue further. FYI, I primarily use Thunderbird, and emails are handled just fine.
dait Posted October 5, 2013 Author Report Posted October 5, 2013 Have you taken a look at this thread? It may be that the ticket exists, but the ticket reply (that contains the email) does not, possibly due to an error experienced when Blesta received the email. If you can confirm whether that's the case, it'd be useful for us in pursuing the issue further. FYI, I primarily use Thunderbird, and emails are handled just fine. The description of the problem looks similar, so it might be that case. But unlike the linked issue, I think I am able to reproduce it on demand. Could you please tell me what to do step by step to give you the information you need?
dait Posted October 6, 2013 Author Report Posted October 6, 2013 I have checked that the problem is somehow specific to our installation since your support system - https://account.blesta.com/client/ - did actually handled SeaMonkey reply well (except for the minor relict mentioned in the other issue). So, I am waiting for your instructions what to do next to help you find the core of this problem.
dait Posted October 6, 2013 Author Report Posted October 6, 2013 I should also mention that these "ghost tickets" do appear in both - the stuff and the client list of open tickets - i.e. if it is the client who sends this email using SeaMonkey, a new ghost ticket appears in stuff's list of tickets. If it is the stuff member who uses SeaMonkey to reply, a new ghost ticket appears in the client's list of open tickets. And yes, I am able to reproduce it over and over again.
dait Posted October 8, 2013 Author Report Posted October 8, 2013 So, anyone interested in fixing this Ghost tickets issue?
dait Posted October 8, 2013 Author Report Posted October 8, 2013 OK, so let's fix another bug in Blesta ourselves .. yeah \*/ In this case the problem goes as follows. When email arrives cron task detects that and ticket manager calls processTicketFromEmail. Email is being parsed in plugins\support_manager\components\email_parser\email_parser.php. In here, things fail. Let's see how for example getSubject fails: public function getSubject(MimeMailParser $email) { $charset = $this->getCharset($email->getHeader('content-type')); if (!$charset) $charset = "UTF-8"; $subject = $email->getHeader('subject'); // Convert to UTF-8 if needed if (strtoupper($charset) != "UTF-8") $subject = $this->convertEncoding($subject, $charset, "UTF-8"); return $subject; } Somehow the value in $charset is "UTF-8", this may seem OK, but the code really expect it to be just UTF-8, not "UTF-8". I really mean that if we wanted to put that value in $charset we would have to call $charset='"UTF-8"'; So obviously "UTF-8" != '"UTF-"' and so we call convertEncoding which fails. But it fails softly so that the result is empty string. Now, why on Earth do we have "UTF-8" in $charset instead of just UTF-8? The core of all evil is this piece of code in email_parser.php: public function getCharset($content_type) { $charset = null; preg_match("/charset=(.*);|charset=(.*)$/i", $content_type, $matches); if (isset($matches[1]) && $matches[1] != "") $charset = trim($matches[1]); elseif (isset($matches[2]) && $matches[2] != "") $charset = trim($matches[2]); return $charset; } In our case the relevant part of the email (sent by SeaMonkey) is this: Content-Type: text/plain; charset = "UTF-8" It should be noted that parsing code should recognize all following formats charset = something charset=something charset= something charset =something charset = "something" charset="something" charset ="something" charset= "something" charset = 'something' charset='something' charset ='something' charset= 'something' and possibly also things like charset=' something ' charset=" something " I believe that that code is able to parse only the first four samples, which means that lots of emails sent to Blesta goes into trash (or become "Ghost tickets" if you like). Either there should be better "trimming" part which would remove both double and single quotes if they are present within the value of charset, OR there should be more complex regular expression that would make this automatically. For a quick test that this function is the cause of the problem I have used the second parameter of trim() function and included ' and " (besides the default) characters in it. Tested with a couple of emails sent from SeaMonkey, all of them appeared correctly in the ticket system.
Cody Posted October 9, 2013 Report Posted October 9, 2013 Thanks for the report. Added CORE-815 for version 3.0.5.
Cody Posted October 9, 2013 Report Posted October 9, 2013 CORE-815. Fixed in 3.0.5. To patch yourself, update /plugins/support_manager/components/email_parser/email_parser.php line 31 From: return $charset; To: return trim($charset, "\"\'");
Recommended Posts