JIRA Workflow Toolbox allows to do things you wouldn't believe possible that easily.
You can trigger a transition on every linked issues and subtask, or on a certain subset of linked issues and subtasks, defined by issue type, issues status and project belonging. This way you make them progress through its workflows.
It is possible to set the value of a field based on the values of another fields. For example, we could set the value of a custom field Urgency based on issue Priority and the value of another custom field called Impact.
Using a post-function you will be able to create one or multiple new issues and subtasks when executing a transition in your workflows. You can also set the fields of the new issues based on the values of fields in other issues, and link the new issues to the other issues in your JIRA instance.
- Creating Stories in an Epic
- Create a Subtask on each Story of an Epic
- Create a Story for each Component in Epic
- Create 3 Tasks in 3 different Projects
- Create a Sub-task for each User selected in a Multi-User Picker
- Create specific Sub-tasks for each selected Component
You can compose free text by inserting, where you need it, the values of custom fields and of more than 50 virtual fields available. For example, you could compose a text to be inserted in the issue at the moment of certain transition execution.
Assign an issue to a user in a project role. In case there are more than one user with the project role, you can set a user as default for a project role in a project. You can use this functionality with every post-function in the plugin that allows you to write on any field of type User or Multi User.
You can add or remove single or set of items from fields of type Multi Select, Multi Checkbox, Multi User Picker, Multi Group Picker, Components, Affected versions, Fixed versions and Version picker.
You can block or hide a transition depending on existing issue links (which issue link types and how many there are), the issue types of linked issues, its statuses, and the projects they belong to.
It is possible to add conditions and validations depending on complex time expressions (day of the week, day to the month, time intervals, etc).
Automatically insert a work log for the time passed since triggering of Start Progress transition to triggering of Stop Progress transition.
A transition in parent issue can be triggered when certain subtask transition is executed. We are going to use that feature to close parent issue automatically, when the last of its subtasks is closed.
Other related examples:
- Close Parent Issue when all Subtasks are Closed
- Moving Story to "In Progress" when one of its subtasks is moved to "In Progress".
- Moving Story to "Ready for QA" once all its subtasks are in "Ready for QA" status.
Special issue link types provided by JIRA Agile are also supported.
We want to prevent issue creation when there is already another issue in the project with the same value in a certain field. That field works as a kind of alternative issue key in the project.
You can easily extend this example to much more complex cases, like preventing coincidence of values in more than one field at the same time, or in more than one project, all projects in a category, or in all the projects in JIRA.
Automatically become watcher of every issue blocking issues assigned to us, in order to react as soon as possible to any change in those issues preventing us to proceed with issues assigned to us.
This is a way to overcome a serious shortcoming of JIRA: JRA-5865
We are going to show how to block or unblock a transition after issue rested for some time in current status. More concrete examples are:
- Prevent a closed issue from being reopened after resting 1 week closed.
- Ensure that issues rest in certain status at least 24 hours.
- Enroute issues to different statuses depending on the time they rested in current status.
Make an issue inherit the highest priority among priorities of issues being blocked (directly or transitively) by that issue.
Setting Priority of an issue when we write the priority name between brackets in the issue Summary. This can be particularly useful for issues created by email.
Setting Due Date of an issue when we write "due on" followed by a date in the Summary of the issue. This can be particularly useful for issues created by email.
Creating issue links when writing sentences containing issue keys in issue Description.
A validation for preventing work logs with a beginning date before a time limit in the past. In particular, how to avoid work logs where the associated date is earlier than 10 days in the past, i.e., if we are on 25th march, today we only allow work logs with 15th march or later as beginning date.
How to apply a restriction on the sum of hours a user can log in a single day, counting work logs in any issue.
Other amazing use cases
- Update linked issue's Date Picker with current issue's Due Date if it's greater than linked issue's Date Picker
- Restricting Subtask Type creation depending on Parent Issue Status
- Restricting Subtask Type creation depending on Parent Issue Type
- Sum subtask's time spent (work logs) and then add it to a certain linked issue
- Set Date Picker custom field with earliest (or latest) value among subtasks and current issue's value (look at comment 2)
- Add to a Multi-User Picker custom fields all the assignees of certain type of subtasks (look at comment 1)
- Make sub-task's status, upon subtask's creation, match parent issue's current status
- Assign issue to last user who executed a certain transition in the workflow
- Add Watchers depending on Security Level