I have four email addresses, how do I setup JEMH?
work in progress
Precursor activities
You have been through Installing JEMH through the UPM
Scenario:
You have a new JIRA, and 4 incoming email addresses that you want to route to 4 different projects.
Prove incoming email
Before getting going with JEMH you should be familiar with how JIRA allows you to configure:
an Inbound Mail Server that takes care of connectivity details for a specific account
separately, a mail handler that is associated with an Inbound Mail Server
Initially, setup one Inbound Mail Server (POP/IMAP)
If you have not configured JIRA to receive incoming email before, refer to the Atlassian Documentation.
Requirements
1. Emails may be sent by users with and without a JIRA account. Emails need to be handled the same.
2. All participants should receive an email with the JIRA issue key.
3. A support person, on receipt of an email, should be able to send mail to JIRA with a few JEMH Directives (e.g. @reporter=joe@place.com) to cause JEMH to create the issue with the nominated reporter (on their behalf). This should then auto-reply to both the support person/group and the real requestor.
Only connect to live mail when done
It is not required to have a connection to a live inbound mail service. JEMH TestCases are preferred for speed.
Assumptions
The assumption is that you have a either
a single mailbox with all the inbound recipients, or
you have multiple mailboxes, multiple mail handler configuration for each physical mailbox, each of which refer to a single JEMH profile, containing the mappings for all projects
Approach
A combination of several JEMH features will will be needed to meet all these requirements.
Project Mappings
JEMH Project Mappings allow the JIRA administrator to route emails to projects based on a number of criteria:
domain mapping through inbound addressee email address or remote sender email address
(if related to a JIRA user) a group membership
subject keyword matching
For the example, several domain mappings would be used. Create a Project Mapping for the projects concerned, then add an inbound addressee mapping. You can add as many mapped addresses as you like, but the first matching rule will win, see Use Project Mappings.
Each Project Mapping must have at least one rule to work but can support several.
Non JIRA user treatment
Non-JIRA email users don't need to have an account created to interact with JIRA remotely. JEMH can store remote user emails in a TEXT(unlim) custom field, referred in the Profile Email section, see Enable non-Jira Account holders to receive issue updates and create/comment on Issues for details.
Alternatively, non-JIRA email users can have an account created in JIRA but not be granted 'right to use', this then allows a degree of management via permissions associated to groups, e.g. 'email-users'.
Notifications
The initial email hitting JIRA can be dealt with in two ways,
JEMH Profile based Issue Creation notifications
JEMH Profiles contain a way to configure the special handling of issue created emails, it can allows:
non-JIRA user (senders only) to receive a copy of the ISSUE_CREATED email (driven by a JEMH TemplateSet selection in the Profile > Email > Templates section)
JIRA-users (senders only)
All, a recent (1.3.4.x) feature extends this to reply-all to any addressee who was on the incoming email. This can be useful if the conversation continues outside JIRA and the 'thread' is desired to be tracked within JIRA.
JEMH Issue Listener Notifications
JEMH Issue Listener allows non-JIRA users and JIRA users to both be notified of specific events. Its also possible for non-JIRA remote users to receive less notifications by switching off specific events. Notifications for both JIRA and non-JIRA users can be driven by the default JIRA ISSUE_EVENT templates, or through customised versions via the JEMH TemplateSet feature.
A start to end configuration of JEMH is in Configure JEMH for a Helpdesk environment from scratch.