Email message body fix & additional features

[skz]

I am having a rather odd issue and I am unable to identify the culprit. I have searched the forums but cannot find a similar issue nor a solution.

Version: 1.6 ST
Enable POP/IMAP email fetch: enabled
Enable email piping: disabled
New Ticket Alert: Enabled
recipient set to: Admin and Dept Manager

cron.php is set up to run every 5 minutes. On completion of the script the email batch is collected and always creates a ticket. Frequently when a support issue comes through the email the message body will come through properly in the Alert email that is sent out to the Admin/Dep Manager but when you go into the ticket the message body is either completely blank or missing half of the msg.

I am able to replicate the issue and have tried changing database type to "Long Text" just in case and am still producing he same issue. I am also able to replicate this issue on 1.7 DPR4.

Other questions:
External Help: We have external "help" that handle support issues who will NEVER have login access to the system that internal staff will need to forward onto other external parties to resolve. Once the issue is resolved the external party will respond via email to the ticket and the internal staff will notify the original person having the support issue.

Email ticket support: Is there a way to open, close, update and delete a ticket via email rather than logging into the system? For example a CSR takes an incoming call and creates a ticket the dept manager then gets a notification. In the meantime the dept manager gets a separate issue via standard email, resolves the issue and would like to add their updated correspondence and resolve the original ticket number that the CSR created.

Any thoughts or direction would be helpful.

[ntozier]

Are the responses really long? What version of MySQL are you using and are you running it in strict mode?

The reason that I ask:
"If strict SQL mode is not enabled and you assign a value to a BLOB or TEXT column that exceeds the column's maximum length, the value is truncated to fit and a warning is generated." (source)

I do not believe that I have ever seen the behavior that you are describing except when encountering certain characters. Which is addressed in the following thread: http://osticket.com/forums/showthread.php?t=1162

[skz]

mysql version 5.0.95

I am not sure what the definition of a long email is but I do not feel that the emails are necessarily long but I suppose the answer to that is very subjective. What constitutes a long email? One of the emails I am able to replicate this over and over with is 30 rows and 73 characters long per line and it is a standard txt email.

Also these are mostly happening on only the new ticket creation not the response. The responses seem to work fine and the initial "admin ticket alert" includes the entire email properly.

I do not see any random characters producing this issue but I am able to replicate this in 1.7pr4 and 1.6st.

[skz]

Here is another example of one of the emails that is populating incorrect in the alert to admin:

Good afternoon,
Can you please help me?
Thanks!�� xxx
�
�

Thanks!! Again you are great.
Joan
�

The actual data only shows the following:

Good afternoon,
Can you please help me?
Thanks! xxx

[skz]

Does anyone have any thoughts or ideas on how to fix this?

[ntozier]

Based on the odd � characters in your post I would recommend that you take a look at the post about german umlauts here on the forums. Even though chances are your not using German, the fix in the thread in my opinion helps with a number of character set related problems. I'm betting this is actually a character set of the email issue when OST parses it. you can find the post here:

http://osticket.com/forums/showthrea...ghlight=umlaut

[sknoops]

Hello,

did anybody found a solution, because we have the exact same problem here. Strange thing is, it worked for a few weeks, and now we only get the first line of the mails in the ticket but not in the email notification. If I look in the database, it is only the first line ...

No strange characters used, just plain English text.

Anybody any idea?

Thanks,
Steffen