Hi All,

For the first time today I'm seeing some strange behaviour in the Inbox processing in OSticket.

My configuration is IMAP to an on premises exchange server, configured to poll the Inbox and move processed messages to a Folder called "Imported". All has worked well until today, with emails being processed and moved to the Imported folder with the Inbox empty after each polling.

However today I am seeing very weird problems.

There are a number of emails in the OSTicket Inbox which are simply not being processed - no ticket is created for them and they remain in the inbox.

However I'm also seeing about a dozen emails that are sitting in the Inbox, ARE importing correctly as tickets, however there are dozens of copies of the same message sitting in the Imported folder as well.

Almost as if it is copying the message to imported instead of moving it, then next time it polls (I poll every minute) it recognises the email in the inbox as an already processed message and attempts to move it again but only succceds in copying it.

There are no errors in the OSTicket log.

Has anyone had problems like this with IMAP polling before and messages randomly not importing or importing but not moving folder correctly ?

I think I've figured out the problem, or at least some of it!

It looks like it is related to the following issue which itself was a result of switching from LDAP to LDAP+HTTP Passthrough authentication:

https://forum.osticket.com/d/101321-http-500-error-for-one-specific-user

It seems the inciting incident was a user who had previously authenticated using LDAP (prior to me switching to HTTP Passthrough) attempting to email the ticket system for the first time. It seems the duplicate entry in the osticket_user_account table not only causes an HTTP 500 crash when the user tries to use the web interface, it causes a crash during email importing!

[30-Aug-2022 12:45:30 UTC] PHP Fatal error:  Uncaught ObjectNotUnique: One object was expected; however multiple objects in the database matched the query. In fact, there are 2 matching objects. in E:\inetpub\osticket\include\class.orm.php:1364
Stack trace:
#0 E:\inetpub\osticket\include\class.orm.php(606): QuerySet->one()
#1 E:\inetpub\osticket\include\class.user.php(681): VerySimpleModel::lookup()
#2 E:\inetpub\osticket\include\class.ticket.php(3990): User::lookupByEmail()
#3 E:\inetpub\osticket\include\class.ticket.php(4179): Ticket::filterTicketData()
#4 E:\inetpub\osticket\include\class.mailfetch.php(905): Ticket::create()
#5 E:\inetpub\osticket\include\class.mailfetch.php(955): MailFetcher->createTicket()
#6 E:\inetpub\osticket\include\class.mailfetch.php(1035): MailFetcher->fetchEmails()
#7 E:\inetpub\osticket\include\class.cron.php(25): MailFetcher::run()
#8 E:\inetpub\osticket\include\class.cron.php(111): Cron::MailFetcher()
#9 E:\inetpub\osticket\include\api.cron.php(19): Cron::run()
#10 E:\inetpub\osticket\include\api.cron.php(40): CronApiController->run()
#11 E:\inetpub\osticket\api\cron.php(23): LocalCronApiController::call()
#12 {main}
  thrown in E:\inetpub\osticket\include\class.orm.php on line 1364

This is why email tickets for this user were not being imported but were sitting in the inbox. As soon as I deleted the ldap.client row for this user their emails sitting in the inbox were imported. Although I can't prove it I suspect this is also what caused the move after import process to fail for other tickets - probably the script was crashing before it got a chance to delete each message from the inbox.

The moral of the story is - if you switch from LDAP authentication to HTTP passthrough on an existing installation you must delete all the rows in ost_user_account table with a backend of ldap.client or you will have trouble not just with users using the web interface, but also with them emailing the ticket system!

Write a Reply...