...
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.
| Tip | ||
|---|---|---|
| Playing with configuration file settings doesn't need a restart | Playing with configuration file settings doesn't need a restart | If you are evolving your JEMH configuration, try putting the config file in say /etc, JEMH detected the leading / or \ and interprets this as an absolute location, loaded as a File, eg configFile=/etc/emh.properties. In order to work a) Jira needs to have read permission on the file, b) on windows, |
Example Config Files
...
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.
| Note |
|---|
Mandatory Configuration entriesJEMH requires several configuration values that cannot be provided via the Service parameters due to inherent field width limits. You must currently use a config file and it must contain a basic set of values. Consider the next example a starting point. |
| Tip |
|---|
Jira 3?The Packages all changed in Jira 4.x, Jira 3.x users should use this: |
| No Formatcode |
|---|
defaultIssueType=bug defaultPriority=minor defaultIssueLinkType=relates defaultProject=someproject defaultComponent=somecomponent emailFieldProcessorPackageList=com.javahollic.jira.emh.processor deleteMail=true stripQuotes=true |
...
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)
| No Formatcode |
|---|
defaultIssueType=bug defaultPriority=minor defaultIssueLinkType=relates defaultProject=someproject defaultComponent=somecomponent defaultReporterUsername=someuser defaultReporterOverridesDerivedReporter=true emailFieldProcessorPackageList=com.javahollic.jira.emh.processor deleteMail=true stripQuotes=true |
...
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:
Key | Value | Notes |
|---|---|---|
projectDefault.ABC.domainFromMatches | fromtest@noplace.com | The ABC is the project key that will be used if any of the multi regexp association based on from email address matches |
projectDefault.XYZ.domainAddresseeMatches | project-[a-z]*@jira.myco.net | The XYZ is the project key that will be used if any of the multi regexp association based on the to: , cc: and bcc: addressees |
Catchemail
Limit to a specific email address in the configured mailbox.
| No Formatcode |
|---|
defaultIssueType=bug defaultPriority=minor defaultIssueLinkType=relates defaultProject=someproject defaultComponent=somecomponent catchEmail=someemail@someplace.com emailFieldProcessorPackageList=com.javahollic.jira.emh.processor deleteMail=true stripQuotes=true |
Since 0.9.4-SNAPSHOT, the catchmail value can now have multiple values, that may also be regexps:
| No Formatcode |
|---|
catchEmail=someemail@someplace.com,[a-z]*-stuff@someplace.com |
...
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.
| No Formatcode |
|---|
defaultIssueType=bug defaultPriority=minor defaultIssueLinkType=relates deleteMail=true stripQuotes=true # dynamic project auto assign projectAutoAssign=true emailFieldProcessorPackageList=com.javahollic.jira.emh.processor |
...
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
| No Formatcode |
|---|
defaultIssueType=bug defaultPriority=minor defaultIssueLinkType=relates projectAutoAssign=true emailFieldProcessorPackageList=com.javahollic.jira.emh.processor deleteMail=true stripQuotes=true # alternate lookup alternateIDLookupClassList=com.javahollic.jira.emh.engine.LDAPAlternateUserIDLookup domainEquivalency=yourco.com,yourco.net,youco.au |
...
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 whiteallow/blackblock-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).
| No Formatcode |
|---|
defaultIssueType=bug defaultPriority=minor defaultIssueLinkType=relates projectAutoAssign=true emailFieldProcessorPackageList=com.javahollic.jira.emh.processor alternateIDLookupClassList=com.javahollic.jira.emh.engine.LDAPAlternateUserIDLookup domainEquivalency=yourco.com,yourco.net,youco.au deleteMail=true stripQuotes=true # auto create bits createUsers=true createUsersIDFrom=alternate autoJoinGroup=jira-users |
...
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.
| No Formatcode |
|---|
defaultIssueType=bug defaultPriority=minor defaultIssueLinkType=relates projectAutoAssign=true emailFieldProcessorPackageList=com.javahollic.jira.emh.processor alternateIDLookupClassList=com.javahollic.jira.emh.engine.LDAPAlternateUserIDLookup domainEquivalency=yourco.com,yourco.net,youco.au deleteMail=true stripQuotes=true # cc handling ccHandling=toWatcher |
...
Keys are URLEncoded, meaning for example that the SPACE character becomes a +. Keys are also case sensitive and must be prefixed with defaultCF
example
| No Formatcode |
|---|
defaultCF.Carbon+Copy=andy |
...
Blocklisting/
...
Allowlisting
This shows simple whitelistallowlist/blacklistingblocklisting, 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).
| No Formatcode |
|---|
defaultIssueType=bug defaultPriority=minor defaultIssueLinkType=relates projectAutoAssign=true emailFieldProcessorPackageList=com.javahollic.jira.emh.processor alternateIDLookupClassList=com.javahollic.jira.emh.engine.LDAPAlternateUserIDLookup domainEquivalency=yourco.com,yourco.net,youco.au deleteMail=true stripQuotes=true # whitelistingallowlisting whitelistSendersallowlistSenders=(.*)@(.*)yourco.net,postmaster@yourco.com blacklistSendersblocklistSenders=spammy@yourco.net blacklistRecipientsblocklistRecipients=noreply-jira@yourco.net silentlyDropBlacklistMatchessilentlyDropBlocklistMatches=true |
Default Workflow advancement
...
In 0.9.2.5+ its possible to configure aliases for directives, so that means you can configure for instance:
Alias Config Entry | Example Alias in Use | Resulting Directive |
|---|---|---|
alias.close=wl.status=close | @close | wl.status=close |
alias.bug=issueType=bug | @bug | issueType=bug |
As this is a replacement, even partial replacements can be used, eg:
Alias Config Entry | Example Alias in Use | Resulting Directive |
|---|---|---|
alias.worked=wl.timeSpent | @worked=1h25m | wl.timeSpent=1h25m |
So whether you want to be flexible or cnt typ prly on ur phne, this should help.
| Note |
|---|
Not found what you're looking for?Check the example-emh.properties file in every JAR, it varies, and generally indicates whatever features are enabled for that JAR version only. Sometimes new feature/directives get 'reworked' to be more versatile, more clear etc. |
...
Nagios Field Processor
Basic Configuration
Key | Example Value | Notes |
|---|---|---|
fp.nagios.fromEmailAddressRegexps | nagios@.* | Required. Allows nagios-specific email address(es) to be specified via regexp. |
fp.nagios.unresolvedIssueMatchTimeLimit | 1d | Optional (default 1d) Use standard Atlassian date formats, eg 1w, 2d, 1w2d, etc |
fp.nagios.project | NAG | Optional. If supplied, it will override the more general 'defaultProject' or KEY@someplace.com related project identification mechanisms |
fp.nagios.components | unknown | Optional. specifies components within the given project to use. Scope for improvement here and auto-component creation etc |
fp.nagios.reporter | admin | Optional (but requires defaultReporter to be set and be valid). A valid Jira userId that has permission to create issues in the nominated project. |
fp.nagios.resolvedWorkflowAction | resolve | Required. See JEMH Usage Guide#JEMHUsageGuide-Workflow, single word workflow action matches (instead of 'Resolve Issue') requires uncommenting the #useFirstWordOnlyWorkflowNameMatch=true option. Failure to do this will stop issues being closed off |
fp.nagios.resolvedWorkflowResolution | fixed | Optional (but requires default defaultWorkflowField.resolution to be set), enables a specific resolution to be set for issue closures |
fp.nagios.overrideHintOgramEmailAddress | root@localhost | Given the Nagios from: email address probably won't resolve to a person, you may want to provide an override for hintOgram emails, to receive notification of any processing problems |
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.
Key | Example Value | Notes |
|---|---|---|
fp.nagios.relatedPhrases.1 | OK,WARNING,CRITICAL | At least one Phrase-set must be defined, this defines three |
fp.nagios.relatedPhrases.1.priority.WARNING | major | Set issue priority to major when WARNING messages are received |
fp.nagios.relatedPhrases.1.priority.CRITICAL | critical | Set issue priority to major when CRITICAL messages are received |
fp.nagios.relatedPhrases.2 | UP,DOWN | additional Phrase-set |
fp.nagios.relatedPhrases.2 | " UP! "," DOWN! ", " UNREACHABLE! " | Example phrase sets with whitespace and required enquoting |
fp.nagios.relatedPhrases.2.priority.DOWN | major | Set issue priority to major when DOWN messages are received |