Summary

This guide will show how to configure a Jira/JEMHC Instance to create issues and comments when the incoming Email is being sent from another Jira Instance. This guide only shows how to replicate the issues/comments in one direction. E.g. Issues/Comments from Instance 1 will be sent to and replicated onto Instance 2 but the Issues/Comments from Instance 2 will not be sent to and replicated onto Instance 1.

Involving Second Instance within the original Issue on first Instance

In order for the Receiving Instance to receive the emails, the original issue on the sending instance would need to have the Second Instances Incoming Mail Server Address stored within the Issue (e.g. within the Email Participants Custom Field) and then have a JEMHC notification Mapping configured to send the notifications to the addresses found within the Custom Field that is storing this Address.

How to configure the Two instances

The steps below has JEMHC installed on both Jira Instances, as there is some configuration changes that are required on both instances.

Sending Instance (Instance 1)

On the sending instance you will need to create/modify the Notification templates (Create,Update and Deleted) to place IssueKey within Curly brackets “{}” instead of round brackets, this is required as the Receiving instance with use a Regexp to gather and Store this IssueKey for Issue Association (explained further into this guide).

This can be configured by:

1. Going to JEMHC > Notifications > Template Sets

   Open

   

2. Then Create/Modifying a Template. Note: If currently using the Default templates, then you will need to create a Custom Template.

   Open

   

3. Update the Subject section by replacing the round brackets with the curly brackets

4. Once this is changed and saved you will then need to change the Template within the relevant Notification Mapping within Notifications > Email

5. Now repeat these steps for the Issue Created Template

Once this has been configured you will then be able to configure the second instance.

Receiving Instance (Instance 2)

First you would need to ensure that you have followed the Getting Started Guide to configure the Inbound mail Processing, as this will create a basic Profile that has a default Mapping configured and will allow issues to be created. For more info see the getting started guide: Getting started | Setup inbound mail processing

For this instance to function correctly, you will need to ensure that the following is configured:

1. A Profile that will:

   1. Allow automated emails to be processed - by disabling/modifying the Precedence Bulk filter to allow emails from the sending instance.

   2. Will add the email Sender onto the Issue, so that they will be seen as already involved on issues. - by configuring a Sender Email Only User Custom field

   3. Store the Issue Key from the sending Instance within a Custom field.

2. Block any notifications from sending back to the Sending Instance (Instance 1), to stop echoing back changes that have been made.

Configuring the Profile

You would need to ensure that the Profile will allow Precedence bulk emails to be processed, store the Email Sender into a Custom Field (assuming the sender is not a Jira User in this Jira instance) and also store the IssueKey from the sending instance to allow issue association.

Steps to configure:

1) Disabling/Modifying the Precedence Bulk Filter

By default the Outbound JEMHC notifications will contain a Precedence Bulk header, by default this will stop the emails from being processed. To overcome this you would need to allow emails with Precedence Bulk headers to be processed, see below.

1. Go to the global Profile configuration within Profile > Profile and set the Precedence Bulk Action to Allow - to allow automated emails to created issues.

   2. If you want to only allow this for a specific sender address then you can be setting the action to Forward/drop and then setting the sender address within Precedence Bulk Included Senders.

       

2) Configure the Email Only User custom field

When the email is processed, you would need to store the sender address within the issue as this would then allow comments to be added as they will be seen as already involved which will give them permission to comment.

2. Now edit a Project Mapping and go to Email Only User and set a Custom Field that will be used to store the Sender address (assuming they are a Email Only User). Set this field within Email Sender Address Field.

   1. This would require you to create a Custom Field that is used to store this value, or you can use the auto-created JEMHC fields.

   2.  

3) Configure Foreign Key Association

This step is to extract the Issue Key from the Subject and store this within a Text Custom field. This is required as it would then allow the update notifications from the sending instance to match the existing issue on the second instance.

3. Go to Profile > Project Mapping/Rule > Pre-Processing and enable Associate Issue by foreign key

   1. Set the relevant Sender within Sender Regexes

   2. Set the Foreign Key Source to Subject

   3. Set the Foreign Key Regexp to a Regexp that will match the IssueKey of the other instance. e.g.

   4. Set the Foreign Key Field to the Text Custom Field that will store this value

   5. E.g.

4) Block Notifications from sending back to the sending Instance

The easiest way to stop the notifications from sending back to the sending Instance is to add a Global Outbound Recipient exclusion. This will mean that the Sending Instance Email Address will be able to Create and Comment on issues but they would then not be updated of any changes made to issues that they are a participant on.

To configure this you will need to go to JEMHC > Exclusions > Outgoing > Exclude email recipients and then add the Sending Instance Address as an exclusion. e.g.

Icons within Description/Comment on Receiving Instance

The Description/Comment on the receiving instance will be different to the original Description/Comment on the Sending Instance as the notifications typically contains Icons throughout the email and this can make the Description/Comment hard to read.

One way to stop this would be to create a global attachment exclusion that will stop attachment below a certain size from being added (e.g. less than 5kb). This can be configured by going to JEMH > Exclusions > Exclude Attachment and then creating an exclusion that will block attachments below 5kb. For more info about how to do this see: Excluding attachments by type, size and file name

This typically a problem when the Incoming Notification was formatted using the Jira theme as this injects icons within the email, which JEMHC will add to the issue when processed as a incoming email. Below shows how the issue description would look with and without the icons:

Testing the configuration

Testing Create scenario

To test this you would need to create an issue on the Sending Instance with the Receiving Instance Mail Server Address within the relevant Custom Field (as per the Involving Second Instance within the original Issue on first Instance section). This should then result in a notification being sent to the Receiving Instance Mail Server Address and as a result a new ticket is created with the Foreign Issue Key within the configured custom field.

Testing Comment scenario

To test this you would need to complete the above create test and then go to that issue on the sending instance and add. This should result in a comment notification being sent to Receiving Instance Mail Server Address and as a result a comment is added to the related issue.