Conditions
Conditions helps you to add different routes to your actions.
Sub condition
The app supports two logical operators:
All -> represents the AND operator.
Any -> represents the OR operator.
Issue exists / Issue is NOT found
The app checks if any issue exists that is related to the email. There are two behaviors of these conditions.
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.
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.
Last updated