You will need to write a plugin (workflow post function) or some scripts to do this.
It is a bad idea though in my opinion because it should really be the other way round. Parent should move to 'X' status when all its subtasks are in 'X' status. The reason I say that is because subtasks are small chunks of work which can be done without the other subtask status. And parent task progress is the sum of all subtasks (which is also not true in every scenario!).
Thank you both for your answers.
I will explain wht this is needed - we have a process that tasks are opened but an operation manager needs to approve them in order to get the work started.
Whenver she approves a parent tasks, all subs should be approved automatically.
Then you could still easily learn your people to not start on a subtask as long as the parent isn't approved.
You could even use a differtent workflow for you subtasks that doesn't include the approved state.
You could also work with filters to show only those tasks that are already approved to your developers.
But you can ofcourse do it with a jelly script (see the jelly script in this blog post for an example of auto transitioning issues in a filter: http://www.petervandevoorde.com/2013/11/13/a-jira-trick-creating-issues-and-sub-tasks-on-transition/)
Yes I know of JellyScripts and Escalation services of script runner plugin, the point I was trying to make was that If the approver wants to see the subtasks before approving the parent and the moment parent is approved the sub-tasks are also approved.
Yes subtasks can be created if they aren't present at the time of parent approval or can use a completly different workflow as well, but I somehow feel Ayelet has a relevant requirement becasue Sub-tasks may require sign off from different executives but the parent can be signed of by a senior executive and the moment the parent is approved then junior executives don't need to signoff and sub-tasks are automatically transitioned.
I don't say that the auto transition is a bad idea, in some cases, like the ones describe by you and Ayelet, it sounds like a good idea and a nice feature.
But I still think this is more about educating your users then forcing the process into the application. For example : how are you going to stop people from simply adding subtasks after approval? Should this behaviour block everything and submit the parent back for approval?
I think the application should be an indication of the states of the different tasks, but the process and how to work with those tasks should be in the heads of the users, not forced into the application.
But that's totally of topic :)
Great comment @peter!
We are doing exactly this in our ServicDesk project. When e.g. a new user is to be onboarded we create a number of subtasks for each activity involved. And this is done when the ticket is taken by the ServiceDesk agent rather than when the ticket was requested.
We use a combination of the Script Runner and Create on Transition plugins
Peter - I never let the system define my work process. I think it's wrong.
The correct work process is that you create all tasks needed for that work and at some point of the week, the operation manager looks at all parent tasks and approve what can be approved.
There's no declines. the Approval is just for the task to go to work. It will go to work at some point.
Thank you for the jelly script. I will test it.
Thank you all.
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs