How to configure JEMH to do Subject-matching Comments (not create new)?

[Edwin Chung]

Hi,

Where do I configure this function - is it Profiles > Configuration > Email > Subject IssueKey Regexps? It looks like this is configured to pull KEY-### out of the subject.

How do I configure this to, instead, make any emails with identical subject (Excluding RE: or FW: or Re or Fw) append to an existing ticket as a comment, similar to the mail-thread-handling built into JIRA?

Thanks,

Edwin

[Andy Brook [Plugin People]]

Hi Edwin,

JEMH does not implement exact subject based matching for selecting an issue for commenting, this is because at scale, it will fail, for example, how many 'password reset' messages could there be? In the main, JEMH relies on replies using the issue key in the subject. The scenario where that doesnt work is replies to the original mail that was sent to JIRA to create issues. JEMH does by default use JIRA mail threading for associating such messages with the original issue. It can also be disabled: Email > Disable Thread Checking.

If you don't have that disabled, please try to reproduce, and create a support ticket with JEMH Audit History exports of the related email messages (no proprietary email objects from your mail client, ta!).

https://thepluginpeople.atlassian.net/browse/JEMH

[Samuel Knowlton]

Hi Andy,

I know this question comes up a lot and as a new JIRA/JEMH admin I'm wondering what the best way to tackle it is.

Our scenario may be specific enough that it would scale: we get support requests from two sources. One is humans, where we're comfortable having every new subject be a new issue, but the other is code failures in a web application. These generate one email per error, and while certain types of repeat errors could be caught and handled in our software, other types can't, for a variety of reasons.

The one issue-per-email rule is problematic here because people will occasionally click ze button ten times and thus generate ten emails.

What I'm wondering is whether or not there's a way to create a rule to do the following:

When an email comes in that matches a particular regexp pattern that we would use in our software's automated error handler, check for any issue created within the last X number of minutes - maybe even just 5 or 10 - and if it matches, either post the content of the email as a comment on the matched issue or else discard it (since we already have the data we want).

Because the potential pool of matches is relatively small, and because JEMH would only have to look at subjects that match a Regexp anyway, is this possible?

Thank you!

[Andy Brook [Plugin People]]

Hi Sam,

So, lets tackle automated sources first, as they are more predictable! Systems generating errors generally (a) Have a repeatable structure, (b) Typically have a 'system' from: address. In these cases the Regexp Field Processor of JEMH can be used to match no specific areas of content from a post HTML-> Text conversion (bots typically send text only, making this again, easier). There is some initial up-front effort involved in getting to grips with how the regexps work but after the first few fields it ought to be easy enough ;) If you want to open up the regexp matching 'from' address, thats possible, but starts to hinder your second case, handling people.

For human senders, assuming Regexp FP isnt usable, JEMH can 'route' messages into a specific project based on keywords in the email (subject/body if enabled), now, once matched, the theory goes that:

a) the email creating the initial issue may have included additional recipients. If those recipients reply, JEMH uses JIRA mail threading to associate those replies with the already created issue.

b) Assuming you've enabled full notifications so that all JIRA users get notified, and all email onyl users get notified, those notifications contain the created issue key, so, replies to such notifications will be reassociated with the initial issue.

The last case (correct me if Im wrong) is where arbitrary users mail in and say 'website xxx is down', well, JEMH doesnt have a way to associate those yet. The Project Mapping Rules aren't appropriate as its for issue association rather than picking a project. It would be a new issue lookup feature, perhaps used after the initial mail threading did not yield a matching issue, and if no issue key was referred in the subject.

Feel free to log a feature request for this, current priorities are JIRA clustering support, new features are likely to be in a 6.3+ build.

[Samuel Knowlton]

That part we have down - it's not a question of routing automated emails to the right project. It's a question of when the same error report comes in 10 times in the space of a minute. Arbitrary users mailing in is also fine with the current feature set - it works very well for us (though we're still struggling a bit trying to get JIRA to parse actual html rather than convert it, but that's another question)

The recipients of that email are correct and the issue gets created correctly. The problem is that it creates 10 issues instead of realizing 'I just created an issue nearly identical to this one.'

The emails are in HTML format, but their content is identical except for the timestamps in the code. What we're looking for is some mechanism whereby JEMH will check for issues within some relatively small timespan and either append the new email as a comment or else discard it (depending on what we feel like for a given project).

I'm not clear on whether this is something that I can already do or if it is a feature request. If it is a request, it would be fairly narrowly tailored to combat repeat issue generation within a short time frame - I understand the concern about the system not scaling when it has a lot of work to do with content comparison.

[Andy Brook [Plugin People]]

Hi Samuel, I think you're wanting a new feature. The trick is that coding a regexp to match the current email content to 'know it is a match' is one thing, but to find another issue (using JQL) could be interesting for arbitrary length content. It would need some testing. Other possibilities are hashing the 'matched' content and storing that in a custom field, would allow a simpler and more effiecient lookup at least.

Please log a feature request, we can continue the discussion there.