Jira Misc Workflow ExtensionsFor Jira Server

Implementing advanced workflows without code

Start Free Trial Now

 

Building Workflows Without Code

Workflows are essential for the success of the business. They automate business rules to auto-assist users in deciding when one step has been completed successfully and the next step can begin. JMWE for Jira Server provides a collection of workflow conditions, post-functions, and validators giving you all the building blocks you need to extend your workflows without code to support any number of business use cases.

Below you can view the list of JMWE post-functions (as well as Jira pre-installed optional post-functions), and the list of all conditions and validators available in JMWE for Jira Server.

For the most updated list and for more information, please refer to this page in the documentation

Workflows for JIRA Server
 

image

Atlassian Verified

 

Conditions

Previous Status Condition 

Allows you to disable a particular transition (hiding it from the list of Available Workflow Actions) if the current Issue either:

  • has never been in the specified Status
  • or was not in the specified Status just before it entered the current Status (if "Most recent status only" is checked).

Use Case: A typical use for this workflow condition is when you can reach a certain Status from several other Statuses (through the same Transition) and want to be able to return to the originating Status. Consider the following partial workflow:

Jira will allow you to create a single Transition from both Open and In Progress statuses to the Waiting for clarification status. But how do you create the transition (Provide info) back to Open and In Progress? And, more importantly, how do you make sure the issue is transitioned back to the originating status? With “Previous status” condition.

Separation of duties condition

Enforces separation of duties (for SAS-70 compliance), i.e. that make sure the same user cannot trigger two incompatible transitions on the same issue. For example, you can prevent a user who has triggered the "Resolve Issue" transition on an issue to trigger the "Close" issue.

Hide transition

The purpose of the Hide Transition workflow condition is to hide a transition from the user, thus preventing the user from triggering it, while making it available to the Transition Parent Issue function or to scripts or remote API calls.

Scripted (Groovy) condition

Hides/shows a transition based on a Groovy expression.

Linked issues status condition

Allows you to hide/show a particular transition from the list of available transitions, based on the status of the issue's linked issues.

More information about JMWE Conditions can be found here.

 

Validators

Field has been modified validator

Forces users to modify a field during a transition.

Field is required validator

Forces a field to have a value during a transition. You can optionally customize the error message displayed if the field has no value.

Comment required validator

Forces users to enter a comment during a transition. If they don't, a customized error message will be displayed.

Field has single value validator

Checks that a multi-valued field does not contain more than one value during a transition.

This can be useful, for example, to make sure users don't select more than one "Fix version" during the Resolve transition.

Previous status validator

Makes sure the issue has been in a specified Status before.

Parent status validator 

Ensures that the current issue's parent issue is in one of the specified Statuses. This is useful only for sub-tasks.

Scripted (Groovy) validator

A workflow validator that is based on the result of a Groovy expression. If the Groovy expression returns false, a validation error message will be displayed.

Linked issues status validator

Ensures that the current issue's linked issues are in one of the selected statuses. For example, you can prevent an Epic to be closed until all of its Stories are closed.

More information on validators can be found here.

 

POST-FUNCTIONS

Field Updating Post-Functions

Jira standard post-functions

  • Update Issue Field (*DOES NOT UPDATE CUSTOM FIELDS) - Updates one of the issue's fields to a given value. Fields that can be updated include: Assignee, Description, Environment, Priority, Resolution, Summary, Original Estimate, Remaining Estimate.

JMWE post-functions

Increase value of field

Increases the value of a numerical field by one

Set field value from user property value

Sets the value of a selected field of the current issue to the value of a User Property of the current user.

Set field value

Sets the value(s) of a selected field of the current issue. The value can be either a constant or the result of the evaluation of a Groovy expression or the result of a Groovy template.

Copy field value to parent 

Copies the value(s) of a field into the same field of the issue's parent issue.

Add field value to parent 

Adds the value(s) of a multi-valued field (such as Fix version(s)) into the same field of the issue's parent issue or from an Epic to its Stories (or vice-versa).

Copy field value from parent 

Sets a field value to the value(s) of the same field of the issue's parent issue.

Copy field value to linked issues 

Copies the value(s) of a field into the same field of all issues linked to it through a specified link type. You can also use this function to copy a field from an issue to its sub-tasks, from an Epic to its Stories, etc.

Copy value from field to field

Copies the value(s) of a selected field to another field of the same issue.

Create/clone issue

Creates a new issue. The specifications of the issue to be created can be customized using the options provided.

Copy field value from linked issues 

Sets a field value to the value(s) of the same field of an issue linked to it through a specified link type.

Set field value of linked issues 

Sets the value(s) of a field on all issues linked to the current issue through a specified link type. The new value can be either a constant or the result of the evaluation of an arbitrary Groovy script. You can use this function to set the value of a field on the Epic of an issue, or on all issues of an Epic. You can also use this function to set a field of all sub-tasks.

Set issue security from user role 

Sets the issue security level based on the Project Role to which the current user belongs.

This function can be used on the Create transition to set a different issue security level depending on whether the issue is being created by an internal user or by an external user (e.g. a customer)

Scripted (Groovy) operation on issue

Executes an arbitrary Groovy script against the current issue.

Link issues to the current issue

Links the current issue to all issues that satisfy a parameterized JQL query.

Unlink issues from the current issue

Unlinks issues from the current issue based on the result of a Groovy condition.

 

Communications Post-Functions

Jira standard post-functions

  • None

JMWE post-functions

Email issue 

Sends an email to certain recipients specified in the post-function configuration.

Comment issue 

Creates a Comment on the current issue. The text of the comment can be either a fixed text, or the result of the evaluation of an arbitrary Groovy script.

Comment linked issues 

Creates a Comment on linked issues. The text of the comment can be either a fixed text, or the result of the evaluation of an arbitrary Groovy script.

 

Assignment Post-Functions

Jira standard post-functions


  • Assign to current user - Assigns the issue to the user who is executing the transition.
  • Assign to lead developer - Assigns the issue to the component lead, if one exists, or project lead.
  • Assign to reporter - Assigns the issue to the user who created the issue.

JMWE post-functions


Assign to role member 

Assigns the current issue to the default member of the specified project role.

This can be used for scenarios like: "when a developer resolves the issue, assign the issue to the QA lead".

Assign to last role member

Assigns the current issue to the latest Assignee (excluding the current one) who is a member of the specified project role. If it finds a user that belongs to the specified role, it assigns the issue to that user. Optionally, it can consider the Reporter and/or the Current Assignee in addition to previous assignees.

This can be used for scenarios like: "when QA fails to assign the issue to the last developer who worked on it".

 

Transition Triggering Post-Functions

Jira standard post-functions

  • None

JMWE post-functions

Transition Issue 

Triggers a named transition on the current issue. This can be used to move the current issue one step further in the workflow, if a condition is fulfilled.

Transition parent issue 

Triggers a named transition on the parent issue of the current sub-task.

Transition linked issues 

Triggers a named transition on issues linked to the current issue through a specified link type. The Transition Linked Issues post-function can also be used to transition sub-tasks.

More information on post-functions can be found here.