Feature #8307

Automatically update parent issue status based on child issue statuses

Added by Giovani Spagnolo over 6 years ago. Updated 6 months ago.

Status:NewStart date:2011-05-06
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Issues
Target version:-
Resolution:

Description

At the moment, if the user creates a parent issue and then some subtasks, the parent issue automatically updates the estimated time field based on child estimates.

It should similarly update the issue status, based on child statuses (ie.: change to New if all subtasks are "new", change to "in progress" when at leat one child is in progress or if there are mixed subtasks in state "new,closed",etc...)

It could also be an option to enable/disable this kind of behaviour in project properties or even by tracker.

History

#1 Updated by Alex A over 6 years ago

+1

#2 Updated by Dmitry Babenko over 6 years ago

-1. Closing all subtasks doesn't always mean closing the parent task,

#3 Updated by Giovani Spagnolo over 6 years ago

Dmitry Babenko wrote:

-1. Closing all subtasks doesn't always mean closing the parent task,

Hi Dmitry, in fact that's why "there shoud be an option to enable/disable this kind of behaviour"... so it accomodates both needs. In our projects we map the Work Breakdown Structure to parent tasks, and then add only new subtasks within each Work Package.

Having a way to dinamically check the status of each WP would certaintly add much value. As soon as a new subtask is added to a "closed" WP, it's status would change back to "in progress", without the need of manual control.

thanks.

#4 Updated by Terence Mill about 5 years ago

+1
We need this too!

#5 Updated by Andrew Hickman over 4 years ago

+1
This would be useful for us too.
I agree that some may not want parent tasks closed automatically, therefore a configurable setting would keep everyone happy.

#6 Updated by Luis Roa over 4 years ago

+1 I need this too.

#7 Updated by Selim Arslan over 4 years ago

Giovani Spagnolo wrote:

Dmitry Babenko wrote:

-1. Closing all subtasks doesn't always mean closing the parent task,

Hi Dmitry, in fact that's why "there shoud be an option to enable/disable this kind of behaviour"... so it accomodates both needs. In our projects we map the Work Breakdown Structure to parent tasks, and then add only new subtasks within each Work Package.

Having a way to dinamically check the status of each WP would certaintly add much value. As soon as a new subtask is added to a "closed" WP, it's status would change back to "in progress", without the need of manual control.

thanks.

+1 Need too

#8 Updated by Lubos Racansky about 4 years ago

+1

#9 Updated by Blazej Zembala about 4 years ago

+1 Must have!
Using backlogs Story is a task, taks are "subtask". Can work on backlogs taskboard and Stories are automaticly colsing, but using smart commits doesn't work.

#10 Updated by Florian S. about 4 years ago

+1

#11 Updated by John Nguyen almost 4 years ago

+1 This is related. I had a customer wanting to automatically create a subtask when the last subtask has been closed. He did not want to create all the subtasks up front because there is a dependency work flow based on the status of the last task.

#12 Updated by Christopher Caruk over 2 years ago

We need this too... Perhaps other here would be interested in sharing the cost of having a plugin built?

Before commissioning the work though I think that we need to consider further. For example, what happens if there are several child tasks that might update a parent or if the parent issue is closed, rejected or otherwise changes state by some other means?

Also it would be good if it were not limited to just the sate attribute and also:
  • sent an update message to the parent if it reaches a particular state.
I've been wondering if this could not be accomplished using a special custom field within the chld task. Something that stores:
  • the initial parent state or an acceptable range of states that will allow an automatic update
  • the state of the child that triggers the change to the parent
  • the child states that trigger an update message to the parent
  • the parent attribute to change and the value to change it to

On save, if the current child contains an automator custom field then check the other child tasks to see if they have will allow an update to the parent and then update the parent. I wonder if this would need to cascade upwards... check the parent's parent, etc.. Perhaps the update of the parent could be handled as an asynchronous task using Sidekiq or similar when the child is saved.

This could be use in the following ways:

  • Supplementary Workflows... let say that you want to automate the process of reviewing and approving task escalation. You could create a child task, with it's own workflow, that's essentially a request to update the priority of the parent. If the escalation request reaches approved, change the priority of the parent.
  • Hiding the details of a task from a requester... Let's say that someone (a customer for example) asks for something that involves many smaller tasks... you do not really want him to be able to see all the detail work being done or receive message every time someone touches the task... you might also want to have someone who is responsible for the task as a whole (assignee) and not change this while all the subtasks are being worked on by other people. As the task is being worked on messages would be periodicity sent to the customer (perhaps owner) or high level assignee.

Anyone interested?

#13 Updated by Iwadara I 7 months ago

+1
I need this too.

#14 Updated by ian tulank 6 months ago

I've found this discussion in Redmine forums: Auto-Close parent after his children are closed.

Also available in: Atom PDF