| Description | Column "filename" in "mantis_bug_file_table" has, as some other columns in this table, a limit of 250 characters. An email containing an attachment with a file name longer than this will caused the following error:
Database query failed. Error received from database was #1406: Data too long for column 'filename' at row 1 for the query: INSERT INTO mantis_bug_file_table
( bug_id, title, description, diskfile, filename, folder, filesize, file_type, date_added, user_id, bugnote_id, content )
VALUES ( ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ? ).
The result of this is the following situation:
The ticket has been created successfully.
The attachment has not been added to the ticket.
The email will stay on the mail server.
And this results in an endless loop: the next time EmailReport is started, the email is fetched again, a new ticket is created again and the attachment causes the error again. |
|---|
| Steps To Reproduce | Create a file with more than 250 characters, e.g. the following one, which has 255 characters:
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901.txt
Attach the file to an email, send it to the email address configured in the EmailReporting plugin and the error will occur.
A real-life use-case where a too long file name causes this error is this one:
I receive an email from someone with a subject containing more than 250 characters.
I forward the email to the email address used for the EmailReporting plugin and my email client attaches the contents of the original email as an attachment using the filename "[VERY LONG SUBJECT].eml".
EmailReporting fetches the email, creates the ticket, tries to import this attachment and results in the error mentioned above. |
|---|
| Additional Information | The Mantis core also doesn't deal with this error yet, which I reported as 0029144.
Two ideas for a solution:
1.
Deal with this error only:
Truncate the file names (probably using a function of the mantis API if there is one) and make the truncated file name unique across all attachments of the email that's being parsed.
2.
Prevent loops like this in general:
Make the whole email import "transactional". Either by importing the whole email in one database transaction, which, i guess, may not be possible if multiple Mantis API calls are involved, or delete everything that has been created by the imported email already in case of an error. |
|---|
