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

Jennifer H.

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!

unknown

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?