Please note that we no longer offer support for this app as it has been removed from the Marketplace.
Content
Prerequisites
JIRA version 6.4.12 and higher
Conditions
1 - Issue Type Condition
Allows transition only if the issue is (not) of specified Issue Type(s) |
Configuration options
- Allow or deny transition
- IssueType(s) to allow or deny from
Use Case
- If you have one general workflow for all your issue types, but you want to make an exception for one (or more) issue types, i.e. to add or remove an additional approval step. Instead of creating and maintaining a separate workflow, this condition allows you to build this functionality into the existing one. It allows you to keep the number of workflows small and easier to maintain.
2 - Status Condition
Allows or denies the transition based on the current status of the issue |
Configuration options
- Allow or deny transition
- Status(es) to allow or deny from
Use-Case
- This is an easy way to use global transitions more often. For example: if you have a global transition to a clarification/estimation status, then it would be best to deny this transition from the resolved and closed status, as the work is already done there.
3 - Version State Condition
Condition to allow transition only if the version(s) of an issue field is (not) in a specified state (Released, Unreleased, Archived) |
Configuration options
- Select field (Fix Version, Affected Version, all version custom field types)
- Choose condition (all, one, no version must have the selected state)
- Select Version State (released, unreleased, archived)
Use Case
- Only allow working on a new feature issue if it has an unreleased fix version
- Require an issue to have a not-archived affected version
Validators
1 - Version State Validator
Validates that the version(s) of an issues field is (not) in a specified state (Released, Unreleased, Archived). A predefined message is displayed, if the validation fails. |
Configuration options
This validator has the same functionality as the Version State Condition
Additionally a validator message can be configured, that is displayed when the validation fails. The validator message is automatically generated depending to the configuration, but can be overwritten.
Post-Functions
1 - Add Text To Transition-Comment Post Function
Adds a specified text to a comment, depending on a user-defined field. The comment can contain field names as placeholder. E.g. %{custom field name}. |
Configuration options
- Field to Check - select a custom field to make the adding of the comment dependent on whether the field is filled in or not
- Add text if field is
Use Case
- Adding a comment e.g. with this text: "This issue has been postponed until {Reopen Date} with the following comment:" when moving to an On Hold status
2 - Copy Field From Parent Or Epic Post Function
Copies a field value from the parent issue, in case issue is a subtask, otherwise from linked Epic |
Configuration options
- Field to copy
3 - Copy Field From Previous Subtask Post Function
Copies an issue field value from the previous subtask of the related parent issue. |
Configuration options
- Field to copy
This page was last edited on 04/18/2024.