Feature #8307
openAutomatically update parent issue status based on child issue statuses
0%
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.
Updated by Dmitry Babenko over 13 years ago
-1. Closing all subtasks doesn't always mean closing the parent task,
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.
Updated by Andrew Hickman almost 12 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.
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
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.
Updated by John Nguyen almost 11 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.
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.
- 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?
Updated by ian tulank over 7 years ago
I've found this discussion in Redmine forums: