Cannot create new ticket via email

Katanshin

I've been really pleased with osTicket, however the one thing that does not work as intended is the creation of tickets from an email to support@blah.com for example.

Looking at the imap folder concerned, I can see the cron is reading emails just fine, and likewise replies to update notifications sent to the ticket originator's email are logged correctly in the ticket thread - provided that ticket was started via the web or staff of course

I've enabled error logging but receive no error messages and am currently trawling through the code to see if I can trace out what's going wrong, but if anyone knows anything about this weird issue please let me know.

Config-wise I have one email address set up, an imapi connection that sends and receives just fine aside from this issue, and am fetching at a 1 minute interval for testing purposes using an autocron (my host restricts me to setting crons via an interface that restricts them to an hour of the day, so I'd have to set up 24 of them to cover an hourly cron, if that makes sense).

In the imapi folder, I can see the email that was sent has been "read", however no ticket was created and there's nothing in the syslog etc.

Keen to get this awesome piece of kit running right!

Katanshin

Alright, I figured this out, so in case this helps anyone...

I'd previously (in fact it was the first thing I'd done since downloading RC5) followed another posts directions to create an additional field for my tickets called "company".

My issue was being caused by the silent failure of the ticket creation function, which failed because there was no "company" variable being passed to it when email was being processed.

adding a dummy var to class.mailfetch.php at around line 230-ish resulted in proper operation.

So to summarise, any additional fields entered must also be catered for in this file, so email is properly routed.

In my example, because I want to capture the company a user is emailling from I've used something like:

$fromco = explode("@",$var);

$var=$fromco;

Resulting in my company field being populated with "microsoft.com".

Hey I'm a web developer, domain name is good enough for now at 2!

I sincerely hope this saves 6 hours of someone elses life!

PRedmond

You've saved 6 hours of my life!! Thanks!! ;)

pRtkL xLr8r

Wow, thanks, totally helped me with my issue. I had created a captcha system to work with the tickets. The new fields (as well as an unauthed captcha) was causing it to fail it seems. What sucks is that there is absolutely no errors being thrown anywhere to point you in the right direction. I never thought the internal ticket system would actually use the tickets shown to users. I got around it by using a define from the cron.php script, and then if_defined on any of the code using the captcha stuff, so that it gets bypassed when run from the command line.

robayer

Nice work

You saved me some serious time as well.

Thanks.

Khris

I'm having a similar issue, however this fix did not resolve the issue for me. I've added three new fields into the os_ticket table which I've also added here in the class.mailfetch.php file.

If I log in through my webmail client, I can see that the email changes from unread to read, but it does not get imported into osTicket.

Anyone else have any other suggestions?

Khris

Got it. Any fields which you make mandatory, must also have a variable entered into class.mailfetch.php.

I made the telephone number required, but didn't originally include this variable in the class file and so it still failed. As soon as I added it, everything works perfectly!

xurizaemon

Subject length may also cause similar behaviour

Note also that as of 1.6, emails with a subject longer than 64 characters will NOT appear in the queue. There is an open ticket in the bug tracker which touches on this. I expect that it also affects other fields, eg overlong email addresses etc.

ntozier

Just wanted to thank you guys for taking the time to post your fix for this issue. It helped me narrow down and fix this problem. I had assumed that it was Exchange 2007 Ent just not playing well with others. I didn't even think that the changes I have made would have caused this.

Thanks again!