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?