Our new Appfire Documentation Space is now live!

Take a look here! If you have any questions please email support@appfire.com

Use cases for conditions

Owned by Radhika Vijji. (Unlicensed)
Last updated: Jun 11, 2020
4 min read

This section has use cases that help you understand the usage of the Conditions provided by JMWE.

On this page:

Current Status Condition

This condition can be used to hide/show a particular transition from the list of available workflow actions, based on the current status of the issue. 

Sample use cases:

 Disable a global transition from certain statuses

  • Add the Current status condition to the transition.

  • Select the statuses from which the Global transition should be disabled from the Current Status field.

 Block issue transition from current status to itself

  • Add the Current status condition to all the transitions of the workflow, the issue follows.

  • On each condition select the status in context

  • Select the "Reverse Condition" option

 Allow users to transition the issue to Approve status only when the issue is in Verified status

  • Add the Current status condition to the transition "Approve".

  • Select "Verified" status from the "Current status" field

 Block transition to 'On Hold' status when the issue is in 'Closed' status

  • Add the Current status condition to the transition "On Hold".

  • Select all the status(es) applicable to the current issue, except the 'On Hold' status.

Previous Status Condition

This condition can be used to hide/show a particular transition from the list of available workflow actions, based on the previous status of the issue.

Sample use cases:

 Every task should be self-reviewed before passing it to the Project lead for a Peer-Review.

  • Add the Previous status condition to the transition leading to Peer-Review status.

  • Select Self-Reviewed from the Previous Status field.

  • Check the Most recent status only and Include current status options.

 I have statuses "Open" and "In Progress" that can transition to "Information Requested" status. I want to offer an identically named transition back to the originating status

Separation of Duties condition

This condition can be used to enforce separation of duties (for SAS-70 compliance), i.e. to make sure that the same user cannot trigger two incompatible transitions on the same issue.

Sample use cases:

 Prevent a user who has triggered the "Resolve Issue" transition on an issue to trigger the "Close issue" transition.

Hide transition

This condition can be used to hide a transition from the user, so that it can only be triggered by a Transition Issue or Transition Linked Issues post-function.

Sample use cases:

 Post-functions which transition an issue have a known limitation that the transition should not be associated with any transition screen. How to overcome this?

 I want to hide a transition "Escalate" that gets auto-triggered when a code fix has been rejected.

Scripted (Groovy) Condition

This condition can be used to hide/show a transition based on a Groovy expression. 

Sample use cases:

 Only the Reporter of the issue should be able to close the issue. 

 Hide the transition from the current user if he does not belong to the Approvers

 Block the transition when the Time to resolution is breached.

 Enable the "Start Progress" only on issues in the current sprint

 Ensure at least one pdf file is attached before the issue can be transitioned

Show transition “Reject” for users of the “Management” project role and “jira-administrators” group only


Related Issues Status Condition

This condition can be used to hide/show a particular transition from the list of available transitions, based on the status of the issue's related issues. 

Sample use cases:

 Hide the "Close" transition of the Epic until all its Stories are closed.

Related Issues Condition

This condition can be used to hide/show a particular transition from the list of available transitions, based on the issue's related issues. 

Sample use cases:

 Hide the transition "In Progress" on an issue until it has at least 1 subtask under it