a) When users work on issues, that action creates an event, this event is caught by the JEMH Event Listener which generates notifications.

b) JEMH also generates notifications from the Profile in response to inbound email (which is the name given to a JEMH configuration, talked of later).

a) JIRA email has historically included issue KEYS in the subject, if this is found to refer to an existing issue, it will drive a commenting behaviour

b) JEMH has features that drive how an email can be associated with issues, so called Field Processors in JEMH can be configured to extract information from formatted or unformatted emails, that can override what issue is used for commenting, or updating

JEMH supports several flavours of email format that can be used to update all JIRA default custom fields, manipulate workflow, log work, etc.

JIRA has inbound mail connections, you configure JIRA with credentials for accessing remote mail severs. When mail is found, JIRA will hand that mail off to a Mail Handler such as JEMH that you have configured in JIRA. For JEMH, when you create a JEMH Mail Handler, you will also select a JEMH Profile, which is where all the configuration is.

After JEMH has finished processing the message, JEMH returns a true value to indicate JIRA should signal the remote mail server to remove the message. The remote mailserver is responsible for interpreting this, e.g. Gmail interprets this via server side configuration, eg marking the message read, and unpicking the 'inbox' label.

a) Usually, your mail credentials have expired, enable protocol debugging in JIRA to see this.

b) When using IMAP, a large email could be present in the mailbox, that cannot be downloaded, you will see timeout and FolderClosed type errors in atlassian-jira.log . See Download performance of POP vs IMAP for how to increase the ‘block’ size of downloads via IMAP. We have seen some mails take many minutes, some customers have presented Report info showing over an hour !

JEMH requires some basic information to create issues: a) target Project, b) Issue Type, c) Reporter, d) Summary. All these can be configured through defaults in the Profile, but when selecting them, be aware that different projects have different issue type schemes, so a default issue type may not always be valid. JEMH Profiles have lots more flexibility through Project Mappings to help.

Postfunctions requiring access to custom fields initialised or set through JEMH will just not work during the issue created transition. This relates to an architectural issue in JEMH, see JEMH-280 that needs work to fix, usually there are workarounds, log a support ticket with specific requirements.

JEMH : Jira Extendable Mail Handler

• Create issues in Jira by email, simple inline email content, e.g. issueType: bug. All standard Jira fields can be set during creation, including Custom Fields (inc Select and Cascade Select). Multiple formats are supported including CSV for multi-issue creation.

• Update issues in Jira by email, most fields are supported, using the same syntax as for creation.

• Emails that fail to create issues or fail to set some fields generate Hint-o-gram emails back to the initiator, describing what went wrong and why, including the original email. HTML delivery is available to registered Jira users if that is their set preference.

• Seamless integration with Confluence via the MailFormNg plugins forms (this project was initially written just for that)

• Reduce admin overhead for email account management by supporting n project per inbox, using the to: address as a project key.

• Enable advanced userID lookup during user creation, handy when you have a corporate Exchange box which insists on using different aliases for different clients (web/outlook/other)

• Fully flexible block/allow-listing by email address, as well as grey-listing on topic, enabling 'problem' emails to be dropped silently rather than clogging up your inbox

• Ability to create users on the fly, with several options for created userid format, eg userid@domain rather that userid@domain

• Ability to configure customized aliases for JEMH directives, enabling shortcuts such as @close instead of @workflow=close

JEMH Field Processors

This set of classes are dynamically identified, enabling users to plugin their own to support some custom format. Several formats are provided:

• Subject based #key=value

• Body based @key=value

• Body based key: value _(specifically written to enable interfacing with Confluence Mail Form Ng Plugin

• CSV tab or comma delimited attachments for yet another way to auto load data

• Nagios , funnel notifications from this popular Infrastructure Monitoring tool into Jira

JIMI : Jira Instant Messenger Interface

An additional component that allows users to interact with Jira via IM:

• configurable Jira user authentication, including captcha

• interactive shell to work in

• easily command framework making new commands trivial to add, currently providing ability to test system info, and also see who is online via IM

• watch projects and issues, eg 'watch conf' or 'watch CONF-123'
  TODO:

• add watch support, eg project, components, issues, reporters etc, all subject to Jira security

• add issue create/update support

Jira Poker

• If speed of delivery matters to you, an optional remote agent can be installed to monitor file-based mailboxes (Eg Postfix) for new mail. The Agent is deployed separately to JEMH as of Poker 1.2, as JEMH needs to be plugins 1, and REST services only work with plugins 2, sigh.

• The Jira Service deployed in Jira receives a poke from the Poker Agent, and triggers the mail retrieval service for the JEMH configured Pop/Imap service

User ID alias resolver

• an extension point is provided enabling the customisation of email address to registered Jira user lookup, needed when a user may for example have email coming from user@someplace.com and user@someplace.de, both of which need to map to user. The provided implementation is suitable for LDAP with a single primary mail account and multiple aliases.