JEMH Configuration Options

Per-Service Jira UI overrides

When a JEMH Service is configured, its configuration file is identified through a configFile=somefile.properties entry. In 0.9.1-SNAP it is possible to provide further values (comma separated, no spaces) to override on a per-service basis, any values in the configuration file. So, you could set different default projects, priorities, assignees etc etc.

Example Config Files

Each of the following shows a simplified configuration, features can be mixed and matched as required:

Bare Bones

This example setups up default a default project so all issues are created in one place (including an optional Component). This configuration will consume all emails in the target mailbox, only users with registered Jira email accounts can send mail in.

Setting Defaults

Most things can have default values, these are global to JEMH, and are used as a last resort if necessary information is missing, or not provided through directives. Eg. a default reporter can be specified. Whether or not the specified default reporter overrides the derivation of email -> user (so they get notifications etc) can also be controlled 0.9.0.8-snap and above . Eg the following config will ensure that there can be only one reporter (perhaps simplifying project security settings)

Default Reporter

The defaultReporterUsername=someuser option sets a user that will be used, if and only if, the email address from the incoming email cannot be resolved to a current Jira user, cannot be divined through the alternateID extension point, and createUsers is set to false.

If a defaultReporterUsername is set, it is possible to set defaultReporterOverridesDerivedReporter=true that will enforce the use of the ID to be used irrespective of what the inbound from: email address, this will apply to issue creation as well as commenting.

Project Defaults

Since 0.9.3.5
This additional feature enables you to specify project specific defaults. This allows routing of specific email domains to specific projects, and will be used if applicable, ahead of the defaultProject. The fields supported are listed below:

Catchemail

Limit to a specific email address in the configured mailbox.

Since 0.9.4-SNAPSHOT, the catchmail value can now have multiple values, that may also be regexps:

Add Dynamic Project identification

Want to create issues in n projects? don't want to setup n service definitions? The following will make use of the to address (requires virtual mailbox setup), eg somekey@some.domain.com where somekey matches a valid project KEY.

Add Active Directory 'alternate email' lookup

This enables Active Directory alias emails to be scanned for equivalent addresses. In order to use this feature you need the LDAPUtils (see install page) library added to WEB-INF/lib and its ldaputils.properties config file added to WEB-INF/lib

Auto User Creation

This example shows how the alternate lookup is used to find a matching user in Active Directory, and use that ID as the Jira Name (id) when the account is created. No allow/block-listing is applied in this example, but you can also restrict the email from: domains that can be created. User creation from the sender is a feature that was lost during development of CC: user creation (JEMH-121. It's now fixed in 0.9.3.4 (Jira 4 only).

CC handling

CC handling can be setup to enable watcher support or for injecting into a custom field (after being subjected to a user lookup that may involve the alternate provider functionality if set.

An additional field restricts who can be added as a watcher, if uncommented, the jemhAddresseeRegexps config option will restrict CC: handling to specific (multiple) regexps (enabling say the CC: auto watching to only people in your company domain). This filtering is done after the mail has been received and passes any 'catchmail' tests. If watchers do not appear to be getting added, check the regexp values for jemhAddresseeRegexps.

Default Custom Field Values

Since 0.9.1-snapshot
The ability to provide declarative custom field values is only used during issue creation, and is only used if no identically named directive is found in the email.

Supported Custom Fields

All existing supported fields should work, including MultiUserCFType and CascadeSelectCFType.

Multi values

Multiple values or Cascade Select values can be provided, are comma delimited with no spaces, eg x,y,z

Key format

Keys are URLEncoded, meaning for example that the SPACE character becomes a +. Keys are also case sensitive and must be prefixed with defaultCF

example

Blocklisting/Allowlisting

This shows simple allowlist/blocklisting, limiting inbound creation to specific domains, potentially blocking individual users, and stopping processing of replies to 'noreply' type emails (ie jira report generator for example).

Default Workflow advancement

As of 0.9.3.10, there will be a defaultWorkflowAdvance field, enabling configuration of automated advance in workflow status on issue creation. Currently this is a global setting, and so will only make sense to use in some situations. The value would be subject to other related workflow settings like aliases.

Future expansion would be to provide per-project specific values, and to enable 'walking' through workflow.

Directive Aliases

In 0.9.2.5+ its possible to configure aliases for directives, so that means you can configure for instance:

As this is a replacement, even partial replacements can be used, eg:

So whether you want to be flexible or cnt typ prly on ur phne, this should help.

Field Processor Configuration

since 0.9.3.5

Custom field processors can now have specific configuration. This additional configuration allows custom handlers to coexist with user facing mail processing, still enabling just one EMH configuration to cater for all needs.

Initially there is just one new processor that has any, the Nagios Field Processor.

Nagios Field Processor

Basic Configuration

Phrase Sets

The Nagios FieldProcessor provides support for arbitrary subject string matching. The assumption is that related notifications are identical apart from a state indicator. Messages from a system eg Nagios, generally have related 'state' indicators such as CRITICAL, WARNING and OK. The additional configuration, starting with fp.nagios.relatedPhrases.1 allows such sets of related indicators to be defined. The first in the list is treated specially, it is the closure state, which will trigger automatic closure of the issue. Optionally you can also provide priorities for the associated states to set the priority of the issue, see below for examples

The first phrase is the 'all good' phrase, which will be used to trigger issue closure
White-space is important, values may be surrounded in double quotes to retain white space information (0.9.3.9+). Careful selection of phrases including whitespace should allow several systems to be incorporated.