Project

General

Profile

Actions

Feature #8307

open

Automatically update parent issue status based on child issue statuses

Added by Giovani Spagnolo over 13 years ago. Updated over 7 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Issues
Target version:
-
Start date:
2011-05-06
Due date:
% Done:

0%

Estimated time:
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.

Actions #1

Updated by Alex A over 13 years ago

+1

Actions #2

Updated by Dmitry Babenko over 13 years ago

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

Actions #3

Updated by Giovani Spagnolo over 13 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.

Actions #4

Updated by Terence Mill about 12 years ago

+1
We need this too!

Actions #5

Updated by Andrew Hickman over 11 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.

Actions #6

Updated by Luis Roa over 11 years ago

+1 I need this too.

Actions #7

Updated by Selim Arslan over 11 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

Actions #8

Updated by Lubos Racansky about 11 years ago

+1

Actions #9

Updated by Blazej Zembala about 11 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.

Actions #10

Updated by Anonymous about 11 years ago

+1

Actions #11

Updated by John Nguyen over 10 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.

Actions #12

Updated by Christopher Caruk over 9 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?

Actions #13

Updated by Iwadara I over 7 years ago

+1
I need this too.

Actions #14

Updated by ian tulank over 7 years ago

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

Actions

Also available in: Atom PDF