Redmine

Been working more with this functionality, and I find that limit less and less practical.

When we have one person assigned to the parent task, that's responsible for tracking it. It becomes unpractical to manage.

Another thing is tasks where all the subtasks are closed/rejected, and there's only the main task left. Then you have no way of setting priority/start date/end date.

Anders Aagaard wrote:

Another thing is tasks where all the subtasks are closed/rejected, and there's only the main task left. Then you have no way of setting priority/start date/end date.

Exactly. Another point is that only the first subtask sets parents due dates. Other subtasks with earlier due dates didn´t update parents due date. And of course closing child tickets makes updating the parent task impossible. Any workaround or ideas how to "unlink" both dates?

Any updates on this? This isn't remotely close to logical behavior.

I also find this behavior to be illogical and counter productive. In fact, in our production system I had to hack this out for the priority as it was completely destroying our workflow. My suggestion is this should be made optional, allowing the admin to select which things are controlled by the child subtask.

Could you make a diff for that hack? I don't have time to do it myself right now. And it's a rather big annoyance to both me and my coworkers.

I strongly agree that this is illogical behavior for a lot of use cases. I'd be happier without the feature, but I'd be satisfied with a way to turn it off (enabling status and due dates on the parent).

Oops. Accidentally left something unrelated in that diff. You ought to be able to figure it out!

I see this has "unintended consequences". Have you used this for a while? I don't wanna risk anything that might screw up the database.

If children aren't deleted/moved correctly for example, how easy is it to fix that manually?
Will children with parents deleted still work properly?

Anders Aagaard wrote:

Been working more with this functionality, and I find that limit less and less practical.

When we have one person assigned to the parent task, that's responsible for tracking it. It becomes unpractical to manage.

In the case of a user Foo responsible for the parent tasks and want to delegate some subtasks for other user Bar , I suggest in this ticket #6460 that changes in subtasks should send a notification for users associated with the parent task.

I know it's an issue not related to this one, but it involves subtasks, and it's good to discuss ways to improve subtasks in Redmine.

+1 - I also think this feature is more painful than useful.

1. independent (completely independent parent and child tasks, there is just a relation between them)
2. derived from children (the way it is now)
3. restricted children (subtasks' priority/due date cannot be set "under" the parent task's, see last paragraph of issue description)

I fully agree.
We just have updated from 0.9.2 to 1.0.4 to benefit from the Subtasks feature, but how it's implemented now, we simply can't use it. We can't have a subtask changing (shortening) the due date of the main task.

Say we have a main task which is "Development of the new RS-232 interface" which is officially due on 01/01/2011, having a subtask "Make a null modem cable for tests" that shortens the real due date to something closer is nonsense.

I like Andreas proposal. Though, I don't know if these properties should be handled at parent task level, projet level or application level...

Thanks, Eric

Hi,

+1 for Andreas

The total relation between subtask and task parent is a nonsense for my project.

I use redmine in agile project, I need different priority beetwen user stories (task parent) for my product backlog or sprint. The subtask (a task for development) priority for each story don't have related to the priorities of my user stories.

But the estimated time from each subtask is a total time for my parent task.

So, I need to choose the relation (date not/and priority not/and time) with subtask and parent task.

Thanks
Yannick

Yes Please!

+1 for Andreas

It would be great if this issue was addressed. As it stands, it looks like we'll have to avoid using sub-tasks since they contort the parent's due date.

Otherwise, the system looks pretty slick.

Thanks,
Shahriar.

+1

I've been using Redmine for years now but I've got to admit that the subtask module is not usable the way it is now.

+1
I don't understand the logics behind current implementation. Anyway, subtasks definitely are unusable in our case.

And unfortunately, it looks Michael's patch makes task -> subtasks relations disappear (e.g. from the list in the issue description).

Eric

+1

I had a due date for a parent task, and it got lost when I created a subtask with a earlier due date. I also think that child tasks should not control the parent task.

Any idea when this might be integrated? I think this is a major problem because it makes the subtasks feature completely useless or unusable. It's interesting that noone from the core team seems to care about it... I would implement it myself, but I have no knowledge of Ruby.

+1

The way subtasks control their parents at the moment is very odd indeed.

• independent (completely independent parent and child tasks, there is just a relation between them)
• derived from children (the way it is now)

+1
Waiting for a better solution, too.

+1
Vote for the option where the current solution is kept, but we also keep a separate estimate for the parent task, so that the parent task would have the properties:

Estimated time: 30 hours(editable)
Total estimated time from children: 32 hours

We can do the same for the other properties.

I've applied the defang_children.diff to Redmine 1.2.0, but it doesn't seem to work. All subtasks are still setting the parent task's dates and estimated hours. Is there an updated diff? Here is what i did in my issues.rb. I also added the line to the show.rhtml as specified in the diff.

  # 9/16/2011 Hack to remove subtask dependency
  #after_save :reschedule_following_issues, :update_nested_set_attributes, :update_parent_attributes, :create_journal
  after_save :update_nested_set_attributes, :create_journal
  # 9/16/2011 Hack to remove subtask dependency
  #after_destroy :update_parent_attributes

  # HACK!
  # This forces Redmine to believe the issue has no children,
  # allowing us to update priority and due dates manually.
  # WARNING: There are some unintended consequences: children are not deleted, etc.
  def leaf
    true
  end

+1 to this (the whole discussion), I find this feature so counterproductive that I end up not using subtasks, and instead organize them by category, version or even subprojects.

Agreed.

I like the option #25 with dual estimated time.

Here is a patch for redmine 1.3, which filters subtasks if closed. So a parent issue would have the highest priority of all active subtasks.

--- app/models/issue.rb.orig       2012-02-29 14:49:31.103061065 +0000
+++ app/models/issue.rb    2012-02-29 14:49:56.147060558 +0000
@@ -798,7 +798,7 @@
   def recalculate_attributes_for(issue_id)
     if issue_id && p = Issue.find_by_id(issue_id)
       # priority = highest priority of children
-      if priority_position = p.children.maximum("#{IssuePriority.table_name}.position", :include => :priority)
+      if priority_position = p.children.maximum("#{IssuePriority.table_name}.position", :include => :priority, :joins => "LEFT JOIN #{IssueStatus.table_name} ON #{IssueStatus.table_name}.id = #{Issue.table_name}.status_id", :conditions => ["#{IssueStatus.table_name}.is_closed = ?", false])
         p.priority = IssuePriority.find_by_position(priority_position)
       end

If all childs are closed the last priority given to the parent survives. You may add a patch which disables the roll-up completely if all childs are closed.

Having the subtasks take over the parent task is a complete pain. We want to use them (and are trying), but the current implementation is not workable for us. I can see the logic that if a subtask has a high priority, then the priority of the parent task must elevate for visibility, and that if a subtask has a date off in the future that the due date on the parent task has to be at least this far out.

The parent issue start/end dates, or priority should not be controlled by CLOSED subtasks - we have some work which is maintained in the parent issue as well as key areas of work extracted to subtasks, and when these subtasks are closed the parent task is left in limbo unless you edit each of the subtasks and remove the priority and dates. Ideally we should be able to set the due date/priority on the parent task at least as high as the highest open subtask, and if a subtask is added with a date that is beyond the parent task it should offer the choice of pulling back the due date on the subtask or extending the parent task.

That was something very informative for me, the information that you have provided has added a lot to my knowledge about the subject. Thank you

website design agency

+1
The way subtasks change the parentask is not practical.

This has become one of my top grievances with Redmine. It makes a very useful feature (sub-tasks) almost practically unusable with our workflow, and almost any other workflow I can think of actually. As soon as you have added a sub-task you lose the ability to control the priority of the parent, which is where you really want to have the control, in a sort of supervisory role.

Suppose we have the following task, for example:

• Fix boat
  • Plug leaking hole (very urgent)
  • Lubricate squeaky hinge (not so important)

Both sub-tasks are logically part of fixing the boat. Plugging the hole is very urgent, however making sure the boat is fixed in its entirety is not (especially once the hole is plugged! #5880). I can see how one can make the argument that drawing attention to the "fix boat" issue is good if there are important (open!) sub-tasks, but since each sub-task is already an issue in its own regard in Redmine there is really no need.

There is also a rather dangerous reverse problem. Suppose we have the critical "plug hole" issue and someone adds a sub-task to it:

• Plug leaking hole (our lives depend on it)
  • Even off the plug surface with sandpaper, once in hole (not so important) <-- added later, but while still leaking

Oops, suddenly it is not important to fix the leak any more (it has now inherited the low priority of the "finishing touches" task). Logically, it made sense to add it as a sub-task to the "plug hole" issue, at least enough that someone could do it accidentally, but the consequence is that we have now altered the main task in doing so.

(Incidentally, perhaps Redmine should have a voting system instead of all these +1s.)

Thanks for providing such a colorful example. If only developers would read it and perceive how nonsensical current implementation is...

+1 please add a property which can enable this behaviour

+1

+1

+1

+1

Priority shall be most importnat/Strongest of the priority all subtasks.

-

Terence Mill wrote:

Priority shall be most importnat/Strongest of the priority all subtasks.

I disagree for the reasons I have stated above.

It would be interesting to hear which workflows people are using in practical, real-world projects of non-trivial size where the current behaviour is desirable, and why.

Unfortunately, having subtasks overruling parent tasks makes the subtask feature essentially useless for us. Even a bit risky, in fact. Evidently, several other Redmine users are of similar opinion, so if the aim is to make Redmine as useful as possible to as many people as possible, I think at least a setting for this should be considered.

+1
This is a must I think, and Josef's example shows exactly why.

From an ease of use perspective, it also makes sense. If I have a large task that several people need to work on different parts of, I really don't want to have to manually set the due date for every single one.

What I think would be really nice is to inherit the parent's properties (due date, priority) as a default set of constraints, but then allow further modification within those constraints. For example, a child task cannot be due later than the parent.

Here is an example:
Parent task 123 is to deliver a doohickey. However, that requires someone to design it and build it, which are tasks 124 and 125 respectively. The doohicky is due at the end of next week, but clearly the design subtask needs a due date earlier than the build sub task.

+1
I would also like this.

+1

+1. I just installed 2.2-stable and found the same issue.

+1

+1

+1
It should give a choice on issue level if the issue controls the subtasks, the subtasks controls the parent issue or no control all must be done manually. Perhaps a per project setting for a default value on new issues.

We have projects where issues are used as "master backlogs", they have an estimation and start/due date. If someone now creates a subtask all that information are lost.

Other projects working more with "small" issues. So we have to group that issues and now the parent issues should calculated from the subtasks.

We have also projects where this is mixed together.

I hope I could give enough feedback, that this is really needed for us.

Hi I installed 2.3 3 Weeks ago. At the moment I am facing the same problem as mentioned here.
Can I use the patch which was posted under #49 also vor the new version?
Is it possible to easily remove the patch, if it won't work?

Sebastian Bertram wrote:

Hi I installed 2.3 3 Weeks ago. At the moment I am facing the same problem as mentioned here.
Can I use the patch which was posted under #49 also vor the new version?
Is it possible to easily remove the patch, if it won't work?

i've patched my 2.2.3 version with this patch without any problem, but can't say with a 2.3...
You can patch with a -b option to backup impacted files.

Marc Pasteur wrote:

Sebastian Bertram wrote:

Hi I installed 2.3 3 Weeks ago. At the moment I am facing the same problem as mentioned here.
Can I use the patch which was posted under #49 also vor the new version?
Is it possible to easily remove the patch, if it won't work?

i've patched my 2.2.3 version with this patch without any problem, but can't say with a 2.3...
You can patch with a -b option to backup impacted files.

You can also reverse patch: patch -R ....

Regards.

Thanks for the replay. I also found this patch. It also sound very nice --> #6687

Is there another diskription howto patch redmine than this one? --> http://www.redmine.org/projects/redmine/wiki/Patch

Because some things aren't clear for me.
Is there already a patch file in redmine?
If not, where do I have to put the patch-programm that is mentioned?
An at last, where do I have to put the .diff file?

Sorry for the questions but I is my first time working with redmine.

Hi.

When you do a git diff the first item in the path is always "a" and "b". To apply git patches, you could use:

git apply patch.diff

But you could also use:

patch -p1 < patch.diff

The number after -p parameters specifies how many path items to remove from the paths given in the diff file.

Regards.

Sebastian Bertram wrote:

I managed to patch the file. First tried the patch form #6687. Patching process went fine, but I hat a problem with an internal error 500 when I wanted to display an issue. So I loaded the old .rb again.

Now I wanted to patch the above .diff. But I says, that it cant find the issue.rb. I think it is because of a/app/models/issue.rb and b/app/models/issue.rb. In my installation files the issue.rb is in app/models/issue.rb.
So I edit the file. But now I am not sure if this is right or not. Maybe somebody could look if that what I have done is making sense.

Thanks and best regards

Erny Revilla wrote:

Here I have a quick & dirty patch for 2.2.1 (stable). It avoids update of the parent issue and makes the fields editable again. Enjoy.

Hi, yesterday I tried to use that patch as guideline to enable the independent parent task priority again (so basically I only used the priority-relevant parts of your patch). It did have the effect that modifications among child tasks didn't affect the parent priority any more. However, it seems that I could still not modify the priority in the parent task itself. The field is editable, I can alter the value and save/update the task, but the priority will not be changed.

After quite some code reading (but not being fluent in Ruby), I could not find an obvious reason for the priority update being ignored.

Maybe you have an idea where to look more thoroughly?

Bernd Winter wrote:

Erny Revilla wrote:

Here I have a quick & dirty patch for 2.2.1 (stable). It avoids update of the parent issue and makes the fields editable again. Enjoy.

Hi, yesterday I tried to use that patch as guideline to enable the independent parent task priority again (so basically I only used the priority-relevant parts of your patch). It did have the effect that modifications among child tasks didn't affect the parent priority any more. However, it seems that I could still not modify the priority in the parent task itself. The field is editable, I can alter the value and save/update the task, but the priority will not be changed.

Hi there. I can't remember well, but I think the parent data is recalculated from children whenever it is updated. I.e., your changes will be overwritten.

Regards

After quite some code reading (but not being fluent in Ruby), I could not find an obvious reason for the priority update being ignored.

Maybe you have an idea where to look more thoroughly?

Bernd Winter wrote:

Hi, yesterday I tried to use that patch as guideline to enable the independent parent task priority again (so basically I only used the priority-relevant parts of your patch). It did have the effect that modifications among child tasks didn't affect the parent priority any more. However, it seems that I could still not modify the priority in the parent task itself. The field is editable, I can alter the value and save/update the task, but the priority will not be changed.

After quite some code reading (but not being fluent in Ruby), I could not find an obvious reason for the priority update being ignored.

Maybe you have an idea where to look more thoroughly?

Hi!

I've solved it for 2.3!
After patch "issue_no_parent_updates-2.3-stable.diff", just find these lines (in app/models/issue.rb:436)

    unless leaf?
      attrs.reject! {|k,v| %w(priority_id done_ratio start_date due_date estimated_hours).include?(k)}
    end

    unless leaf?
      attrs.reject! {|k,v| %w(done_ratio).include?(k)}
    end

+1 Completely illogical behavior.

issue_no_parent_updates-2.3-stable.diff + http://www.redmine.org/issues/5490#note-61 = issue_no_parent_updates-2.4-stable.diff needed.

+1 to have the behavior swapped. There is probably a good reason to have the child tasks control the parent task, but I'm not seeing it.

Hi there! I stumbled upon the estimates-due-subtasks problem and as this page seems stalled and somewhat long went for the forum: http://www.redmine.org/boards/1/topics/41138. Hopefully the ideas presented there help to move the topic along.

Please fix this issue. Maybe the following strategy might help solving it:

- Make parent ticket have it's own 'estimated_hours' value.
- State TOTAL estimated_hours value behind the estimated_hours.
- Make parent have it's own start_date / due_date and have a red flag/warning behind it subtask begins/starts before that date.

+1

+1

Pretty please with sugar on it.

+1

Definitely need to at least allow the option for the parent fields to remain editable and independent of the subtasks. Reasons well-documented by others before me.

+1
Josef's Example

I say it would be best if you have two fields per issue when issues have sub-tasks.

One read-only field that displays the sub-task's properties (as it does now) and an input field next to the first field where you can either override or add dates, hours, etc.
This gives us flexibility to use the current style of sub-task handling or to input our own needs.
Sub-task properties should not always override parent task properties.

+1

+1
Very-very needed.
Idealy it will be as extention to option of autocalc/manual updating of done percentage by task state.
It's awful, while I can override percentage, and canot override begin and end date, priority, and even estimated horus.

• independent (completely independent parent and child tasks, there is just a relation between them)
• derived from children (the way it is now)
• restricted children

+1

Parent tasks should accumulate subtask estimated time, not be overridden by them. If I create a feature that I think will take 10 hours to complete, and implementing this feature creates an unforseen bug, I want the bug to be a subtask that needs to be fixed as part of implementing the feature. I do not want the 0.5h expected time on the bug to completely eradicate the 10h expected time on the feature... Also, the start/end times don't work in this context, either. The bug would start later than the feature, and possibly end at a different time as well.

+1

+1 it is survival need

+11, current behavior (subtasks taking control of parent task) is a huge deal breaker and is wreaking havoc when we try to use Redmine to organize work

+1, the following suggestion would be perfect. I would also like to add that these options should be for each property (start date, due date, spent time, priority ...) because even though I don't want start and due date of subtasks to affect parent task, I would still like the subtasks' spent time added to the parent's.

Nick Maximenko wrote:

+1
it will be good if we can set up for tasks:

• independent (completely independent parent and child tasks, there is just a relation between them)
• derived from children (the way it is now)
• restricted children

+1

It is also a important feature for our usage of Redmine.

I'll start working on this.

Lucile Quirion wrote:

The patch is ready (it applies onto v3.0.0 r14043)(its formatted with git)

...

I would like to have feedback on this patch.

Thanks

I would like to know how to apply this patch on an installed and running redmine server?
Should I make a clone of the repo onto my local computer, apply your patch and see what files that are changed by the patch? Then copy the changed files into my redmine installation, overwrite the files already in place?

Thanks

Lucile Laine Quirion

awesome! will this work with Redmine 2.6.0/2.6.2? I have been looking for that for a long time...

Lucile Quirion wrote:

The patch is ready (it applies onto v3.0.0 r14043)(its formatted with git)
I would like to have feedback on this patch.

+1 for the issue.
Unfortunately I am running on 2.5.1 so I'm not sure your patch would apply cleanly...

+1 (fields of parent-issue should not be restricted by closed/rejected child-issues)

Lucile Quirion wrote:

The patch is ready (it applies onto v3.0.0 r14043)(its formatted with git)

I've named the setting 'issue_independent_time_tracking'.
Its available via the Administration > Settings > Issue tracking > "Estimate and track time for parent issue independently from children issues"

Parent attributes 'priority', 'start_date', 'due_date', 'estimated_hours' and 'done_ratio' will not be overriden by subtask.
Child attributes 'start_date', 'due_date' will not be updated when the parent task is rescheduled.

I would like to have feedback on this patch.

Thanks

I don't get this...

If you eliminate all the dependencies, as suggested, this leads to simple "Related" relation and breaks entire idea of subtasks.

If you have a need for such loose relation why are you trying to use (and change) subtasks instead just using relations?

Sebastian Paluch wrote:

Lucile Quirion wrote:

The patch is ready (it applies onto v3.0.0 r14043)(its formatted with git)

I've named the setting 'issue_independent_time_tracking'.
Its available via the Administration > Settings > Issue tracking > "Estimate and track time for parent issue independently from children issues"

Parent attributes 'priority', 'start_date', 'due_date', 'estimated_hours' and 'done_ratio' will not be overriden by subtask.
Child attributes 'start_date', 'due_date' will not be updated when the parent task is rescheduled.

I would like to have feedback on this patch.

Thanks

I don't get this...

If you eliminate all the dependencies, as suggested, this leads to simple "Related" relation and breaks entire idea of subtasks.

If you have a need for such loose relation why are you trying to use (and change) subtasks instead just using relations?

People have different views on what a parent/child issue is and how they should act in relation to each other.

• At the moment, they act like "Folder"s for subtasks. This essentially makes the parent issue have no function or substance other than to be a container/label for its subtasks.
• On the other hand, my natural understanding of how parent/child works was that parents have their own task or issue, and any subtasks that are added onto it are additional tasks (get it? "added" onto the issue are "additional" things to the issue, not the ONLY things).

The natural workflow of Redmine also perpetuates one way more than the other because when you create a parent/child relationship, (usually) you first create the parent and then create "subtasks" to that parent. For me particularly, I tend to create parent issues (without knowing they are parents first) and use them. As I am using the first issue, I find that I need subtask issues to track specific parts of the first issue. I create a subtask and apply dates and whatever that are specific to ONLY that subtask. Now my parent issue's data (dates and whatnot) are being overwritten by the subtask and the subtask data pertains ONLY to its specific scope. This is unnatural for the user.
Its important to be able to identify and understand the different viewpoints of the user, especially on a total user experience-level.

Additionally, if they had a Issue Relation called "Subtask" or something similar, I might use it instead of creating subtasks and having parent/child issues because it doesn't work the way I naturally think it would work.
Otherwise, it isn't really the same to label something as a "related issue" vs a "subtask" (or whatever you call it).

Are you sure to delete user's data without asking?

_def self.up
  # Clears estimated hours on parent issues
    Issue.where("rgt > lft + 1 AND estimated_hours > 0").update_all :estimated_hours => nil
  end_

Petr Pospisil wrote:

Are you sure to delete user's data without asking?

Yes, this was not data entered by users but calculated by Redmine (sum of leaves estimates)

James H wrote:

The natural workflow of Redmine also perpetuates one way more than the other because when you create a parent/child relationship, (usually) you first create the parent and then create "subtasks" to that parent. For me particularly, I tend to create parent issues (without knowing they are parents first) and use them. As I am using the first issue, I find that I need subtask issues to track specific parts of the first issue. I create a subtask and apply dates and whatever that are specific to ONLY that subtask. Now my parent issue's data (dates and whatnot) are being overwritten by the subtask and the subtask data pertains ONLY to its specific scope. This is unnatural for the user.
Its important to be able to identify and understand the different viewpoints of the user, especially on a total user experience-level.

Same for me.

Jean-Philippe Lang wrote:

You can now choose between the 2 first options how start/due dates, priority and done ratio are handled. The last one is way too vague, please open a separate feature request with the exact rules that are needed.

We're talking about Redmine core functionality, I wish such issues would be met with a higher priority and be thoroughly discussed and evaluated before getting (somewhat) fixed. Next fix/feature will probably be several years ahead.

I know this ticket is closed, but wanted to interject one point in to it anyhow. First off, I am very happy to see the ability to change this behavior being added to Redmine core. I used to hack this out of my version because turning an established ticket in to a parent would blindly clobber data that was needed, breaking many things.

With that said, I see a need for having both pieces of information. Towards that, would it be an option to add a couple new fields to parent tasks that would indicate the summed information from the sub-tasks? For example, Estimated Hours and Spent Time are very useful to have summed up.

Ismael Barros² wrote:

I've just updated from Redmine 3.0 to Redmine 3.1 just to get this fix, but it doesn't seem to be working for me.

Confirmed here as well (same settings). I suspect that the devs would prefer to have a new ticket opened for this regression so it can be tracked/fixed in a new release. Do you want to do that or should I?

Done: #20992
Thanks :)

Is this available for:

Environment:
  Redmine version                3.2.1.stable
  Ruby version                   2.3.1-p112 (2016-04-26) [x86_64-linux-gnu]
  Rails version                  4.2.7.1
  Environment                    production
  Database adapter               PostgreSQL
SCM:
  Git                            2.9.3
  Filesystem                     
Redmine plugins:
  event_notifications            3.2.1
  planner                        0.5
  redmine_better_gantt_chart     0.9.0
  redmine_checklists             3.1.5
  redmine_dashboard              2.7.1
  redmine_mail_reminder          3.0.0.0001
  redmine_mentions               0.0.1
  redmine_percent_done           1.0.0
  redmine_spent_time_in_issue_description 2.8.0
  redmine_tags                   3.1.1
  redmine_work_time              0.3.3
  timelog_timer                  2.0.0

Janeks Kamerovskis wrote:

Is this available for:
[...]
?

According to #20992-2, it was set to be released in 3.1.2, so it should be available in your 3.2.1

FYI: I am working on the "restricted children" option mentioned in #5490-91 in a new issue #34609. Input is appreciated.