Restrict Mail Handler commenting to a single project

[Michael Davison]

I have set up an incoming mail server & handler per the documentation: https://confluence.atlassian.com/adminjiraserver073/creating-issues-and-comments-from-email-861253784.html

As far as I understand, the handler will add comments to *ANY* Jira project on the instance if the issue project key is included in the Subject line of the email, when the handler is set to "Create new issue or add comment" or "Add comment..." settings.

Is there any way to restrict this functionality, to ignore certain project keys, or get the handler to only check for 1 issue project key?

Example:

My instance includes Projects with Keys "ABC" and DEF". I only want to add comments to project "ABC".

I configure a server/handler for "Add comment..." During testing, of the handler/server, when I include "ABC-123" in the subject line of an email sent to that server/handler adds comments to that project & issue #. Great!

But if a user sends an email to the same server/handler with "DEF-123" in the subject line, comments will get posted to Project "DEF," Ticket # 123. I DON'T want this to happen.

[Alex Koxaras _Relational_ · Accepted solution]

Hi @Michael Davison 

Did you choose in which project you want this mail handler to create issues or add comments? Take a look at an example setup I have below. Both email handlers create new issues, or add new comment to specific project:

[Michael Davison]

Thanks @Alex Koxaras _Relational_ .

Here's the thing: I set up 2 test email handlers, using 2 different email addresses as shown below. I have selected the default project as well, as shown in your image. I have 2 separate default projects, test1 and test2 (mine appear below). 

However, as far as I understand, the default project is only for Creating issues. It does not limit commenting to a single project (my example below).

To test this, I sent an email to the test1 email address with the TEST2 issue key in the subject. The test1 mail handler put a comment on the test2 project - and this is what I am trying to limit. It appears I can comment on ANY project in my instance when this is turned on. For example, if I put a Jira issue project key in the email subject header that is a LIVE, PRODUCTION project, and not one of the test projects I created, and send it to one of the handler addresses below, the test server/handler will comment on the live project (something I definitely don't want).

Does this clarify my issue?

[Alex Koxaras _Relational_]

Let me test it and I'll get back to you

[Alex Koxaras _Relational_]

Good morning @Michael Davison and sorry for the delay!

So I've tested it and it seems that you are right. It does create a comment to another project. However, reading the official documentation, this is the normal behavior. So this is expected. You might want to use another email handler to do your job, such as 

• Create a new issue or add a comment to an existing issue OR
• Add a comment before a specified marker or separator in the email body

[Michael Davison]

Many thanks for your time @Alex !

[Alex Koxaras _Relational_]

If you are satisfied with the answer, kindly mark it as accepted and close this one out. Thanx!

[Michael Davison]

@Alex Koxaras _Relational_ 

I just am confirming that there is NO way to implement my original question - that is, to restrict the mail handlers to comment to a specific project.

No email handler that has commenting in Jira (choices below):

• Create a new issue or add a comment to an existing issue
• Add comment from non-quoted email body
• Add comment with entire email body
• Add comment before specified marker or indicator

Includes this functionality. Correct?

[Alex Koxaras _Relational_]

@Michael Davison the below handler 

• Create a new issue or add a comment to an existing issue

restrict the creation of issue and comments to a specific project.

[Michael Davison]

@Alex Koxaras _Relational_ Thanks however I have tested my handler using the

"Create a new issue or add a comment to an existing issue"

setting and it is still possible to post a comment to ANY project with this - it does not limit comments to a single project.

[Alex Koxaras _Relational_]

That's strange, because I've tested it as well and it didn't create an issue on another project. So sorry then, but I don't have an answer for you. Perhaps somebody else from the community might help you find the right answer. You can always turn to Atlassian's support, since you are on the premium plan.

[Michael Davison]

No worries @Alex Koxaras _Relational_ I appreciate your time and help!!

[David Roberts]

Hi @Michael Davison 

Did you ever figure this one out?

We also want to limit the "email to comment" feature to create comments from only those emails where the subject contains a key from ONE specific JIRA project, not for all JIRA projects.

E.g. we use JIRA for incident management, and when an end user emails our "support desk", it creates a ticket in our support desk project.  However, if they happen to put one of their JIRA issue keys into the subject line, then it creates a comment on their own JIRA issue instead of creating a new JIRA in our support project.

[Michael Davison]

@David Roberts One thing that might help is to setup a dedicated, separate email and NOT use the Atlassian Default Cloud Mail Server:

in the incoming email server/handler. I suspect that when I was having issues, both my internal project and our 3rd party service providers were both using the default server, therefore if our projects happened to be mentioned or included in the subject line, we would get strange comments from our 3rd party service provider. Once we set up a dedicated email and replaced that in the settings, the cross-pollination stopped. Are you using the Default Cloud Mail Server?

[Alex Koxaras _Relational_]

So @Michael Davison it's good to know that what I proposed back on September was the solution to your problem. How come you didn't try it back then?

[Michael Davison]

Alex you suggested using a different handler.

The solution is to use a dedicated email as the server, and not use the default cloud server email that Jira provides.