The CERT® JIRA Attachment mail handler creates a new JIRA issue from incoming emails. If the incoming emails is just text/plain, its data is used to create the issue. If the incoming email is multi-part and there is a single RFC-822 attachment, it is interrogated and used to create a new JIRA issue. This allows a user to "forward as an attachment" and have the forwarded email be the input for a new JIRA issue.
The handler supports both S/MIME and PGP encryption. The BouncyCastle libary is being used to perform the decryption.
This handler was coded and tested using JIRA version 4.4.5, however preliminary testing has successfully been conducted in JIRA 4.x.
If the single attachment is RFC-822 compliant, the main email body and the attachment's body are combined to form the description for a single JIRA issue. By default the attachment's information is used to build the issue data (reporter,assignee,summary). If the attachment's From: field is not a valid JIRA user, the forwarder's From: will be used. This behavior can be controlled by both a Service Parameter and a X-Header value.
If the single attachment is encrypted, it will be decrypted. If it cannot be decrypted, it will be attached to the JIRA issue as is.
The main email's body will become the description for the new JIRA issue. Each email attachment will be attached to the newly created JIRA issue. If the attachment can be decrypted, the decrypted text will be attached to the JIRA issue. If an attachment cannot be decrypted, it will be attached to the JIRA issue as is.
Copy all of the JARs from this distribution's lib to directory to JIRA's lib directory (usually /opt/tomcat/webapps/jira/WEB-INF/lib)
Most configuration options can be set by either a service parameter or an X-Header on the email. For all boolean values if they are not specified, their value will be false. If a value is specified both as a configuration parameter and as an X-Header, the X-Header value will be used.
All parameters that accept a username also accept an email address.
| Service Parameter | Required | X-Header | Allowed Values | Comments |
|---|---|---|---|---|
| addccusers | No | X-AddCCUsers | false,true | Boolean value. If true, all valid users, identified from the CC email header,will be added as watchers to the issue. |
| defaultassignee | No | X-DefaultAssignee | JIRA username/email address | If specified, all issues will be assigned to the specified default assignnee. |
| issuetype | Yes | X-IssueType | Valid issue type integer identifier | 1=Bug, 2=New Feature, 3=Task, 4=Improvement |
| priority | No | X-Priority | 1,2,3,4,5 | 1=Blocker, 2=Critical, 3=Major, 4=Minor, 5=Trivial Default == 3 |
| project | Yes | None | Project ID | The value will automatically be converted to all uppercase |
| recipientassignee | No | X-RecipientAssignee | false,true | Boolean value. If true, the first found user (in To & CC) will be the assignee for new issue. |
| reporterassignee | No | X-ReporterAssignee | false,true | Boolean value. If true, the reporter will be the assignee for the newly created issue |
| reporteroverride | No | X-ReporterOverride | JIRA username/email address | If specified, the reporter will always be the specified value. If specified with a valid JIRA user (or email address), no other reporter determination will occur. |
| reporteruser | No | X-ReporterUser | JIRA username/email address | If specified, the specified user will be the reporter if the reporter cannot be determined from the From: header. This parameter serves the same purpose as reporterusename for the http://www.atlassian.com/software/jira/docs/v3.13/issue_creation_email.html}Create Issues and Comments Handler. It is a fallback value if no other way of calculating the reporter results in a valid JIRA user. |
| supressCreated | No | X-SuppressCreated | false,true | Boolean value. If true, the "Create via email" description text will be suppressed |
reporteruser is the only handler parameter that EAH shares with Create Issues and Comments Handler
The relevant section should start with:
<property>
<key>handler</key>
<name>admin.service.common.handler</name>
<type>select</type>
<values>....And include the other Email Handlers. All 3 XML files are located in directories under
/opt/tomcat/webapps/jira/WEB-INF/classes/services/com/atlassian/jira/service/services/
EAH can set any number of custom fields with data. The data can either be static or extracted via regular expression from the input email message.
The data is read in the from the Application.properties file (/etc/certops-jira/eah/Application.properties). Each custom field processing instruction consists of three (one is optional) fields.
| Field Name | Required | Description |
|---|---|---|
| name | yes | The custom field name. This must be exact |
| value | Yes | Static data or regular expression for the value of the custom field |
| input | No | If specified, it instructs EAH what message field to use against the regular expression. Legal values are: SUBJECT, BODY |
Each custom field description set is prefixed with custom.field.N., where N is a digit. There cannot be a gap in the sequence. EAH will keep loading custom field descriptions until custom.field.N.name returns null.
Example Application.properties
custom.field.1.name=Contact Method
custom.field.1.value=Online
custom.field.2.name=InternalTracking#
custom.field.2.value=([0-9]{5}-[0-9]{3})
custom.field.2.input=SUBJECT
custom.field.3.name=cert.creator
custom.field.3.value=EAHThe regular expression must contain a capturing parenthesis. EAH will use the capture data as the value for the custom field. In the example above, the InternalTracking# value will be the text captured by ([-0-9]+).
If any errors happen with the custom fields, a warning is logged but the issue will still be created.
The CERT® Attachment Mail Hander configures log4j by: