Hi All,
We are trying to understand exactly what Jira looks at when an email is received to determine either (1) there is not an existing Issue, so create a new Issue or (2) this email pertains to an existing Issue, so add the email to the existing email. Note, we are using Jira's email-to-case functionality, so emails to our help desk get forwarded to Jira.
We have found that adding the project key (e.g. ITSHELP-12345) to the email subject will correctly link to the existing case most of the time. However, we are now running into issues where a customer sends a new email/new thread to our inbox with the same subject of an old Issue (with no sign of an old key) and Jira adds the email to the old issue instead of creating a new one.
If we were to know exactly what Jira looks for on the email to perform the link, we can correctly identify why this is occurring.
Any ideas?
Thanks,
Sam
In general, it is based off the subject of the email containing the specific Issue key in question. However, let me preface this response by saying that there are potentially a lot of difference between Jira Core/Software projects versus Jira Service Desk (JSD) projects when it comes to handling inbound mail. That is because Service Desk has completely different code in use to handle mail. So the behavior could be different between the project types is the point I'm trying to make here to start.
In most cases where I see people confused about this in regards to Service Desk creating new requests when they want the response included to an existing one (opposite problem from your issue here, but related).
I did some more testing here in my Jira 7.12.3/JSD 3.15.3. I found that end users that replied via email with the same subject title (but editing out the actual issue key) would still have that message added back to the original post.
But when I created a new email, with the same subject line (but without an issue key) as an existing request, from the same user email account, it actually created a new request. This caused me to dig deeper into the differences of the messages sent to Jira itself.
So what I suspect is happening here, is that each message Jira is sending out to a user has a Message-ID that you can find in the email headers. It looks like this:
Message-ID: <JIRA.71004.1517739365000.9.1547799482107@Atlassian.JIRA>
When you click reply in your email client to a notification JSD sent, the message you as the client send in return has a header called "In-Reply-To:" that contains a unique identifier like this:
In-Reply-To: <JIRA.71004.1517739365000.9.1547799482107@Atlassian.JIRA>
When Service Desk sees this header it matches it against known messages sent already from this Jira site. As such, it doesn't have to then match the subject line at all for that message and can just presume that this message is a reply to an existing issue and add it there. I'm betting that in your case, the end user's message that was sent to Jira has this header and that's why it's getting included to the old issue rather than creating a new one.
Excellent input Andrew! I suspected the headers were being used as they are more reliable than text in the subject.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
A sidenote: I have additionally tested the "In-Reply-To"-behavior on JSM Cloud (team managed) and found that it works the same way:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Sam Fikaris, that is interesting info. It has always been my understanding that it was all based off the Issue Key in the subject but I have never done any testing to prove/disprove. I think I will do a bit of testing and I will reach out to other champions/atlassians to get more info or ask them to chime in here.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.