JEMHC Project Mappings allow fully-flexible Rule driven routing of email to projects. This guide will describe JEMHC Project Mappings in detail, and provide examples to illustrate their use.
It is not necessary to have a production mailbox setup to drive inbound issue creation, JEMHC Test Cases can be used to inject an email into the processing pipeline.
A JEMHC Profile drives how incoming emails are handled in every detail, this includes the JIRA project that issues should be created in and much much more!
When creating a Profile, the Profiles configuration is the default Project Mapping that applies by default when no other Project Mappings rules are either defined or match, as such, the default Project Mapping has no rules.
When additional Project Mappings (for a given JIRA Project) are created, it is then possible to add Rules of several types that cause this Project Mapping to apply over other Project Mappings or the default. When Project Mapping Rules are defined, for the most part, fields defined in the 'Default Project Mapping' are inherited by but can also be overridden by additional Project Mappings.
Rules can further override values defined in the related Project Mappings, allowing very flexible issue creation with full access to all issue parameters at that time.
Validating expected outcome of email handling can be done quickly and easily with a JEMHC Test Case, where an 'email' can be crafted with a valid TO: address that matches the "Catch Email Address" in the profile (your mailbox inbound address).
In this scenario, all mail will end up in the given project, that's it. For more flexible use of one profile to route mail to different projects, see following scenarios.
Once a basic Profile with default Project Mapping exists, adding a new Mapping for a new project that will route some mail to that mapped project, and all other mail to the default Project Mapping project.
A project mapping rule can be made up of one or more of the following criteria:
Rule Type | Description | Example Value | |
---|---|---|---|
From Address | A list of regular expressions that are used to match against the email sender address. Note that this is matched against the email address part of the sender header, personal names are not considered. |
| |
Recipient Address | A list of regular expressions that are used to match against the email recipient address. Note that this is matched against the email address part of the sender header, personal names are not considered. |
| |
Keywords | A list of strings that are used to match against text in the email subject or body (or both). |
|
Rules can be created that match using regular expressions on the From or To (recipient) addresses defined in the email, as well as keywords, in this example, we'll map any sender from the @localhost domain with the regular expression .*@localhost (in regular expressions, * means any number of the preceding character not all characters, to match any character . is used, hence .*
to match everything):
After submitting, the summary for the rule is shown:
With this project mapping rule in place, any mail from @localhost will get handled through this Project Mapping, and be created in the TEST project
Its possible to use one Profile, with one Project Mapping per 'inbound mailbox', in order to do this, the top level 'catchemail' addresses must include ALL inbound mailboxes. The simplest way to do this is with email aliases to a common account, for example, e.g.: "support@yourco.com" with aliases "aaa-support@yourco.com, bbb-support@yourco.com, ccc-support@yourco.com", with these aliases present all mail ends up in one mailbox, then the "Catch Email Address" can be as easy as:
Then, Project Mappings can be associated through a Domain rule matching the full actual inbound mailbox address. |
Related articles appear here based on the labels you select. Click to edit the macro and add or change labels.
|