Route Jira user and Non-Jira user addresses into custom fields
For an end to end tutorial see Enable non-Jira Account holders to receive issue updates
Scenario 1: Jira user sender
For convenience you want to:
extract JIRA users sender email address, store in 'jira sender Email' custom field (text single line type)
extract NON-Jira recipients email addresses, store in 'Non Jira participants' custom field (text multi-line type)
add any JIRA users who are recipients as watchers
Test case mail
The below TestCase email will be used for the example, the sender bob@yourco.net is a Jira user, the first cc, tim@yourco.net is also a JIRA user. The addressees user1@faraway.com and user2@farawayother.com are not registered in JIRA.
MIME-Version: 1.0
Received: by 10.223.112.12 with HTTP; Sat, 18 Jun 2011 22:42:26 -0700 (PDT)
Date: Sun, 19 Jun 2011 17:42:26 +1200
Message-ID: <BANLkTinB1mfSh+GwOXGNWoL4SyDvOpdBoQ@mail.gmail.com>
Subject: Example email
From: "Bob Local" <bob@yourco.net>
To: notest@localhost
Cc: tim@yourco.net, user1@faraway.com, user2@farawayother.com
Content-Type: text/plain; charset=UTF-8
some text
Configuration
For this scenario, a project TEST is defined, and set to be the default through Project > Fallback Project
so that issues will be created there. As a Jira sender is involved in this example, no Default reporter is required.
Custom Field need to be created to store the data:
Jira participants, a multi user picker
Non Jira participants, a text (unlim) field for storing non-Jira email addresses
jira sender Email, a text type
Email Settings need to be made to store the data:
CatchEmail
If no address is defined as a catchmail the TO: address that was used to send the mail to JIRA will end up in a non-jira user custom field this creates an email loop! To avoid this, set the catch email address to match the inbound address. If multiple address/sources are used, they can be defined as comma separated values in the JEMH Addressee regexp field.
Sender Processing: jira-user
Assign Sender JIRA User to Multi User Picker CustomField: JIRA participants
Assign Sender JIRA User email to Text CustomField: jira sender Email
Addressee Processing
Addressee Handling: toWatcher and toCustomField (multiselect)
JIRA account holders to MultiUser Custom Field: JIRA participants
Non JIRA account holder to a Text CustomField: Non JIRA participants
Created Issue
The created Issue has the following attributes set:
Details
Non JIRA particpants: user1@faraway.com,user2@farawayother.com
jira sender Email: bob@yourco.net
People
Reporter: Bob Local
JIRA participants: Tim Local
Watchers
With the Addressee Handling set to include toWatcher, normally this would only include tim@localhost, however, due to the default issue settings and Add Sender As Watcher, we have two users present as watchers:
Issue Settings
Watchers
Scenario 2: Non-JIRA User Sender
With a Non-JIRA sender, the simplest solution is to set a Default reporter under the User Settings.
Reworking the previous TestCase:
MIME-Version: 1.0
Received: by 10.223.112.12 with HTTP; Sat, 18 Jun 2011 22:42:26 -0700 (PDT)
Date: Sun, 19 Jun 2011 17:42:26 +1200
Message-ID: <BANLkTinB1mfSh+GwOXGNWoL4SyDvOpdBoQ@mail.gmail.com>
Subject: Example email
From: "Uri User" <user1@faraway.com>
To: notest@localhost
Cc: user2@faraway.com,user3@farawayother.com
Content-Type: text/plain; charset=UTF-8
some text
The configuration for this scenario requires some more custom fields and configuration, namely:
non jira sender Email
non jira sender Name
Created Issue
When executed, the TestCase produces the following results:
Details
Description, containing a prefix indicating who made that particular description/comment. It doesn't seem like much here, but when one of the other non-jira recipients replies to the issue created email, that comment will be prefixed with their details.
Non JIRA particpants: user1@faraway.com,user2@faraway.com,user3@farawayother.com
non jira sender Name: Uri User
non jira sender Email: user1@faraway.com
People
Reporter: Admin
Watchers
NONE
Scenario 3: Add Organization member (sender of the email) to the Request Participants field
Since 3.3.48-Server Since 3.3.49-Dc
In this example, we will show the ability how to add the sender of the email who is also part of the Organization which is set on the issue, to the Request Participant field.
To be able to add sender to the request participants field, make sure that Request type is set on the issue.
Enable Profile Config
Navigate to JEMH > Profile > Email > Sender Processing and enable Add Organization member as Request Participant
Result
When the sender who is a member of the organization as per example comments on the issue
Organization members
he will be added to the Request Participants field as per example