2 - Triggers & Conditions
On this page, you will be able to set up what triggers and condition for the integration.
In addition to this there is also the possibility to use Postfunctions to trigger a integration.
Issue Event Trigger(s)
Scheduled Job Trigger
Contextual JQL Condition
Misc Conditions
Parent
Issue events
Choose the Jira issue event that shall trigger this Integration.
Condition | |
|---|---|
Selected Event | The event triggered when updating, creating or transition an issue |
Run only on these project(s) | Limit the event handler to only run on the specified projects, this check will be done directly after the event is triggered. |
Trigger only if actor of the event is | This check will run after the “Run only on these project(s)” condition and limits the integration to run only if a specific user is the actor or not depending on the operator. Operator EQUAL means the user must be the user triggering the event Operator NOT EQUAL means the user must not be the user triggering the event This is useful for many case, one could be to not make circular calls where a bot comments the issue and an event listen to comment event and comments the same ticket again. |
Field changed condition | This check is done after the “Trigger only if actor of the event is” and check if a certain field was changed during the event. This is useful to determine if a certain field was changed when the issue was edited |
JQL Condition. When to execute the event(s) | JQL clause to limit the condition event. |
JQL Condition User. User that will be used to run the JQL search. If not set the JQL condition will use current user as actor | In some locked down projects and servicedesk it is not always the case that the user performing the event has permission to run a certain JQL query, in these cases use a actor that performs the search. |
Attachment Condition | This checkbox condition will trigger the integration only if there is an attachment available on the issue. When sending attachments to remove systems the call is done as a multipart, sometimes there is a need to limit it to only send if an attachment is present on the issue. |
Scheduled Jobs
If you need your integration to run on a scheduled basis, enter a cron expression and/or the optional JQL expression. NOTE: If a JQL expression is used a user has to be selected as well. (this is because Jira requires a user when evaluation JQL conditions)
We recommend using https://www.freeformatter.com/cron-expression-generator-quartz.html to evaluate your crons.
To run the search select a user that has access to the project that is searches.
Enter a JQL to search for the issues.
When the schedule runs, it will automatically search for issues using JQL and perform the specified action on each matching issue.
Contextual JQL Condition
Contextual JQL can be used from either an incoming request or a parent → child relationship, where you would like to run the child only when a certain JQL condition is met, but the parent could run always. Usually used when you have a login call and that gets a token which needs to be passed to the children.
Parent child
Consider the image above where you need to Login to plan view and perform either a get attribute or update field call. Both calls needs to use the logged in token from the login call. But should never be triggered the same time. To achieve this you can use the Contextual JQL Condition and specify a JQL when to do a get or update. Example when the issue is in status=New it might fetch the attribute and when it is done it might update the attribute.
The Contextual JQL has the response and the triggered issue (scope) available to use as variables in the JQL field, example: priority={{issue.priority}}.
Incoming Webhook request
If and when this integration is part of an Incoming HTTP Rule, (see https://rixter.atlassian.net/wiki/spaces/RIFJ/pages/1134755875 ) define the JQL condition here.
The Contextual JQL is a powerful feature in Jira that allows you to search for issues that meet certain criteria and then perform actions on them. When an Contextual JQL query is triggered by an incoming request, it will search for issues that meet the specified JQL criteria and automatically run the configured action if any hits are found.
To ensure that the correct issues are targeted, the action will automatically surround the JQL query with "key=issue-key AND (your JQL)". The issue key is taken from either the URL when posting to a Jira URL with issue key or from the body of a payload.
URLs that are checked is
/rest/api/2/issue
/rest/servicedeskapi/request
If neither of these is present in your use case, you can add the key={{your_variable}} into the JQL search box. This will translate the issue key from the incoming payload, ensuring that the correct issues are targeted.
Using variables in the JQL search box can also be useful for other purposes, such as checking reporter = {{currentUser}} or Label in ({{my_label}}). To determine what a variable is named, you can check the incoming log and look at the payload received. The same name as the payload variable is used for the variable in the JQL search box.
By using Contextual JQL to run actions in Jira, you can automate your workflows and streamline your processes, making it easier to manage and track issues across your organization.
Parent
If this integration has a parent, only trigger if the Parent HTTP response code is any of the ones entered as conditions. This is optional to fill in.