JEMH for Jira Server/Data Center - Enterprise Mail Handler for Jira
All of your email needs in Jira
The Enterprise Message Handler for Jira (JEMH) provides a wide array of business enabling functionality, unmatched by any other handler. It allows full configuration, which can later be exported or imported for easy migration between environments. It currently supports several communication channels including Email, Slack and SMS.
Manipulate issues via email
Directives allow users/automation solutions to modify issues directly through email. With several Directive formats to choose from, JEMH can be the email integration glue required to join disparate systems to Jira.
Transports extend JEMH's notification capabilities beyond just email. Each Transport hooks into JEMH's Event Listener system and can be enabled on a per-event basis. As usual, customization of both HTML and plaintext content is possible. The following Transports are built in:
Standard Jira mail handlers are not scalable. With project, issue and user numbers rising, mail servers are put under increased load and Jira issue creation slows down. JEMH solves this with Project Mappings, allowing you to route email to projects based on definable criteria. This criteria could be as simple as sender/recipient address, group membership or email content. All the while, allowing control over the attributes of created issues.
Improve help desk efficiency
Using Jira as a help desk out of the box requires creation of users, but if the interaction is fleeting, and with a lot of support traffic, a significant amount of wasted seats will accrue, never mind the Jira user account 'noise'. JEMH solves this by mapping remote user email addresses to a Custom Field, and uses a "Default Reporter" to nominally create the issue on their behalf. Updates by interactive Jira-users (and remote non jira-users) cause Issue Events to be fired, to which a JEMH Issue Event Listener reacts, making use of JEMH Template Sets, can notify remote users of these changes.
Jira licensing is based on the number of interactive application users. This refers to users that own a user account capable of logging into Jira instances.
Filter out spam from your Jira
Often you may find Jira getting bombarded by various automated responses, for example when a user is Out of Office. This problem can be a distracting annoyance. At worst, it could cause email loops or prevent legitimate emails from being processed. JEMH has advanced blacklisting features that can stop this from ever happening.
Capability to pull mail into Jira, creating and comment on issues, add attachments etc. It does that by specifying a (singular) target project. The relationship is one handler/project to one mailbox
Ability to consume emails from unregistered users (but not the ability to include those users in updates to created issues)
Ability to create users from their email address
Depending on the 'choice' of mail handler different 'capabilities' can be gained, but they cannot be used together.
HTML email has a basic conversion to wiki markup compatible output
Scalability - with large numbers of inbound mail handlers there are significant resource and maintenance overheads. Using JEMH, you can route many addresses from a common mailbox to many projects, effectively supporting n projects with n mailboxes with one mailbox connection (this is why JEMH was first written).
Auditing - JEMH optionally retains history of emails received and what happened in case of failure. Once the failure has been addressed, it is possible to re-process these emails
Round trip support for both Jira users (via standard Jira Notification schemes) as well as email users
JEMH configurations (Profiles) include all inbound mail handling configuration. A Profile can be referred by one or many JEMH Mail Handlers, reducing complexity. Profiles can be exported and imported, allowing environment migration, and supply for support purposes.
Project Mappings within Profiles allow mail to be routed to Projects based on Rules, Sender or Jira mailbox Recipient, Keyword (body/subject) or sender user group. Each Mapping underlying Rule can be used to route mail and customize how they are created (change assignee, priority, labels etc)
Directives are commands that are email supplied key/value pairs allowing issues to be modified (e.g. priority, custom fields, workflow). These can be applied during create or comment, with blacklist/whitelisting and Jira user group usage restrictions as needed
Field Processors are different 'interpreters' for email supplied content, most enable Directives supplied in a different way. The most versatile of these is the Regexp Field Processor which enables extraction of values from emails via Regular Expressions. Values are mapped to custom fields, but also, with such extracted values, its possible to translate these external values (e.g. priority 'must have' to internal Jira specific values 'blocker' via JEMH Aliases.
Email compatibility, JEMH has extensive support for fixing defective emails. The world is full of mail sources generating 'broken' emails that are not possible to process with default handlers. JEMH can fix many structural issues 'on the fly'
Full image support for a richer user experience, including image inlining
Blacklisting of emails by subject out of the box, based on Regular Expressions.
Blacklisting of all standard Jira images when attached, of image attachments based on size (e.g. <5K), of images specifically uploaded (signature image) based on their hash
BETA: Status notifications, allowing Jira to notify email-only users of open/recently-closed issues.
Auto creation of users, but, integrated with LDAP for user lookup and correct userID usage in Jira instead of just email address
JEMH is designed for extensibility, key feature points are extendible making new implementations for customers specific requirements possible
Test Cases are a feature of JEMH that allow simple email scenarios to help validate configuration. Test email content can be edited on-the-fly. Exporting email content from auditing to Test Cases is common, and also allows problem emails to be provided for support
Ability for users to mail out template driven content to specified issue participants and email-only users, including selected issue attachments, feature can be secured to Roles on a per-project basis
Post Function notifications
Ability to drive notifications from workflow, similar feature set to the Ad-hoc notification, but also including a JEMH Custom Field for transition-specific (notification with) selected attachments.
Its powerful event-based notification system can react to issue and user events and generate notifications for them.
Control which projects JEMH monitors, and what specific events it should create notifications for
Separate Jira user notifications from non-Jira user notifications
Custom notification templates can be made for all events if desired. You can preview custom template edits while editing them.
Its also possible to change or ignore a received event based on a user defined script, allowing further control over notification behaviour