Blesta Not Downloading Tickets from Mail Server

[Jason Ryan]

Hello all -

Recently we upgraded to PHP7.4 and quickly found out that their was a compatibility issue with the bundled Stripe-PHP library and have since downgraded back to PHP7.3. Upon doing so, we reinstalled the required PHP extensions for PHP7.3 but now were are having issues with Blesta downloading emails and attaching them to tickets. There are no errors and the Task is running fine.

What works:

1. Client sending 1st email to create a ticket - Ticket is created and the auto-response is delivered and received by client

2. Ticket is visible in Blesta, staff and respond to the ticket and the Staff response is sent and received by the Client

3. Client responds to the Ticket via Email - this is where it breaks down. The task is run as normal, the Email is marked as "Read" on the mail server, but the response is never downloaded and attached to the Ticket.

Like I said, there are no errors showing anywhere and we can figure out what may be causing the issue here. All emails being "sent" by Blesta work fine. We are on Blesta version 5.2

If anyone has any insight it would be greatly appreciated.

Thanks

[Jason Ryan]

For anyone else who may come across this issue, it wound up being that it was due to Error Reporting being on and Debug was set to "true". It is unclear as to why this would only cause the downloading of emails to fail and nothing else, seems counter intuitive to me, especially using debug in Wordpress is generally used to find issues, not cause them.

It is fixed now and back to normal.

[Jason Ryan]

Update:

The following error is now showing in our Blesta Logs:

[2022-01-24T16:20:14.757751+01:00] general.ERROR: Exception: Plugins is not a valid controller in /home/xxxx/xxxx/public_html/vendors/minphp/bridge/src/Lib/Dispatcher.php:113 Stack trace: #0 /home/xxxx/xxxx/public_html/index.php(21): Dispatcher::dispatch('/plugins/suppor...') #1 {main}
 
[2022-01-24T16:20:16.092067+01:00] general.ERROR: Exception: Plugins is not a valid controller in /home/xxxx/xxxx/public_html/vendors/minphp/bridge/src/Lib/Dispatcher.php:113 Stack trace: #0 /home/xxxx/xxxx/public_html/index.php(21): Dispatcher::dispatch('/plugins/suppor...') #1 {main}  

[Paul]

How are you importing tickets, using POP, IMAP, or piping? Are you saying that a new email to the department opens a ticket, but replying to the email sent to the client from a staff reply does not get imported? It's unusual that an email would be imported for a new ticket but not for a reply unless the reply is missing the required information in the subject line.

I would check that mailparse and php-imap are installed. When changing PHP versions, this is most commonly overlooked.

The errors you've included do not appear to be related.

[Jason Ryan]

1 minute ago, Paul said:

How are you importing tickets, using POP, IMAP, or piping? Are you saying that a new email to the department opens a ticket, but replying to the email sent to the client from a staff reply does not get imported? It's unusual that an email would be imported for a new ticket but not for a reply unless the reply is missing the required information in the subject line.

I would check that mailparse and php-imap are installed. When changing PHP versions, this is most commonly overlooked.

The errors you've included do not appear to be related.

@Paul

We are using IMAP and yes, double checked our installed extensions and all required extensions are installed and are the correct versions.

 

On 1/22/2022 at 5:39 PM, Jason Ryan said:

3. Client responds to the Ticket via Email - this is where it breaks down. The task is run as normal, the Email is marked as "Read" on the mail server, but the response is never downloaded and attached to the Ticket.

This is the only part that is failing. When cron runs it marks the email as "Read" on the server but it is not updating the tickets with the response.

[Paul]

5 hours ago, Jason Ryan said:

This is the only part that is failing. When cron runs it marks the email as "Read" on the server but it is not updating the tickets with the response.

If it marks it as read but doesn't import it, it is probably failing. Try disabling your cron job, and running it manually under Settings > System > Automation by clicking the button, after a 5-min wait with an email ready to be imported. At the same time, tail your logs via SSH.

tail -f /path/to/logs_blesta/*.log

Note any output and whether the email is imported when running the cron manually that way.

[Jason Ryan]

14 minutes ago, Paul said:

If it marks it as read but doesn't import it, it is probably failing. Try disabling your cron job, and running it manually under Settings > System > Automation by clicking the button, after a 5-min wait with an email ready to be imported. At the same time, tail your logs via SSH.

tail -f /path/to/logs_blesta/*.log

Note any output and whether the email is imported when running the cron manually that way.

 

Been working with our host support on this. I have disabled Cron, emailed our support channel, waited 5 minutes, ran cron manually and no import of the responses and nothing showing in logs.

I've now moved the cron job to our app panel at the host instead of EasyCron, it still runs as normal and the polling tickets task is running with no errors.

I only posted this here to see if anyone else out in the community ever came across this, didn't want to confuse things by cross-posting. Sorry @Paul