Configuration

For a streamlined guide on setting up JEMH for issue creation via email in JSD 3 onwards, see Create Issues (Jira Service Desk 3).

Setting the Customer Request Type

In order for email (a.k.a Non-Jira) users to create fully functional requests in Jira, the Service Desk custom field Customer Request Type must be set with a specific value.  This value has the format projectkey/requestid.  By default this field is not visible on edit screens.

All Emails to a single Request Type

Setting a JEMH Default Custom Field value to Default Project Mapping will cause all issues being created to have that custom field value, so setting Customer Request Type to default001 will do that, see the JEMH Profile > Default Project Mapping > Custom Field Defaults section:

Open

Request Type defined through Project Mappings

JEMH Project Mappings allow routing of emails to projects.   With Service Desk this method also gives you the opportunity to route incoming email into a defined Service Desk queue.  Defining the Customer Request Type can be done at the per-Project Mapping level which then becomes the default for all Mapping Rules unless overridden:

Open

Each Mapping Rule could then provide a different value, for example:

Use of Directives

JEMH Directives can also be used to set the field remotely, JEMH Aliases can be used to simplify this to #servicedesk or similar.

Example: Email only (no account)

Here is a JEMH Test Case, it has no special directives defined, the project mapping above will be used (with serv/default003 as a value):

The post-execution screen shows which Domain Rule fired:

Going to the created issue (with the Customer Request Type field visible):

As 'admin' switching views to the Service Desk, the new issue is present, and can be managed through the Service Desk UI:

The Edit option allows new columns to be added:

So, adding the Email Users custom field allows you to see who the email came from, even including the 'personal' part of the email address if stored:

Notifications

Where email users are concerned, the JEMH Default User is used as the context for the operation, this is the user who will receive email notifications via Service Desk.  With JEMH configured for non-JIRA support already, nothing changes, and standard IssueEvent notifications occur:

Example with Service Desk User (with account) by email

The Portal Access user that came in with JSD 2.2 introduces some problems:

•   https://jira.atlassian.com/browse/JSD-1473 Issue Creation for Portal Users fails through the API, this requires the workaround below

•  Using this workaround, it is possible for any user to send an email into an issue with an issue key, and have that added as a comment.  Issue Security Schemes don't appear to help.

The following is the current workaround configuration:

 JEMH v 1.6.49+ required

Process

1. Create an auto-join group, e.g. servicedesk-customers which is not used elsewhere
   
   

2. Modify JEMH Profile set set the Customer Request Type custom field (described in the first section)

3. Modify JEMH Profile

   • set User > Create users : ON

   • If your users all exist externally, not in a common LDAP repository set User > Create UserID from: email. Users in LDAP wont be created as they exist already, the next step will do what remains

   • set User > Auto Join Group(s) to refer to servicedesk-customers and set the User > Auto Join Group Condition to be "For All JIRA Users"
     
     
     

     
     
     

4. Modify Project Role

   • Go to your service desk project and then edit Users and Roles in Project settings

   • Select Add users to a role and select the JEMH auto-join group, so that users who create issues by email without first subscribing, automatically get allocated that group, this role, and are therefore able to create issues etc.

      

5. Modify the Permission Scheme, granting the servicedesk-customers group the below permissions.  If you give "Project Role (Customer)" permissions in the scheme instead, public sign-up will be disabled by JSD.

   
   
   

Commenting

Who gets internal notifications?

Any comment that is marked as internal will not be sent to Non-Jira users, achieving the intent of the JSD internal comment function.  JIRA account holders found to be in the Service Desk Customer role will not be notified of internal JSD comments.  Users who are designated as Service Desk Agents, or authorized Software/Core users will also get notified of internal comments.

Before version 1.6.50, JEMH would not be able to detect that an internal comment was made via Service Desk and therefore the above did not apply.

Controlling visibility of comments

Comments made by Service Desk Agents via JEMH are internal by default.  However, this behaviour can be changed on a per-project basis by changing the setting Profile > Project > Project Mapping > Comment > Agent comment visibility.  If Directives are enabled for comments and a suitable Field Processor is also enabled, then agents can set the visibility of their comment from the email itself during its composition.

For example, with the @Prefix field processor enabled the following would set the comment to be public:

@ Prefix Field Processor example

In your profile, you could create aliases for the directive to allow simpler usage by agents:

The above 2 alias configurations (with the @prefix field processor enabled) would allow agents to then use @internal or @public in their email body to set their comment as internal or public respectively.

Including email recipients

terminology recap:

• “email user” or “non-jira user” : have no account at all, who cannot login to Jira or the JSM portal

• “Jira user” : have accounts, of some kind in the instance, whether they are portal users or interactive Jira users.

When a user emails into a JEMH managed mailbox, additional recipients of the message can be added to the created issue (or on update, if the sender is already involved), exactly how additional recipients are managed is controlled through the Profile > Email > Addressee Processing section, shown below:

Addressee Handling is the primary driver to describe how email addressees are handled. In JSM, two fields are usually involved:

1. Selecting toCustomField will enable support for email-only non-Jira user support (email notification of updates but no ability to access the portal), where recipients are automatically merged into a text multi-line custom field (3, above).

2. Selecting toJSDRequestParticipants will enable support for Request Participants, the addition of users here is subject to the filter (2, above).

Request Participants

The Service Desk project admin can set 'customer permissions (screenshot below), this security setting affects JEMH.

Jira is the gatekeeper of security and will reject issue update requests (by JEMH) if they violate security choices. Settings are found within the JSM Project > Customer permissions section.

“Customers who are added to the project”

When set, Jira will deny any Jira user that may exist in your site but are not actually added as customer to this particular Service Desk:

Prior to 3.3.63 Jira would reject attempts by JEMH to set customers who were not authorized, resulting in emails being Forwarded.

since 3.3.63 JEMH can be configured to react to such users, allowing exclusion (registered customers only) or partial inclusion (treating such customers as non-jira) - enabling this support does mean ‘email user support’ is also enabled.

“Customers who have an account on this Jira site”

When set, Jira will allow any Jira user to be added as a request participant. If addressees are found that do not have accounts, they will simply be excluded. Only when non-Jira support is enabled would they become involved as email only.

This is historic behaviour:

Email Processing Report Messages

since 3.3.63

When users are added as Request Participants:

When a user is not authorized and is added as a non-jira email user:

When a non-customer user is excluded when either toCustomField is not enabled or a custom field is not defined for “Assign non jira-user Email to Text Custom Field”:

Related articles