JEMH Features

Profiles

Profiles are top level containers for configuration. When a JEMH inbound mail handler is configured, a Profile will be selected from a list (so a Profile will need to be created before the mail handler can be configured).

A single Profile can route mails from one mailbox to multiple projects, thereby addressing a major scalability issue with the default mail handlers. Multiple Profiles can be configured if required.

Profiles and all their related configuration (with the exception of custom template references) can be exported as XML, for easy migration between environments as well as for support purposes.

Open

Profiles contain a Configuration, that defines how JEMH processes emails, these are broken down into various categories:

Security

• Privileged User - In order to perform some low level operations, normally done under a human user context, a user with sufficient privilege to perform that action is required. This field specifies that user, which defaults to the person who created the Profile.

• Strict JIRA permissions - By default JEMH will enforce strict JIRA permissions regarding updates. This means that any issue operation must pass valid authorisation (i.e., auto adding watchers requires EDIT_ISSUE). Disabling Strict permissions reduces some of these rules.

• Allow Anonymous Commenting - Allows anyone who uses the issue key in the email subject to comment on a issue.

• Default reporter overrides derived - If enabled, will always use the Default Reporter in the User section. This could be used to ensure users are not created.

• Use email sender for security checks - A convenience feature, for example, an project lead wants to forward a user email into JIRA for issue creation, the project lead has permission in the project, but the user the email belongs to and who is being nominated as @reporter does not (perhaps STRICT security is enabled). With this enabled, JEMH will run under the senders associated JIRA user account for the purposes of security checks.

• Treat Unprivileged users as non-Jira - This will treat users with no issue permission or right to use as a “email user” with the reporter being the “default reporter”.

Issue Security

• Issue security level - If set, will apply a default issue security level to all created issues, applying some basic security by default.

Issue Visibility

• Comment Level Security for groups - Enables matching of groups for security level checks.

• Comment Visibility - Selects a project role or group. Naturally, these must be valid for whatever project an issue resolves to.

• Comment Visibility Optional - This will set the comment as non-restricted when the commenter does not have the group or role set in Comment Visibility.

Jira Service Desk

• External Customer Comments Enabled - This will allow customers to comment on an issue even if they are not an issue participant

Project

• Project Auto Assign - If your mail server is capable of delivering multiple addressed email to a single inbox, eg abc@place.com and def@place.com, that if a project KEY exists that matches 'ABC' or 'DEF' then it will be used. This is the most efficient and scalable routing solution, allowing JEMH to support n Projects with just one configuration and mailbox.

• Project Auto Assign from Subject - Allows users to indicate a Project Key within the Subject of the email. This would be captured by a Regexp configuration.

• Auto Assign from Sub Addresses - With an RFC5233 format addressee (user+KEY@place.com), used to still support the above for KEY matching.

User

• Default reporter user name - By default, JEMH will attempt to locate the JIRA user related to a given email, if that lookup fails, and user creation is not enabled, then this value can be used to provide a 'fallback' reporter. The Default reporter must still have the correct project authorisation in order to create issues.

• Enable automatic assignee - If enabled, will look to Component, then Lead for an assignee, if a default is not set in the project.

User Creation

• Create users - If enabled, will on receipt of email addresses in FROM:, TO:, CC: create JIRA users and set with the relevant address.

• User Directory - Defines the User Directory to add the newly create to. Use the DEFAULT (first available writable directory in the Jira User Directories list) OR pick a specific directory.

• Require Sign-up Email - If enabled, Users passing the user creation checks will be required to click an acknowledgement link in order to have the account created.

• Notify Users - If enabled, will email auto-created users, enabling them to change passwords etc.

• Create User ID from - Provides control over how the user ID in JIRA is defined. At the moment, limited to:

  • Name

  • Email

  • Alternate (future LDAP re-integration)

• Alternate ID Provider - Defines the ID provider that should be used when creating the user Id.

• Create from Email condition - This defines when the user should be created from an email. The two options are:

  • Always

  • Exist in alternate only

• Allow user creation by email domains - A CSV list of regular expressions for email addresses that will be valid for JIRA user creation purposes (e.g.: .*@yourco.net).

• Block user creation by email domain - Inverse of above, giving choice of pick valid domains or invalid domains.

• Global Auto Join group(s) - A CSV list of names of groups that an auto created user will join. This list is absolute, so if jira-users is not included, the user will not have that group, have right-to-user JIRA, or count toward JIRA license.

• Auto Join Group Condition  - Controls when auto-joining groups occur. The three options are:

  • On User Creation

  • For All Jira Users

  • On Creation or For users Without Groups

• Force userId Case  - This will force the userId to be created either in lower or upper case.

• Selected LDAP Config - Defines the LDAP configuration that should be used when creating new users.

Issue

• Use Mail XHeader Priority - If enabled, the emails header X-Priority will be scaled by value (1-5) to the range of available Jira priorities

• Summary - A fallback summary that will be used in place of an empty one (give that an empty subject will cause a rejection).

• Comment - A fallback comment that is used in place of an empty one.

• IssueLink type - Allows a default issue relationship to be defined, e.g. Relates, allowing reduced typing to link issues with Directives. The current options are:

  • Blocks

  • Cloners

  • Duplicate

  • Problem/Incident

  • Relates

• Worklog security Role - Sets a default security Role applied to worklog notes delivered through JEMH.

• Worklog security Group - Sets a default security Group applied to worklog notes delivered through JEMH.

• Add Sender As Watcher - Automatically adds the sender as a watcher to created issues, not necessarily with right-to-use.

• 3rd Party CF Support - If enabled, JEMH will attempt to initialize 3rd party Custom Fields with String (text) values supplied. Problems with such initialization will be logged at INFO level only.

• Add Issue Entity Properties - This feature helps mail clients thread Jira notifications in the conversation that drove their creation. It enables JEMH to store the incoming message Message-ID, References and In-Reply-To headers during issue creation

Dates

• Default Due Date - Sets a default due date of issues created by email. Number of working days in the future.

• Date Formats - Comma separated list of Java Date Formats to be accepted.

• Date Time Formats - Comma separated list of Java Date and Time Formats to be accepted for DateTime Custom Fields.

• Due Date Format - Allows an email specific format for DueDate. This may be overridden through Directives, if left undefined, must match the system default.

Loop Detection

• Issue comment limit - Restricts comments by email on any one issue to be no more than this value. Useful to put a block on runaway notifications!

• Issue comment max size (Kb) - Limits inbound emails to a specific size, note that this relates to the COMMENT size only. Useful to stop runaway bot-generated chatter between JEMH/other.

• Limit exceeded action - Determines action to take when set limits are exceeded, eg:

  • Forward to the Forward User (Notification section)

  • Reject

  • Truncate

Aliases

Aliases are versatile mechanisms for providing short cuts to common directives, e.g. an Alias bug with value issueType=bug allows a Directive of @bug to be used. Additionally, Aliases can be used to provide a mapping from some other source that happens to match a supported JEMH Field Processor format, for example, if a remote system created a value:

Related Systems: this,that,the other

This value could be mapped to components by setting up an Alias components with a value of Related Systems.

Email

Email Selection

• Operating Mode - This indicates the mode that the Profile will run as. The current options are:

  • Create and Comment

  • Create Only (all messages)

  • Comment Only (conditional outcome set through MessageFiltering)

• Catch Email Address - This is a specific address that should be found within the email. If this is not found then this Profile will not process that email.

• Catch Email Headers - This is a CSV list of headers that the Profile should check when attempting find a matching Catch Email Address.

Message Filtering

• Non Catchmail Match Action - This identifies the outcome that should happen with the email when there is no matching Catch Email Address within the email.

• No Issue referred in CommentOnly mode Action - This is the outcome that should happen when the email is not related to an existing issue. This option will only run when the Profile is in the Comment Only mode.

Pre-processing

• Use Reprocessed Message - Some users receive emails that are technically broken, having missing start boundaries and other problems. Enabling this option causes that stored message to be re-loaded and used instead, working around some of the problems found. This option also allows Pre Processing Tasks to be used when processing the emails.

• Pre Processing Tasks - This is a list of task that take place when processing email. Some of these tasks are used to fix broken elements of the email e.g. missing To address. Some tasks allow for the emails to customised to provide a specific outcome.

• Merge Re-sent messages - Once sent, if a message is re-sent, it is not a reply-to but a copy, enable this, to match the re-sent message to the issue (subject to Thread Matching Limits)

Thread Matching

• Disable Thread Checking - Thread checking correlates email's through reply-to fields, this field allows that correlation to be disabled, leaving just subject-based issue key detection as a basis for association.

• Thread Matching Condition - This is a condition that is used to determine whether an incoming mail is threaded to an existing issue. Current options are:

  • None

  • Open Issues Only

  • Open or Resolved In Last 30days

  • Not With Resolutions

  • Issue Matches JQL

• Not With Resolutions - Issues with configured resolutions will not be commented on. Only applicable when Thread Matching Limit set to ‘NotWithResolutions’.

• JQL Query - Thread matching will be ignored if the associated issue does not match the specified JQL query. Only applies when Thread Matching Limit set to ‘Issue Matches JQL’.

• Enforce rejection - If using create and comment mode, force rejection rather than create issue.

• Notify of Thread Match Reject - When Profile operating is in Commenting Only mode, messages that do not resolve to a pre-existing issue will be rejected. If this is enabled, a specific customisation notification about that will be sent to the sender.

• Use Issue Custom Field for Reject Sender - Defines the Custom Field of where the Reject Sender address can be found.

• Body Format Preference - Defines the body format preference that should be used when processing the email. The options are:

  • Text

  • HTML

• From Address Parse Order - Defines the order that the Email headers will check in when searching for the sender address. Current options are:

  • Reply-To: then From:

  • From: then Reply-To:

• Ignore Subject Issue Keys If... - If the addressee (projkey@place.com) matches a known project key and projectAutoAssign is enabled, the subject will not be used as a basis for a comment, and will be created in the nominated project instead

• Subject IssueKey (comment) Regexps - One or more regular expressions used to find issue keys in email subjects. Comma separated patterns will be evaluated in the order provided.

• Forwarded Email Subject Prefixes - Emails with a subject matching case insensitively any of these prefixes will be considered as 'forwarded' and not be subject to content stripping.

• Global Subject Cleanup Regexps - Regexps that are used to remove matching words/characters from the email subject. This is applied to emails that are processed by this Profile.

• Global Body Cleanup Regexps - Regexps that are used to remove matching words/characters from the body content. This is applied to emails that are processed by this Profile.

• Normalise Newlines - If enabled, will cause more than two consecutive newlines to be replaced with exactly two newlines (one empty line) to remove unnecessary newlines.

• Prefix content with a Comment Header - Defines the type of users that a Comment Header will be applied to. Current options are:

  • Disabled

  • Non-Jira users

  • Both Jira and Non-Jira users

• No Comment Header Addresses - CSV list of from addresses that shouldn’t have comment headers attached.

• Eat empty lines leading an email - Some mail systems will inject empty lines into the email content. This option will remove these empty lines to reduce processing issues.

• Strip-Quotes - Removes the quoted (replied to) content of mails can be stripped (see bodyRegexp also)

• Pre-validate Custom Field values - Validates provided Directive values for Select, MultiSelect and CascadingSelect (1 level) custom fields early, reducing 'false' directive hits.

• Email Sent Date CF - Defines the Custom Field that the Sent Date will be added to.

• Processing throttle - Delays processing of each email by the configured number of seconds.

HTML

• HTML Extraction Method - The extraction method that should be used for HTML content.

• HTML Wiki Markup Escaping - Pre-escapes HTML text containing vertical bar and left curly brace to stop wiki rendering of tables and macros from html.

• Hide HTML Links - When HTML mail is parsed, embedded links are generally extracted and listed. Check this option to hide that list.

• Remove non-breaking spaces - Removes non-breaking spaces (<&nbsp;>) which can potentially be necessary for valid wiki markup conversion.

• Link <a> - Defines how Links should be treated when processing an HTML email. The current options are:

  • No Links. Links are stripped and not shown.

  • Summary. Links are notarised and listed at the end of the content body.

  • Inline. Links are rendered as wiki-style links.

• HTML Image Handling - Defines how images should be treated when processing an HTML email. Current options are:

  • None. images are treated as attachments only and not rendered inline.

  • See Attached. Images are attached and a reference ‘(See Attached)’ is left where the images were placed in the body.

  • Thumbnail. Images are attached and rendered as thumbnails within the body.

  • Full Size. Images are attached and rendered as full size within the body.

• Use Provided Image Attributes - Use Width and Height attributes from the Image tag to render Images as shown in the browser.

• Rendered Image Attributes - When Images are rendered inline, attributes can be added.

• Table Rendering - Control how HTML tables are shown.

• Heading Level - Select a level of headings to be converted to wiki markup equivalent.

• Horizontal Rule <hr> - Conversion of HTML horizontal rule element to wiki markup.

• Pre-formatted <pre> - Conversion of HTML Pre-formatted element to wiki markup.

• Block Quotation <blockquote> - Conversion of HTML Block Quotation {quote} element to wiki markup.

• Code <code> - Conversion of HTML Code {code} element to wiki markup.

• Text Colour - Conversion of HTML text colour element to wiki markup.

• Subscript <sub> - Conversion of HTML Subscript element to wiki markup.

• Superscript <sup> - Conversion of HTML Superscript element to wiki markup.

• Bold <b> - Conversion of HTML Bold element to wiki markup.

• Italic <i> - Conversion of HTML Italic element to wiki markup.

• Underline <u> - Conversion of HTML Underline element to wiki markup.

• Strikethrough <strike> - Conversion of HTML Strikethrough element to wiki markup.

• Ordered List <ol> - Conversion of HTML Ordered List element to wiki markup.

• Unordered List <ul> - Conversion of HTML Unordered List element to wiki markup.

• Emphasis <em> - Conversion of HTML Emphasis element to wiki markup.

• Citation <cite> - Conversion of HTML Citation element to wiki markup.

• HTML Tag Newline Injection - Defines when new lines should be added after specific HTML Tags. Below is the current list of HTML Tags that can be configured:

  • Division <div>

  • Span <span>

  • Line Break <br>

  • Image <img>

  • Paragraph <p>

  • Table <table>

Labels

Auto Labelling (keywords)

• Auto Labelling Enabled - Enables automatic labelling from Subject.

• Can Create Labels - If enabled, candidate words from the email can be created if they don't already exist.

• Auto Add Suggestions - Use Jira's in built suggestions for the issue.

• Add Unique Originals - If Jira doesn't make suggestions, this setting will add any unique originals that were not already suggested.

• Capture Mode - Defines the mode that the label should created. Current options are:

  • Full Subject

  • Subject After Delimiter

  • Full Subject or Delimiter based

• Minimum Label Characters - Defines the minimum number of characters the label can be.

• Maximum Label Characters - Defines the maximum number of characters the label can be.

• Auto Labelling Delimiter - Delimiter used to identify when the label should be created. This will only work if the Capture Mode is either “Subject After Delimiter” or “Full Subject or Delimiter based”.

Ignores and Substitutions

When processing subject words, this configuration will allow for substitutions (e.g. to correct common typos) and to ignore specific words.

Auto-labelling (sender domain)

• Add Sender Domain - If enabled, will use the domain part of Email Only users addresses as tags.

• Sender Domain Storage - Defines where the Sender Domain should be stored. Current options are:

  • Label

  • Custom Field

• Sender Domain Allowlist - CSV list of domains that are allowed to be added into a Label or Custom Field.

• Sender Domain Blocklist - CSV list of domains that are not allowed to be added into a Label or Custom Field.

• Sender Domain Custom Field - Defines the Custom Field to use when Sender Domain Storage is set to “Custom Field”

Attachments

• Enable Attachments - When enabled, allows JEMH to process email attachments (requires Jira attachments to also be enabled)

• Allowlisted Attachment Types (csv) - CSV list of file types that can be added to the issue. If the attachment is not one of these types then it will not be added.

• Block Attachment Types (csv) - CSV list of files types that should not be added to the issue.

• Blocklisted Attachment MimeTypes (csv) - Allows specific attachments identified as a given mime-type to be excluded.

• Non Renamed Attachments (csv) - Allows nominated regular expression matches for filenames to NOT be renamed (could be applicable to specific files that are identified as image that are never inlined and need to retain the filename without -1, -2 being appended)

Add Email/original content to issue

If enabled, will create a ZIP wrapper containing the original content (text or HTML), and if selected, a full copy of the email (stored in neutral message/rfc822 EML text format).

• Add Email to Issue Condition - Defines when to add the ZIP file that contains the original content. Current options are:

  • Never

  • On Create

  • On Comment

  • On Create and Comment

• Add Original Email Body to Issue - Defines when to add a file to the issue that contains a the original email body content. Current options are:

  • Never

  • On Create

  • On Comment

  • On Create and Comment

• Disable Zip Wrapper - Disables JEMH from putting the Zip Wrapper content onto the issue.

File Name Format - replacements

• Create Name Format - Applicable to Issue Creation, this is a configurable format field for the ZIP, the EML part and the TEXT or HTML part. Variable replacements are applied.

• Comment Name Format - Applicable to Issue Commenting, this is a configurable format field for the ZIP, the EML part and the TEXT or HTML part. Variable replacements are applied.

• Add Embedded Atts - Add attachments from within message/rfc822 attached files that would otherwise remain in an attached .eml file.

• Add Image Wiki Links - If enabled, adds a thumbnail image linking to the related attachment image, now attached to the issue.

• Add File Wiki Links - If enabled, adds a download wiki link to files attached to the issue.

Addresses

• Custom From: email address - Allows emails from JEMH to be given a specific From Address.

• Custom From: email name part - Allows emails from JEMH to be given a specific ‘Name’ part of the address.

• Custom Reply-To: email address - Allows emails from JEMH to be given a specific Reply-To address.

• Custom Reply-To: email name part - Allows emails from JEMH to be given a specific ‘Name’ part of the Reply-To address.

Sender Processing

Jira User

• Jira user sender to User Picker custom field - This is a User Picker Custom Field that the sender Jira user should be placed into when creating a new issue.

• Jira user sender address to Text custom field - A Text Custom Field that the sender Jira user Address will be placed into when creating a new issue.

Jira Service Management

• Add Organization member as Request Participant - Adds Sender who is part of Organization as a Request Participant.

Non-Jira user

• Non-Jira user sender name to Text custom field - The text Custom Field that the Email sender name will be added into.

• Non-Jira user sender address to Text custom field - The text Custom Field that the Email sender address will be added into.

Addressee Processing

• Addressee Handling - Defines how addressees should be involved within the issue. Current options are:

  • To Watcher

  • To Custom Field

  • To JSD Request Participants

  • First CCIs Assignee

• Request Participant Filter - Defines who can be added as a Request Participant on the issue. Current options are:

  • Require Customer Role

  • Require No Use Jira

  • None

• Assign non jira-user Email to Text CustomField - Defines the Text Custom Field that non jira-users recipients will be added to.

• Jira account holders to MultiUser Custom Field - Defines the MultiUser Custom Field that recipients with a Jira account will be added to.

• CC non-Jira Emails Custom Field - Defines the Custom Field that Cc’d non-jira emails will be added to.

Distribution List Extraction

• Distribution List extract LDAP Config - The LDAP configuration that can provide access to the definition of the distribution lists.

Assignee

• Use first valid user as assignee - During initial issue creation, addressees are checked for ability to become assignee in the issue, starting with TO: then CC:

Templates

Identifies the templates and format that should be used for:

• Forward Email

• Comment Header

• Hintogram

• User Sign-up

• Thread Match Reject

Queue

• Auto Flush Queue - As soon as processing is complete, flush the queue for immediate delivery

Allowlist

Allowlist

• Sender Must Have Account - If enabled, the sender address must be related to a Jira account holder.

• Allowlist Senders - This is a Regex configuration that will only allow matching users to create new issues.

Blocklist

• Blocklist Senders - Regex configuration that will stop matching senders from creating new issues.

• Blocklist Recipients - A Regex configuration that will stop matching recipients/participants from being added to the issues.

• Blocklist Match Handling - This identifies what should happen with the email if the sender has been Blocklisted

Notifications

Forward User

• Project Lead as Forward User - This identifies that the Project Lead should be notified of a email processing failure.

• Forward Users - This is a CSV list of Jira users that should receive forward notifications when they occur.

• Forwards Emails - Optional email addresses used in addition to the forward user.

Hint Notifications

• Hint Notifications enabled - When enabled this will send notifications back to the original sender when their emails did not result in a issue/comment being created. These notifications will identify why the email was not successfully processed.

• Override Hint Notification email address - This allows you to override the recipient of Hint Notifications so that only one specific email recipient receives these notifications.

• Notify Sender of Forward - When JEMH's processing results in a Forward outcome, a Hint Notification email will be sent to the sender (or nominated override account) to aid in fixing the problem

Issue Events

• Use Generic Events - No other events, eg Updated will be used

• On Comment Event Behaviour  - This is used to identify the event that should be triggered when a comment has been added.

• On Create Custom Event  - The Custom event that should be triggered when a issue has been created.

• On Comment Custom Event - The Custom event that should be triggered when a comment has been added to an issue.

• Custom event firing mode - Determines if custom events are fired independently, as a bundle, or both.

Directives

• Directive Processing Behaviour - This identifies when Directives should be applied. The options are:

  • On Create or Comment

  • On Create

  • On Comment

  • Disabled

• Use Translated Field Names - When enabled, will also scan Custom Field name Translations for a match with Directives.

• Allowlisted Directives (CSV) - If defined, only Directives defined will be allowed, others will be silently ignored.

• Blocklisted Directives (CSV) - If defined, matching Directives will be silently ignored.

• Directive Groups - Defines groups that Jira user associated with the sender address must have in order for directives to be available.

Field Processors

Defaults

Field Processor Enablement

• Basic - no-op mail processor, no directives possible.

• At(@) Prefix - Keys are prefixed with @, eg @key = value.

• Colon Suffix (Mailform) - Keys are suffixed with :, eg Some Key: value.

• Subject - Subject content keys are prefixed with #, eg #key ="some long value".

• Regexp - Allows regexps to identify 'values' in emails to be used in Jira issue queries, for locating issues to comment on.

• XML - Body content follows XML structure (defined on wiki).

• CSV - email containing an attachment with CSV values identifying issues (defined in wiki).

• X-JEMH Header - The X-JEMH Header Field Processor allows a text payload to be solely concerned with content.

• Nagios Notifications - Nagios generated emails, specific content extracted from subject and body.

• Script (Advanced) - Allows custom email processing behaviour via scripts.

Third Party Field Processor Enablement

• Enabled third party Field Processors - This is a list of Third Party Field Processors that have been added to JEMH/Jira. To select/deselect the relevant processor you will have to use Ctrl + Click.

• Indicate active Field Processor/Profile - This will prefix the description/comment with text identifying the Field Processor that was used and from what Profile.

Project Mappings

Project

• Mapped Project - Defines the Project that the issues should be created within.

Issue

• Component - The value to be set to Components field when a value has not already been set.

• Issue Type - Default Issue Type for issues created in this Project.

• Priority - Default Priority for issues created in this Project.

• Labels - Provides a specific Label for issues created in this Project.

• Reporter - Specific Reporter that will override the Non-jira sender.

• Assignee - Default Assignee used when an issues is created.

• Watchers - Adds additional watchers to issue.

• AutoLinking - When selected, if a comment were made against an issue that was not allowed to be commented then that issue will be linked to the one that was created.

Groups

• Join group from email domain - Auto create and join the user to a group matching the email [domain] in <user@domain>

• Add group to given project role - Assigns the group to the specified role within the Project.

• Join group to custom field - A specific Group capable Custom Field. that will be populated with the nominated domain based group.

Auto Join Groups

• Auto Join Groups - Target users will auto-join the given comma separated list of groups.

• Apply on - Configure when Auto Join Groups should be applied

• Audience - Configure which Users should be auto joined to Groups. This includes Service Management Users who have accounts

Issue Security

• Issue Security Level - Creates the issue/comment with the specified Issue security level.

Pre-Processing

• Cleanup Expressions - Here you define expressions that are 'removed' from the final content. This can be applied to the Subject and email Body

• Body Delimiters - Here you get define expressions to apply during create/comment that will match specific content and will then remove any content that follows.

• Dynamic Evaluation - A form that enables dynamic evaluation of create/comment body cleanup and delimiter expressions against a nominated Test Case.

Comment

Core/Software

• Viewable By Role/Group - Identifies the type of users that can see the comment.

Service Desk

• Agent comment visibility - The visibility of comments created by Agents. Current options are Private and Public.

• Collaborator comment visibility - The visibility of comments created by Collaborators (any user with application access). Current options are Private and Public.

• Add Uninvolved Senders - When enabled, will add uninvolved senders as request participants. Requires Security > External Customer Comments Enabled to be enabled.

Email

• Message filter actions - Configure what action should be taken when an email is filtered by a message filter. Leave blank to inherit the action from the default mapping.

• Archived issue handling - Configure how JEMH will handle commenting on an issue if the issue has been archived. Current options are Reject and Forward.

Custom Field Defaults

Custom Field Defaults allow arbitrary Custom Fields to have default values specified.

Workflows

Allows workflow transitions to be conditionally triggered when its respective project mapping is matched.

Blacklisting

Blacklisting is where global blacklist configuration can be made. These settings allows, for example, 'Out of office' emails to be explicitly blocked for all configurations (over and above what is defined within a Configuration.

Open

Template Sets

Template Sets allow configuration of all JEMH injected text and/or notification content, providing Subject, and Text/HTML content template editing as applicable.

JEMH Template Sets and 'normal' JIRA notifications

To be clear, JEMH Templates are not replacements for JIRA email templates and do not change them, primarily this is due to a 'bug' that the default Atlassian Issue Event Listener cannot be removed/replaced JRA-19957.

JEMH contains velocity templates for its notifications within the plugin. TemplateSets provide a means for the end user to customise the content of emails sent by JEMH without requiring unpacking /repacking/ redeploying of the plugin. JEMH allows customisation to vary, so that different projects can receive different styles (though at this time, JEMH does not help you design those emails).

Template Set: JEMH Comment Header

This is a simple comment header that prefixes inbound email descriptions/comments indicating that the value came via email, and who it was supposedly sent from:

Template Set: Issue Event Template Set

@Since 1.2
Issue Event templates are also included, specifically for use with non JIRA account holder notifications.

Issue Event Templates, unlike JEMH Templates are not bundled with JEMH, they are read from JIRA. When an Issue Event Template Set is created, a snapshot of the current JIRA Template is made, allowing that particular template to be customized for one particular project, or shared across several. Future changes in JIRA may require maintenance to these templates, that work must be accepted as part of upgrade testing!

The Issue Event templates are located in JIRA under $JIRA_INSTALL/atlassian-jira/WEB-INF/classes/templates/email/...

JEMH Issue Event Template Sets provide a means to not only customize the Text and HTML content, but also the subject, to a point. Rendered templates are the same as JIRA users receive.

Template Set: HintOgram Template Set

The HintOgram optional mechanism is JEMH's way of communicating processing failure. Due to the noise that this can create, these notifications can be routed to an admin (who could perhaps fix the problem or communicate to the user that priority: broken is not valid).

HintOgram emails look like:

Template Set: Forward Template Set

Forwarded mail is sent on by JEMH to a nominated user email address, in the format selected as preferred by that user. The templates are currently 'functional' but can be customised.

Template Sets - how are they 'used'

JEMH Profiles define how most TemplateSets are used, if the 'Default' is selected, the uncustomized 'internal' default JEMH template is used.

Test Cases

Test Cases allow rapid testing of email content against configurations and completely bypasses inbound mail handlers, so a configuration can be validated before being hooked up to the outside world. A TestCase email is the native raw text email content that travels over the wire, not just content. Test Cases can be generated from Audit log information for problem diagnosis.

Notifications

Notifications are configured on a per project basis to notify users by email addresses found in a custom field (that JEMH can be configured to populate on the way in). Notifications can use default templates, or make use of customised content through the Issue Event Template Sets.

Certificates

An initial implementation of GPG Security for signed email validation. This implementation natively executes GPG binaries, and has been validated on Linux only, other platforms should work.

Auditing

Auditing allows a historic view over processed data, enabling tracing of an email to an issue.

An audit log for the processing is available that @Since 1.2 contains any Hints that were generated as part of processing that may have caused the processing to fail for some reason (e.g. reporter doesn't have correct permissions for action).

All inbound mail is captured and stored (on the file system under JIRA_HOME/data/jemh) irrespective of processing status

Audit mail can be exported (for support/diagnostic purposes) as well as being converted into a Test Case for local configuration testing.

Credits

@Since 1.2
As the application grows, various libraries and third party components are being pulled in. The credits section provides attribution to the author(s) of those works and indicates the license under which they are used.

Licensing

Always available, provides access to current license status, as well as the online shop.