Create Issues (from JIRA 7.0)

Summary

Application Access and Issue Creation

From JIRA 7, application access is taken into account on top of project permissions.  If the user has access to one application, they can in theory create issues in the other two applications (see here for more information).

You want to create issues with emails coming from a particular person.  This person could be anyone - from a JIRA account holder with full access and permissions, to a non-JIRA email user with no JIRA account.  In this article, we will cover the possible methods of issue creation with JEMH, and the expected outcomes of the creation process in each case.



Understanding the different types of sender

In order to configure JEMH optimally, it is best consider who is sending mails to be processed and target your configuration appropriately.  These persons can usually be split into two groups:

Non-JIRA User

This is an email sender whose email address is not associated with any user account in the JIRA instance.

JIRA User

This is an email sender whose email address is associated with a user account in the JIRA instance.   The JIRA user can have varying levels of credentials:

  • With Issue Permissions and Application Access (Core/Software/Service Desk)

  • With Issue Permissions and NO Application Access at all

  • With NO Issue Permissions and Application Access (Core/Software/Service Desk)

  • With NO Issue Permissions and NO Application Access at all



Creating Issues with Non-JIRA Senders

A Non-JIRA sender has no permissions or access to JIRA.  Therefore in order for their emails to be made into issues, we need to set up a default reporter user in the JEMH profile.  This user has the permissions to create and edit issues in the target project.

  • The email sender can have their address and personal name (if given) in custom fields.



Creating Issues with JIRA Users

JIRA Users with issue permissions and with access to a JIRA application

When a JIRA User sends an email to JEMH, they create the issue and are set as the reporter of the issue.

  • The email sender user can be added as a watcher on the issue

  • The email sender user can be added to a multi-user picker field

  • The email sender user address can be added to a field

JIRA Users with issue permissions and with no access to any JIRA application

In order for emails sent by these users to result in issue creation, the setting Treat Unprivileged JIRA Users as Non-JIRA needs to be enabled.  This is done by going to your Profile and editing the Security section.

When a JIRA User sends an email to JEMH, the Default Reporter is used to create the issue.  Then, the JIRA User sender is set as the issue reporter.

  • The email sender can be added as a watcher on the issue

  • The email sender can be added to a multi-user picker field

  • The email sender address can be added to a field



JIRA Users with no issue permissions and with access to a JIRA application

In order for emails sent by these users to result in issue creation, the setting Treat Unprivileged JIRA Users as Non-JIRA needs to be enabled.  This is done by going to your Profile and editing the Security section.



When a JIRA User sends an email to JEMH, the Default Reporter is used to create the issue, and is also set as the issue reporter.

JIRA Users with no issue permissions and with no access to any JIRA application

When a JIRA User sends an email to JEMH, the Default Reporter is used to create the issue.  Then, the JIRA User sender is set as the issue reporter.

  • The email sender can be added to a multi-user picker field

  • The email sender address can be added to a field