プロジェクト

全般

プロフィール

Vote #69850

未完了

Automatically update parent issue status based on child issue statuses

Admin Redmine さんが3ヶ月前に追加. 3ヶ月前に更新.

ステータス:
New
優先度:
通常
担当者:
-
カテゴリ:
Issues_2
対象バージョン:
-
開始日:
2011/05/06
期日:
進捗率:

0%

予定工数:
category_id:
2
version_id:
0
issue_org_id:
8307
author_id:
22233
assigned_to_id:
0
comments:
14
status_id:
1
tracker_id:
2
plus1:
9
affected_version:
closed_on:
affected_version_id:
ステータス-->[New]

説明

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.


journals

+1
--------------------------------------------------------------------------------
-1. Closing all subtasks doesn't always mean closing the parent task,
--------------------------------------------------------------------------------
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
We need this too!
--------------------------------------------------------------------------------
+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.
--------------------------------------------------------------------------------
+1 I need this too.
--------------------------------------------------------------------------------
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

--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+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.
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
+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.
--------------------------------------------------------------------------------
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?
--------------------------------------------------------------------------------
+1
I need this too.
--------------------------------------------------------------------------------
I've found this discussion in Redmine forums: message#39161
--------------------------------------------------------------------------------

Admin Redmine さんが3ヶ月前に更新

  • カテゴリIssues_2 にセット

他の形式にエクスポート: Atom PDF

いいね!0
いいね!0