This feature request is basically concerned with how email is handled when creating or commenting on a ticket - and almost all of it is replicated by other tickets. But there's been so little work done on email handling I wanted to start another ticket to renew the subject and give people a chance to comment.

While one of the reasons I like JIRA is the clean interface and ease of working with tickets. The vast majority of our users are used to and want to continue interacting with our ticketing system via email. We can generally do this with JIRA - however a handful of features are lacking that require us to manually touch each ticket - usually to update information in it or 'file' it - either in a specific project or more commonly, a component.

My request is that Atlassian recognize the need for much more robust email handling capabilities - While I acknowledge it is kind of a pain to populate custom fields based on content of an email (though with the regex handler this should be at least almost doable), it is kind of nuts (IMHO) to support components and default leads for components, without allowing email created tickets to be placed in a component. For example, one of our mailboxes receives mail sent to 'security', 'abuse', and 'copyright' - I've set up separate handlers for each of these - but since I can't file the ticket created by each into a separate component I either have to create separate projects for each or manually move each ticket into the proper component. If we put them into a common project, we can't even tell which handler touched them - there's no preserving of the email header information.

We also often send information via a ticket to groups of individuals - these groups are not maintained in our AD - they're local email distribution lists or listserves that are maintained by one of the >300 departments on campus. We're not going to set up separate bogus accounts for those lists in JIRA for each of these since there's no distributed group management function. What we really really need is the ability to allow the alternate notification type field (or some variant thereof) to permit either the ticket handler or the ticket submitter to enter a non JIRA account email address and then have that email address notified on change of status to the ticket. Similarly we really need a simple ability to click a link and have an entire ticket (comments and all) forwarded off to some random address we enter.

One concept you may want to consider - though it'll raise hell with your authorization architecture - allow the owner of a ticket to be able to create and email a tokenized URL that gives time delimited access to a specific ticket - to whomever has the URL. This would allow us to grant very temporary access to a ticket to someone not in JIRA or who might not normally need access. I have had times when I need to show a ticket to an attorney or a department head on a one time basis - being able to send them a tokenized link that allowed them in to see just that ticket for hours or days would be fantastic.

The other critical reason we need all this was also mentioned a while back in another ticket in this component. Our unit (not to mention the campus) has multiple ticketing systems. The ability to interact with them is critical - without that we can't justify having a separate ticketing system - and we really don't want to give up JIRA. Email is the ticketing lingua franca, and the ability to customize an outgoing email and consume incoming emails is the simplest way to do this. It would be very helpful if we could add a special notification type to the notification scheme - one where a highly custom formatted email was sent in addition to the normal notification email. For example, perhaps a project (or groups of projects) could send an email whose body was basically a custom XML format of the ticket (we'd set up the xml) to a specific address, e.g., a mailbox for our other ticketing system. The only real alternative for this is for us to have a programmer custom code a plug in to interact with, in our case, RT.

Okay - I hope this gets the idea across. Many thanks.
MC