Project

General

Profile

Actions

Feature #13585

open

Make sub-task inherit the properties of parent

Added by Dipan Mehta over 11 years ago. Updated over 8 years ago.

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

0%

Estimated time:
Resolution:

Description

Background

Sub-task as such is a pretty much a complete issue like any other. It has it's own values of each custom fields, states, permissions, authors and so on. Currently the only thing common or linked between the parent task and sub-task are dates, closure etc.

However, when we think of sub-task it's not just-another-work-item; else it would be just another relation. Sub-task should necessarily derive it's properties or workflow from parent task - since it is the parent task which defines the 'larger scope' for all its children.

Some scenarios

  1. In many cases - for a given issue, there are many custom fields liek customer-representatives, QA specific attributes, project and process specific attributes etc. which should be governed by parent issues.
    • The sub-tasks shouldn't be required to keep copy and updating issues when parent is updated
    • The sub-tasks sometimes shouldn't be allowed to change some of the properties.
  2. Many a times, when we are building a feature, some specific use-cases, exceptions keeps arising. In this case, we create a sub-task (not a new task). From the customer/accounting point of view it may be regarded as an 'extra work' but from release or QA point of view the patch for the full parent issue inclusive of all sub-tasks is single. In such cases many feature specific custom field should be simply 'as per parent'
  3. Another example, if the parent feature is 'client approved' the sub-tasks should also get 'client approved'

Currently the shortcut is to 'copy' a task straight away to preserve the values but when the same values change on the parent task - the sub tasks should reflect the same.

Approaches

Given this principle, we should be able to define specific behaviors:
  1. The target version should get directly linked to sub-task assuming both the sub-task and parent tasks are expected to be finished together.
  2. Custom fields of issues can have a properties as 'derive from parent'. Hence they can be automatically linked from parent tasks.
  3. Alternatively, in the "New issue"/"Update" form, the custom fields (even if mandatory) can have option called 'Follow parent' option which will follow value of parent as applicable. This way, specific properties can be linked to parent without any standard template.
  4. Specific State transition in workflow can have a flag <move sub-task along> which will reflect the corresponding states of the issues as well.
  5. Alternatively, when parent's status is changed, additional drop-down of child's status can be selected or can be kept unchanged if no change is more appropriate.
  6. Closure should be completely linked
  7. %done of the parent task can be directly derived from the sub-tasks.

There is no assumption that parent task and sub-task are of the same tracker - hence this overlap only applies to states and custom fields which overlaps in the respective trackers.

What do you people think about it?


Related issues

Related to Redmine - Feature #6217: When creating a subtask, pre-fill fields Target version, Category & Start- and Due date based on parent valuesClosed2010-08-25

Actions
Related to Redmine - Feature #9972: Subtasks assigned to same version by defaultClosed2012-01-10

Actions
Related to Redmine - Feature #7057: Send email notification on subtask and parent updatesClosed2010-12-06

Actions
Related to Redmine - Feature #11177: Email notification for subtasks status changes to watchers of the parent taskClosed

Actions
Related to Redmine - Feature #9991: Estate parent task vs subtaskClosed

Actions
Related to Redmine - Feature #7450: Subtask : automatic statusNew2011-01-26

Actions
Related to Redmine - Feature #5875: Changes to child estimates should trigger journal entries for the parent estimateNew2010-07-12

Actions
Related to Redmine - Feature #6117: subtasks default to parent issue target versionNew2010-08-12

Actions
Related to Redmine - Feature #10989: Prevent parent issue from being closed if a child issue is openClosedJean-Philippe Lang

Actions
Actions #1

Updated by Dipan Mehta over 11 years ago

Different issues which discuss about linking child issues with parent:

1. Target Version:
There are number of Issues that request linking sub-tasks' Target version to be same or linked to parent's Target version: See #6117 and #9972 (Also see http://www.redmine.org/boards/4/topics/28743)

2. Blocking of parent by child issues. see #5462

3. Watchers: Another linkage is to have watchers to be directly inherited. See #7057, #11177.

4. Issue status: #9991, #7450, #5734

5. Time and Estimates: #5733, #5875

Actions #2

Updated by Dipan Mehta over 11 years ago

Another important related issue: #6117

Actions #3

Updated by Edosoft Factory over 10 years ago

You should checkout Subtasks Inherited Fields Plugin at https://github.com/edosoft/redmine-inherit-fields-plugin

Actions #4

Updated by Bryn Jeffries over 9 years ago

Edosoft Factory wrote:

You should checkout Subtasks Inherited Fields Plugin at https://github.com/edosoft/redmine-inherit-fields-plugin

Great plugin. In addition, to retrospectively inherit target milestones you can issue via the database console (at least for PostgreSQL)

UPDATE issues 
SET fixed_version_id=I2.fixed_version_id
FROM issues I2
WHERE issues.parent_id=I2.id;

Actions #5

Updated by Ricard F over 9 years ago

This would be great to have it nativelly... There is nothing simillar to that plugin working on 3.X

Actions #6

Updated by Jérôme L about 9 years ago

Maybe proposing parent values as default is not enough. What if a parent value (say, milestone, for example) changes? Should the child value change as well?

For each potentially inherited property, the choice should include "Inherited from parent" and this link should be remembered instead of the value itself. This could be the default choice.

This way, the user can choose to have a property of the child issue (priority, version) differ from its parent property, but if it is set to be inherited, changing the parent's property changes the child property as well.

Actions #7

Updated by Florian ROBERT about 9 years ago

+1

Actions #8

Updated by Alessandro Zucchi over 8 years ago

+1

Actions #9

Updated by Toshi MARUYAMA about 8 years ago

  • Related to Feature #10989: Prevent parent issue from being closed if a child issue is open added
Actions #10

Updated by Toshi MARUYAMA about 8 years ago

  • Related to deleted (Feature #10989: Prevent parent issue from being closed if a child issue is open)
Actions #11

Updated by Toshi MARUYAMA about 8 years ago

  • Related to Feature #10989: Prevent parent issue from being closed if a child issue is open added
Actions #12

Updated by Toshi MARUYAMA about 8 years ago

  • Related to deleted (Feature #5462: Blocking issues to be closed which have open subtasks)
Actions

Also available in: Atom PDF