Conditions

Conditions helps you to add different routes to your actions.

Sub condition

The app supports two logical operators:

• AND operator.

• OR operator.

Check if any of the finders fit an issue in the system

This is the most common usage of this condition. In the below example, the condition checks if the finders have any issue results.

Check if an issue is previously created by the Mail Handler

In some special cases, it should be checked if an issue was previously created. The below example represents an Update issue (Set Labels) that will be executed only IF any of the above, same-level IF conditions are true. In other terms, if the email's Subject matches the regex STM.* or TEMP.* the Labels field will be set to the added Manual value. Else, if the issue already existed before, the Assignee field will be set to a Manual value. For viewing purposes, the screenshot was added in two

Email content matches

This condition checks whether parts of the emails match with a given regexp.

The fields that can be set here are the followings:

Email part

• Body

• Subject

• Header

• To addresses

• Cc addresses

• To/Cc addresses

• From address

• From name

Header name

If the "Header" email part is selected, this field appears to allow defining the header's name. The header name search is case-insensitive. If the defined header is not present in the email, the result of this condition will be false.

Negation of the result

• matches regexp -> true if the regexp fits the selected email part. Example: Email's body: "The email content." Regexp: email Result of this condition: true

• not matches regexp -> true if the regexp does not fit the selected email part Example Email's body: "The email content." Regexp: email Result of this condition: false

Regular expression

A regular expression that fits with any part of the email. Documentation can be found here.

Issue field matches

This condition checks a field of an issue.

This condition only works correctly, if you have an existing issue at this point of the execution. If there is no issue when the execution calls this condition, the result will be false.

The following fields can be set:

Field

Currently, we support only the Status field

Negation of the result

• equals

• not equals

Value

The Field's value.

Sender has NO access to the issue

This condition checks if the sender has permission to open the issue by checking the BROWSE_PROJECTS permission. A customer also has BROWSE_PROJECTS permission if added as a Request Participant.

If the sender has no access to the page, the action in the IF statement is executed.

For proper working please be sure if there is a find or created issue in the context.

If there is no issue at this point of the execution, then the app checks the global permission of the user. For more details, please check the Atlassian documentation.

Sender is member of any of the groups

This condition checks if the sender is a member of any of the given groups.

Sender is member of any of the project roles

This condition checks if the sender has the given project role(s) in the given project.

Issue matches query

This condition allows running a JQL query on the issue in the context.

Please make sure there is an issue in the context, where you add this condition. A good practice, if you add an "Issue Exists" condition before this one.

If the JQL should contain a user, please select "Insert user" option below.

Email sender is unkown

This condition checks if the sender has a user account on the Jira instance.

If the sender has no user account, the action in the IF statement is executed. Disabled users are handled as non-existing.