JEMH Usage Scenarios

To see how JEMH can help you make the most out of your JIRA instance, see the following scenarios. If you have a scenario that's different, drop me a line on the support site and I'll see if I can help.

Scalability for incoming email handling

Once you have a non-trivial number of projects, you will have found that this doesn't scale (btw, this was one of the reasons JEMH came to be). Adding a specific mail handler for each project will do bad things to your mail server and queue flush timings, delays in fetching mail etc. JEMH Addresses this in a number of ways:

Scenario 1 - you can support n addressees in a mailbox (e.g. have a Postfix virtual mailbox)

JEMH allows dynamic routing to a project based on the addressee of an email. This means that one JEMH configuration can support n projects with one connection to one mailbox.

Scenario 2 - you don't want to open up all projects

JEMH allows mapping of projects based on addressee. If your mailbox can receive mail addressed to different recipients, JEMH provides Project Mapping that can use the addressee to route email to a specific project. Again, one JEMH configuration, multiple mappings supporting multiple projects with just one mailbox and just one connection.

Support Desk - lots of external users

This is becoming quite common. You have a JIRA instance for your team, but want to engage with your customers. Creating JIRA user accounts for all your customers is one option, but it might work out a little pricey, and for occasional use, perhaps doesn't make the most of that investment. JEMH can help by providing an email interface for JIRA, routing traffic to projects through customisable mappings.

Scenario 1 - Create Users with interactive logon

By enabling full JIRA user membership, your remote users have the flexibility to logon or use email. The thing that JEMH brings over the default handlers here is that issues can be routed to projects, categories, have priorities set, labelled, all based on incoming domain, saving lots of ticket management. If you receive a lot of traffic, this automated routing of traffic should help greatly!

Scenario 2 - Create Users but do not enable interactive logon

By creating a JIRA user account that doesn't allow interactive logon, that account can be used within JIRA but does not count as a seat. The additional advantage of this setup is that notification schemes will work, using that users email address. The downside is of course, that those users will receive enticing JIRA ticket id's and might expect to be able to logon to JIRA.

Scenario 3 - Don't create users

If you just don't like the idea of creating users in your JIRA period, then its also possible to support that but there are consequences. By not creating an account, there is no way to include them in notification schemes, however, coming in 1.1 is an integrated EventListener that will enable per related project customised notifications, enabling you to remove specific JIRA logon references and transform JIRA into a more email-friendly helpdesk system.

System Integration

Scenario 1 - integrate Nagios monitoring system X with JIRA

Sure you could write a REST client etc etc, however, many systems provide email alerts, routing those to JIRA for management can be a time saver. JEMH supports Nagios notifications and is able to automatically close out open tickets if an 'OK' message is subsequently received. This association with a previously existing issue is something that will be coming to generic issue processing at some point in the future.

Scenario 2 - integrate system X with JIRA

JEMH Is pretty flexible and offers many ways to handle incoming mail, including manipulating the issue that would be created through Directives. Directives can be supplied in a variety of formats (but can't be mixed in the same message as all Directive Field Processors go through an initial selection, there can be only one...), for example, a message can be supplied with a modified subject #issueType=bug there is even Alias support, so #bug could be made to have the same effect.

Confluence integration

Scenario 1 - integrate JIRA with confluence via e-mail

The awesome Adaptavist MailFormNg plugin allows you to setup a form in Confluence that emails JIRA. JEMH has a Directive Field Processor that caters to this format, and can route the email accordingly.

Ad hoc usage

Scenario 1 - influence issue creation

JEMH can, through the use of Directives, help more appropriate issue creation, for instance, when receiving an email, you can forward to jira, but set a specific project, issueType, priority etc.