Duplicate tickets created when email sent to 2 different project mapped emails in JEMH

Is it possible to create 2 tickets in different jira queues by sending one email to 2 different project mapped emails in JEMH?

Here's our use case - HR would like to send 1 email to both IT and Facilities in order to open a ticket in each of their queues. Both are aliases for the same mailbox, but are mapped to 2 different jira projects in JEMH (matched against addressee). When this happens, 2 duplicate tickets are created in the Facilities jira queue, rather than one in each. Is this expected behavior?

Thanks!

1 answer

1 accepted

0 votes
Accepted answer

Hi,

It is expected behaviour, as, the email addressees are processed sequentially and matched against defined catchemail and jemhAddresseeRegexps, sequentially. For a given message, and profile, the output will be repeatable, regardless of the number of additional matches found. But, I'll come back this point at the end

There are two ways to approach this currently, see which best fits your needs;

1. Have different physical mailboxes for the two accounts and use separate profiles for each. This then ensures you can process 'required' addressees differently for the same message. The main disadvantage of this pattern is that it doesnt scale, if your mailbox count is low, its fine.

2. Rework how you deliver messages. If you deliver messages as BCC to addressees, the to: list will be empty, but, some mailservers inject the 'delivery address' into a SMTP header, these headers can be listed in JEMH Email section and are used as part of catchemail processing. This means that a given email that 'can only' be delivered to one address will match a given catchemail address, and allow JEMH Project Mapping, within *one* mailbox and *one* Profile. This would be by recommended option.

As I mentioned before, current processing doesnt factor in multiple addressees on an email for duplicate issue creation in different projects, but it is a requirement I've heard of in several cases. The main problem with such a solution (which could be implemented) is the scenario of replies to the original mesage:

Currently, any reply to the original message that created the issue will be associated by ID threading with the first issue created (injection a scenario of confusion). You could turn this behaviour off in JEMH, however, doing so prevents an association being made when those replies are processed, resulting in any replies created two more issues.

Would you still want to create many issues based on many TO/CC catchemail matches, regardless of the outcome?

Thanks Andy! We'll investigate option #2.

Hi Andy,

Thanks again for the suggested workarounds. Quick question however - we're still trying to understand why it was creating duplicate tickets in the first place. If there is more than one addressee (regardless of whether it's mapped to different projects), shouldn't it just create a ticket for the first on the list and disregard the others? Just wondering if I should open a ticket for that, or if this is intended behavior.

Thanks again!

Oops - that was me :) Logged in to the wrong account.

yea, happens to me all the time ;)

If there is more than one addressee (regardless of whether it's mapped to different projects), shouldn't it just create a ticket for the first on the list and disregard the others?

If an email is delivered to many recipients, a physical copy of the email will be delivered to those mailboxes. If those mailboxes are directly monitored by JIRA/JEMH, they would of course be subject to processing.

AFAICT JIRA Mail Threading is designed to manage the scenario of additional addressees replying to the original email, such that those replies get associated with the original issue. JEMH Field Processors could affect that, Id need more details to be sure.

Please log a support ticket, attach your profile, an example email export from JEMH audit history from the 'initial' mail, and from subsequent 'created' emails from other recipients. It would be helpful to get an emh.log file for the period, details are here.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,711 views 17 21
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you