1.9.11 closed ticket doesn't reopen although it is configured to reopen

mfelber

We have encountered one ticket (maybe there are more) that has imported a new message and still was closed after the import of the new message.We have configured this instance that tickets should reopen in this situation (ticket status list).I have tested the reopen mechanism and normally the tickets reopen when a new message arrived. This seems to be a rare case.I could not reproduce this exception.The imported message was not a autoresponder message and no mailing list was used.It was a message that was forwarded manually via an email client to the email address of osticket.Is there a way to investigate why this happened? Or a way to prevent this (without disallowing reopen tickets).This is not so good because you will not recognize that a ticket has a new (maybe important) content received.It was an accident that we found out that new content was received in this ticket.This is the system environment:osticket 1.9.11Debian Squeeze 2.6.18Web Server Software Apache 2.2.16PHP Version 5.5.30 (mod_php)MySQL Version 5.5.44This is the header of the imported message:Return-path: <address of the person who send the mail>Delivery-date: Tue, 22 Dec 2015 09 +0100Received: from mi010.mc1.hosteurope.de ()by vwp6199.webpack.hosteurope.de running ExIM with esmtps (TLS1.0)id 1aBIQh-0001qh-MY; Tue, 22 Dec 2015 09 +0100Received: from mailbe6-s.mpsa.com ()by mx0.webpack.hosteurope.de (mi010.mc1.hosteurope.de) with esmtps (TLSv1.2-SHA)id 1aBIQg-0002yb-4xfor osticket-mail-address; Tue, 22 Dec 2015 09 +0100Received: from pps.filterd (bedmm601.inetpsa.com )by bedmm601.inetpsa.com (8.15.0.59/8.15.0.59) with SMTP id tBM8YP2S010470for <osticket-mail-address>; Tue, 22 Dec 2015 09 +0100Received: from ylav6540.inetpsa.com ()by bedmm601.inetpsa.com with ESMTP id 1yvyq74qjk-1(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT)for <osticket-mail-address>; Tue, 22 Dec 2015 09 +0100Received: from YLAV2300.inetpsa.com () by YLAV6540.inetpsa.com () with mapi id 14.03.0235.001; Tue, 22 Dec 2015 09 +0100From: address of the person who send the mailTo: osticket-mail-addressSubject: subject textThread-Topic: thread topic textThread-Index: AdE8ECS3cqelSPtBTaCFjT1hXcGDJQAABaeQACB0o/AAAFWIIA==Date: Tue, 22 Dec 2015 08 +0000Message-ID: <DE9A369C0A2E7E4B9374A165C6B5D75F1DB188AF@YLAV2300.INETPSA.com>References: <A4062B7DE63B894BA75205F4DDBC7BBF2C3DB175@YLAV2320.INETPSA.com> <52B4B80E368A7F4195A53193D2E0E7E147FF377E@YLAV4450.INETPSA.com>In-Reply-To: <52B4B80E368A7F4195A53193D2E0E7E147FF377E@YLAV4450.INETPSA.com>Accept-Language: fr-FR, en-USContent-Language: de-DEX-MS-Has-Attach: yesX-MS-TNEF-Correlator: x-originating-ip: Content-Type: multipart/mixed;boundary="_012_DE9A369C0A2E7E4B9374A165C6B5D75F1DB188AFYLAV2300INETPSA_"MIME-Version: 1.0X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2015-12-22_07:,, signatures=0X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310008 definitions=main-1512220162X-HE-Spam-Level: /X-HE-Spam-Score: -0.6X-HE-Spam-Report: Content analysis details: (-0.6 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust 0.1 HTML_MESSAGE BODY: HTML included in messageX-HE-SPF: PASSEDEnvelope-to: osticket-mail-address--_012_DE9A369C0A2E7E4B9374A165C6B5D75F1DB188AFYLAV2300INETPSA_Content-Type: multipart/related;boundary="_011_DE9A369C0A2E7E4B9374A165C6B5D75F1DB188AFYLAV2300INETPSA_";type="multipart/alternative"--_011_DE9A369C0A2E7E4B9374A165C6B5D75F1DB188AFYLAV2300INETPSA_Content-Type: multipart/alternative;boundary="_000_DE9A369C0A2E7E4B9374A165C6B5D75F1DB188AFYLAV2300INETPSA_"--_000_DE9A369C0A2E7E4B9374A165C6B5D75F1DB188AFYLAV2300INETPSA_Content-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printable

ntozier

"It was a message that was forwarded manually via an email client to the email address of osticket.Is there a way to investigate why this happened? Or a way to prevent this (without disallowing reopen tickets)."It was a forward. If you want it to thread properly it has to come from a collaborator, the ticket owner, or an assigned agent.You can literally cheat this by dragging and dropping the email from mailbox a to mailbox b. (I do this in Outlook all the time with a quick action). A forward has a completely different message-id

mfelber

Ok, I think I understand. The correct message id is always neccessary in order to get the ticket reopened, right?But I'm still a little bit confused how the import mechanism works. I try to explain it:the person A who has forwarded the mail was not involved in this ticket but osticket imported it to the correct ticket. That let me thought first the correct message id is in this mail. The ticket owner sent originally this mail to person A and person A forwarded it to osticket.However I don't find a message id in this mail that corresponds to a ticket.It looks like osticket has used the subject and the appearance of the ticket owner to match the mail to the correct ticket.Works the import mechanism this way when no corresponding message id was found in the mail?Thanks for the cheat..