Emailed replies create duplicate issues after they've been moved to another project

[Will Davis]

Hello,
I have a scenario where my organization has a Service Project where initial triage is performed and issues are moved other service projects. For example, all emailed requests come into our "IT GSD" service project and may be moved to "Facilities & Engineering".

I'm experiencing an issue where the following scenario occurs

• Customer A submits a request via email and CC's some additional team members (Customer B, Customer C, etc)
• Jira creates an issue and sends a notification to the reporter stating a new issue has been created, and adds the CC'd people as Request Participants
• Agent A moves the newly created issue to another service project
• Customer A, Customer B, or Customer C reply to the original email thread that Customer A started (not the Jira notification email)
• New issues are created in the original service project (IT GSD) and the original moved issue in the "Facilities & Engineering" project is not updated with the content of the email

We've done many of the recommended steps, such as ensuring the two projects have the appropriate customer permissions to add comments. It appears that this might be an issue with the mail handler not understanding the "in-reply-to" header correctly, or that we may not understand it ourselves.

As a result, we're missing many important updates to tickets. An example series of tickets is:
1 - https://companyname.atlassian.net/browse/FE-196
2 - https://companyname.atlassian.net/browse/GSD-865
3 - https://companyname.atlassian.net/browse/GSD-866

In the above example, ticket #FE-196 originally came in via email to the IT GSD project. We moved it to the Facilities & Engineering project, and then tickets #GSD-865 and #GSD-866 were created when Customers replied back to the email thread started initially.

I should note that if we don't move the issue to another project, any of the customers in the example above can reply to the email thread and a comment is added to the existing issue.  It does not create a new issue.

The only time a new issue is created is when we've moved the issue to a new service project.

Thank you in advance for your help!

[Mohanraj Thangamuthu]

Hello, Good day. I believe this is JSM project. Incoming coming email will check the issuekey present on the email subject and add comment to existing issue. In your case the original issue is moved to different project (meaning issue key gets changed), so issuekey on new project and issuekey on the email subject does not match resulting with new issue. 

What is the reason you are moving the issue to new project, can this be cloned ?

[Will Davis]

Hello Mohanraj,

Yes, this is a JSM project.  You're correct in your response.  Additionally, when the email handler doesn't find the issue key, it'll fall back to the "in-reply-to" header from the email.  Atlassian support explained to me there's a 3-year old bug affecting my exact scenario: [JSDCLOUD-9118] Replying to a request's notification after that request has been moved will create a new request instead - Create and track feature requests for Atlassian products.

Unfortunately, it doesn't look like I'll be able to get that resolved any time soon.  Since it's 3 years old, low priority, and hasn't been assigned yet, the only solution I can come up with is to bring these groups into a single service project and create queues, add additional issue security, etc.  I'll also have to have a custom field for setting the "Team" so I can update all the queues to filter out irrelevant work.  This will lead to unnecessary clutter and complexity for everyone, including our customers.  The customer portal won't have a tile for each group with Request Types organized within.  Pretty poor experience, to be honest.

As far as the use case: We liked the idea of having multiple service departments (Laboratory Engineering, IT Support, Facilities, Architecture, etc) with their own projects and their own tiles on the customer portal.  It's very convenient because each of these projects can have their own queues, their own add-in configurations, customers, etc.  It would allow a "triage" team to review all incoming tickets for these groups, take any Tier 1 and Tier 2 tickets and assign it to themselves, and immediately escalate/move anything else to the appropriate groups.  Then, project-level automation can kick in and provide value for each of these groups.

From a design standpoint, multiple service projects works well for us and a single project does not nearly as well.  We can hack it together in a single project, but it's not ideal.

You mentioned cloning - Unfortunately I don't think that'll solve the issue we're having.  Most customers aren't experienced with Jira so they'll likely get a new ticket notification and continue to email the original thread.  We can educate the customers, but the issue will still persist and create friction between everyone using the product.

Thanks for your response!