Configure an Event-based action

When you create or edit an Event-based Action, the Event-based Action Editor will open (Figure 1, right). The Event-based Action Editor uses the JMWE Automation Rule Builder, consisting of two side-by-side panels; the left panel has buttons for selecting each configuration category (e.g. When for the event that triggers the action), and the right panel includes specific configuration options for the selected category.

To configure an Event-based action, set the following configurations:

1. Action name (Point 1, Figure 1, right) - Required. Click the name to edit. Enter a meaningful name and hit Enter, or click the check button to save.

2. Description (Point 1, Figure 1, right) - Click Add a description to edit the Scheduled Action description. Enter a detailed explanation of the action and click the check button to save.

3. When/Event (Point 2, Figure 1, right) - Click the When header or the Event button. In the right panel, select the event that will trigger the action. See the Events section of Event-based Actions for more information.

   1. Ignore events caused by JMWE post-functions and actions - Check this box to prevent the Event-based action from triggering when another JMWE post-function or action runs.

   2. Ignore events caused by Jira Automation and other apps - Check this box to prevent the Event-based action from triggering when the event is caused by a native Jira Automation or other app.

4. If Scope/Projects (Point 3, Figure 1, right) - Click the If Scope header or the Projects button to configure which projects will trigger the Event-based Action; only events on issues within the selected projects will trigger the action. See Projects and Issue Types, below, for more information.
   If you do not select a specific project(s), issues from all projects will trigger the action.

5. Issue Types (Point 4, Figure 1, right) - Click the Issue Types button to configure which issue types will trigger the Event-based Action. See Projects and Issue Types, below, for more information.
   If you do not select specific issue type(s), all issue types will trigger the action.

   1. Only apply to issues that match a JQL filter - Check this box to use a JQL query to filter the issues that should trigger the action.

   2. Only apply to issues that match a Nunjucks condition - Check this box to use a Nunjucks condition to filter the issues that should trigger the action.

6. Then/Post-functions (Point 5, Figure 1, right) - Click the Then header or the Post-functions button. In the right panel, select a post-function from the list to add the first post-function, or click Add post-function to add additional post-functions. See Post functions, below for more information.

   1. Skip subsequent post-functions if a post-function encounters an error - Check this box to stop the execution of the Event-based Action if any of it’s post-functions encounter an error.

Projects and Issue Types

Configuring which projects and issue types will trigger your Event-based Action, both work the same way. You can use the pull-down menu at the top of their list to browse the list or start typing to search for specific projects and issue types. Check the box next to the project or issue type to add it; click the X next to its name in the list to remove it.

Alternately, you can click Select Projects/Select Issue Types to open a window listing all of your Jira projects or issue types (Figure 2, right). Select or deselect the projects or issue types and click Add.

You can further filter the issue types that will trigger your action by using the JQL and Nunjucks filters. When either of these boxes are checked, a new field will appear - JQL or Nunjucks. Click these fields to open the JQL Filter/Nunjucks expression window, where you can enter the query or template and preview its results. Click Save to save the query or template and apply it to the action.

For more information on using JQL queries, see Using Jira Expressions.

For more information on using Nunjucks, see Using Nunjucks Templates.

Post functions

For each issue included in the Event-based Action (see Projects and Issues, above), the configured post functions will run in the order in which they are listed.

When editing an existing Event-based action, the right-hand panel for Post functions includes several buttons for working with the post functions within the action:

• Filter - Filter the list of post functions by type.

• Advanced view/Simple view - Switch between views. See Post function views below for more information.

• Expand all / Collapse all - Only available in Advanced view. Expand or collapse all post function tiles.

Add a post function

The post function list includes a set of Recommended post functions at the top of the list. Based on the most commonly used post functions as well as the other post functions currently added, this list will help with discovery of post functions you may need.

1. For the first post function added to an Event-based action, simply click the post function in the list to add it. Alternately, in the right panel, click Add Post-function at the top of the panel.

2. Select a post function from the list and click Add. You can search for the post function by name using the Search field at the top of the list.

3. The post function configuration window will open. Configure the selected post function as needed, then click Save. See Post functions for more details on all of the available post functions.

Modify or delete a post function

The steps to modify or delete a post function depend on the post function view you are using. See Post function views directly below for more information.

Play the Arcade

Post function views

Pass variables within a sequence

It is possible to pass data from one post function to all subsequent post functions within an Event-based Action by using the {% setContextVar %} Nunjucks tag. When using a Build-your-own (scripted) post function, the variable can be set anywhere within your script; when using other post functions, the most common place to set a variable is in the Conditional Execution configuration.

• context: Holds all the context variables added in the current post function. For example, if you create a context variable myVar in the first post-function of the sequence:

  {% setContextVar myVar = "a value" %}

  This variable will then be available to all its subsequent post functions as:

  {{ context.myVar }}

   

Variables specific to the Create Issue post-function

• newIssueKey: Stores the issue key of the last issue created by a Create Issue(s) post-function in the action. You can access it as:

  {{ context.newIssueKey }}

   

• newIssueKeys: Stores an array of the keys of all the issues created by any Create Issue(s) post-function in the action. You can access the created issues from

  {{ context.newIssueKeys }}

  For example: to add a comment on the current issue with the keys of the issue created

  Issues created are: {{ context.newIssueKeys | join(",") }}

You can access the information of a specific issue using the issue filter. For example: To get the assignee of the issue created by the Create Issue(s) post-function

Pass context variables to an Event-based action

Variables specific to the current transition

If a post-function for the acton is run during a transition, information about the transition is accessible.

Access these variables using the prefix context.. For example:

This returns ID of a transition. The following information is available:

• transition.transitionId: Stores the ID of the transition.

• transition.transitionName: Stores the name of the transition.

• transition.from_status: The status from which the current transition starts.

• transition.to_status: The status to which the current transition leads.

• transition.workflowName: The name of the workflow to which the transition belongs.

• transition.workflowID: The ID of the workflow to which the transition belongs.

Variables specific to Comments

If the post-function is run during a transition, any comment that was entered on the transition screen is available. 

The newly created comment is available if the post-function is run during an action triggered by an Issue Commented event.

• context.comment.body: The body of the comment, as text with wiki markup.

• context.comment.created: The date/time the comment was created.

• context.comment.author.accountID: The account ID of the author of the comment.

• context.comment.author.displayName: The display name of the author of the comment.

• context.comment.jsdPublic: Determines if the comment is shared with Customers (for Jira Service Management projects).

Variables specific to Attachments

If the post-function runs as part of an Event-based Action listening to the attachment_created or attachment_deleted event, the attachment added or deleted is available through the context.attachment variable.

Access these variables using the prefix context.. For example:

This returns ID of an attachment. The following information is available:

• attachment.filename: Stores the filename of the attachment.

• attachment.id: Stores ID of the attachment.

• attachment.created: The date/time the attachment was created.

• attachment.size: The size of the attachment.

• attachment.mimeType: The mime-type of the attachment.

• attachment.author.accountId: The account ID of the user adding the attachment.

• attachment.author.displayName: The display name of the user adding the attachment.

Variables specific to Issue Links

If the post-function runs as part of an Event-based Action listening to the issue_link_created or issue_link_deleted event, the issue link added or deleted is available through the context.issueLink variable.

Access these variables using the prefix context.. For example:

This returns the issue link type of the link being added. The following information is available:

• issueLink.sourceIssueId: The issue ID of the source issue of the issue link being added or deleted.

• issueLink.destinationIssueId: The issue ID of the destination issue of the issue link being added or deleted.

• issueLink.issueLinkType.name: The issue link type of the issue link being added or deleted.

Variables specific to Work Log Links

If the post-function runs as part of an Event-based action listening to the worklog_created, worklog_updated, or worklog_deleted event, the worklog data is available through the context.worklog variable.

Access these variables using the prefix context.. For example:

This returns the date and time of when the worklog was created. The following information is available:

• worklog.timeSpent: Work Log string added/updated/deleted.

• worklog.timeSpentSeconds: Work Log in seconds added/updated/deleted

• worklog.comment: Comment added/updated with the Work Log.

• worklog.created: The date/time the worklog was created.

• worklog.updated: The date/time the worklog was updated.

• worklog.started: The date/time the worklog was started.

• worklog.author.accountId: The accountID of the user adding the worklog.

• worklog.author.displayName: The display name of the user adding the worklog.