Become a JIRA Subtask Ninja
Recently while working with a customer we came across a bug in JIRA 7.1.6 – Fix Version is not Copied to subtasks when Creating JIRA Subtasks.
The customer in question usually broke stories into JIRA subtasks. When creating a story they assign a fix version to it. This is the version in which they plan to release the feature described by the story.
The customer had a filter which showed the JIRA subtasks and parent stories by fix version. But after upgrading to JIRA 7.1.6 they noticed that for new subtasks the fix version was not being automatically inherited from the parent story. It seems that this version of JIRA broke this functionality – it was working fine in 6.x and as recently as 7.0.5.
As the bug in question is deemed a low priority bug with low level of impact, the likelihood of it being fixed any time soon is low. So we needed to look at some workarounds.
In general, JIRA subtasks can be a bit of pain to create and maintain. There is potentially a lot of manual effort in creating them and copying values to / from parents. But it is necessary if you want divide up the work and assign to the individuals responsible, and then get accurate reports and dashboard views.
So when reviewing workarounds and other techniques to manage this efficiently we wanted to look at some generic and flexible solutions. The first that came to mind (and is suggested by Atlassian in the bug response), is the use of Post-functions and the JIRA Misc Workflow Extensions free add-on.
Using Post-Functions to inherit values for JIRA Subtasks
What is a post-function? A post-function is one of the more powerful integration and customization points in JIRA. When a workflow transition is executed, JIRA will execute a number of post-functions that cause other JIRA magic to happen. For example, JIRA will re-index the issue when you change the issue status.
We can add additional post-functions and this is what we can use for our first solution. We will create a post-function that will be executed when a sub-task is created. It will copy the Fix Version value from the parent issue.
We are going to need an add-on which will provide a post-function type to do the field value copying. Many add-ons in the Atlassian Marketplace provide a range of additional workflow functions, including conditions, validators, and different types of post-function (I plan to do another article reviewing the most popular add-ons in this category – let me know in the comments if you are interested).
For this article we will use the Suite Utilities for JIRA – a free add-on that works in both Server and Cloud versions of JIRA. Make sure you use the correct version of the plugin for your version number of JIRA.
Creating the Post Function
Login as an administrator and install the Add-on in the usual way.
Go to Admin->Issues->Workflows. Find the workflow for the relevant sub-task issue type and click the Edit button.
Edit the workflow in graphical mode by clicking Diagram.
Choose the Create Transition by clicking on the line from the solid dot that indicates the start of the JIRA workflow.
A small panel should appear in the right of the workflow pane. On this panel you should see a link to Post Functions. Click this link. A new tab will open in the browser.
Here you will see the list of post-functions already added. JIRA will automatically do this when you are creating a workflow transition and its generally not a good idea to mess with these. We will click Add post function link to add our own function.
We then choose the Copy Value From Other Field post-function [image]. Click the Add button.
We configure the post-function as shown in the next image. Choose the Fix Version field in both cases. Click OK.
The post-function is added at the top of the list. Move your mouse over the post-function row, then click the down arrow to move the post-function after the “Creates the issue originally” post-function.
You are finished editing the post-function, so you can close the browser tab and return to the original tab with the graphical browser view.
Click the Publish Draft button at the top of the window.
Now test your workflow. Create a Story and set a fix version. Create a sub-task in this story and check that the fix version is inherited from the parent story.
So that takes care of inheriting values to subtasks from their parents. You can extend this solution to inherit any field, and I would encourage you to explore the other options provided by the plugin.
We need a JIRA admin to modify the workflow and configure this. But there is an alternative that does not require a JIRA admin and can be built by project managers or regular users.
Note: Please remember that if the fix-version is changed in the parent, it will not automatically propagate the change to the subtask. The copy function is only trigger when the transition is executed.
Become a JIRA SubTasks Ninja – The Quick SubTasks Plugin
This has to be my one of my favourite plugins. A real gem that I only recently discovered. Its free, has decent documentation, and the potential to boost your JIRA chops significantly. And you don’t need to be a JIRA admin to understand or use it.
You’ll find the plugin in the Atlassian Marketplace. When you install this plugin you get a new option in the More menu – Create Multiple SubTasks.
It works very naturally. By that I mean you simply create a list of tasks in a text box. Break down your story (or any other parent issue) into subtasks by writing a text list using a special but very simple syntax.
Here’s an example from the offical plugin documentation.
You can enter 1 or more subtasks, one per each line. And you can choose the issue type of the subtasks, as well as decide if you want to use add the summary of the parent issue as the prefix for the summary of subtask.
To solve our original problem we can use the special “@inherit” syntax which tells the subtask to inherit the field value from the parent issue. Couldn’t be simpler. No messing with post-functions.
If that’s all this plugin could do it would be worth it. But it has more.
We often have a standard set of subtasks for a particular issue type. For that scenario we can define templates.
Now when we select “Create Multiple Subtasks” we can choose the template. Templates can also inherit values, explicitly set values, and even use placeholder values for the summary and field values. Check out the documentation here.
Finally, we can also integrate this into our post-functions. We can, for example, add a post-function which automatically creates the subtasks for a story.
Note: Just like the post-function solution, this will only copy the fix-version (or any other field value configured with @inherit) on creation of the subtask. To ensure that the fix-versions of the parent and subtasks always remain in sync you would need to use JIRA listeners…maybe the subject of another blog. Let me know in the comments if you’d like to find out more.