OsTicket duplicate tickets

glebcha commented 11 years ago

Most time tickets are duplicating. This bug was mentioned several times on official forums and somebody thought fetching was the reason. Please comment on this issue.

protich commented 11 years ago

This is not a bug.

osTicket tries to sniff out duplicate tickets based on message ID, but emails might be refetched on ticket delete - depending on how your mail server handles "read" emails. POP3 and some IMAP implementations, for example, do not track read/unread flags.

That said, you have 2 options.

Delete fetched emails
Move fetched emails to a different folder/label (feature added to v1.7)

clonemeagain commented 10 years ago

We've suddenly hit this issue, started on Friday, now we have loads of duplicates. Its never affected us before, and we haven't changed the code in ages.. (still using 1.7.2).

Checked, the message_id's are unique, however the email_mid's are duplicates for the offending messages. Including all headers (obviously). Would it be wrong to simply mark that email_mid field as "Unique" in the table? Get the database to force uniqueness on it too?

Something must be wrong with the class.thread.php function:

    function lookupByEmailHeaders($mailinfo, &$seen=false) {
        // Search for messages using the References header, then the
        // in-reply-to header
        $search = 'SELECT message_id, email_mid FROM '.TICKET_EMAIL_INFO_TABLE
               . ' WHERE email_mid=%s ORDER BY message_id DESC';

        if (list($id, $mid) = db_fetch_row(db_query(
                      sprintf($search, db_input($mailinfo['mid']))))) {
            $seen = true;
            return ThreadEntry::lookup($id);
        }

If you were to get more than one value, which one is first? The DESC says the "latest one", not the original one.. There really only should ever BE one.. The index is confusing, it's "keyname" is "message_id", however, its actual column is "email_mid", and isn't unique..

SQL query: SELECT message_id, email_mid FROMot_ticket_email_infoWHERE email_mid = '<9803f9fc2a59296f@945b6b518f221052>' ORDER BY message_id DESC

message_id email_mid 55622 9803f9fc2a59296f@945b6b518f221052 55621 9803f9fc2a59296f@945b6b518f221052 55620 9803f9fc2a59296f@945b6b518f221052 55619 9803f9fc2a59296f@945b6b518f221052

DESC says it is using the message_id index.. I don't know enough about indexes or tables to determine if changing it to unique in production would fix it or break it further.. All those id's match tickets:

SELECT id,pid,ticket_id,staff_id,thread_type,created,updated FROMot_ticket_threadWHERE id IN (55619,55620,55621,55622)

id pid ticket_id staff_id thread_type created updated 55619 0 20208 0 M 2014-03-31 00:52:15 0000-00-00 00:00:00 55620 0 20207 0 M 2014-03-31 00:52:15 0000-00-00 00:00:00 55621 0 20209 0 M 2014-03-31 00:52:16 0000-00-00 00:00:00 55622 0 20210 0 M 2014-03-31 00:52:16 0000-00-00 00:00:00

I should mention that we use gmail/imap with the "move to folder/label" option, and it has worked fine for the previous 40k messages.

osTicket / osTicket-1.7

OsTicket duplicate tickets #462