More specifically, with the defaul "Create a new issue or add a comment to an existing issue" email handler, new issues submitted by email will all be created in the one project specified in the mail handler configuration. But comments to existing issues will be attached correctly regardless of project if the username associated with the origin email address has appropriate authorization and etc.
With that same default email handler you could have all incoming email go into a common "input queue" project, and then have some mechanism to move issues into appropriate project queues. In my organization's "inside the firewall" JIRA we have a common input queue and the development team lead moves issues by hand into the appropriate queue. This is a low-volume application and it gives the team lead a chance to have a finger on the pulse of the issues as well as to make triage and routing decisions.
There are also alternative email handlers that allow the "project" to be specified in the body of the email message and/or automatically applied via rules; see
and possibly search Google for "jira email handler".
We have more than 400 projects. So does it mean i have to confiugre those many number of handlers? Also in the documentation(https://confluence.atlassian.com/display/JIRA052/Creating+Issues+and+Comments+from+Email) it was mentioned as
Tip: You can configure JIRA's mail servers so that recipients of email notifications can simply reply to these messages and have the body of their replies added as comments to the relevant issue. To do this, simply set the From address in JIRA's SMTP mail server to match that of the POP or IMAP mail server's account being monitored. In most cases, this means having JIRA's SMTP and POP or IMAP mail servers use the same mail account. Details on how to configure JIRA to handle these emailed replies is mentioned below.
In the from address of SMTP mail server configuration, we already have an email alias mentioned. So JIRA is sending mails for all the actions currently. Could you please let me know how this impacts if we have project wise handlers?
Email support for JIRA projcets with default mail handlers has a one to one mapping. You can setup a project with a mailbox and it will work fine, you can even do this 30+ times. It is at that point the non-scalability of this approach will become more visible, laggy responses, maintenance overhead (only 350 more mailboxes to go...)
What JEMH offers, amongs many other things, is a way to do so much more with a single mailbox, for example:
Automapping addressee to projectKey
If you have the luxury of controlling a mail subdomain (email@example.com), automatic routing to any number of projects with a key matching the prefix xxx can be achieved with a single mailbox and one checkbox.
Mapping a project by incoming addressee
If you dont have that luxury, and have many different pre-existing address, and are able to setup mail server forwarding rules, such that all those mails end up in a single mailbox, then JEMH Project Mappings allow you to route specific addressee's to specific projects, with customised creation parameters (component/issueType/assignee/...).
Mapping a project by sender
Getting a little more selective, its also possible to map an incoming email based on the sender address, allowing 'account' type management.
Mapping by keyword
A recently added feature now also allows routing of emails to projects based on keyword matching.
So, JEMH (not free) provides many options designed for scalability in JIRA email handling. if you would like to discuss your needs offline, happy to chat; andy at javahollic dot com
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
As part of the Bitbucket product team I'm always interested in better understanding what kind of impact the use of our tools have on the way you work. In a recent study we conducted of software devel...
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!
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