MantisBT - v3.0 Release
View Issue Details
0001217v3.0 Release[All Projects] Generalpublic2012-11-25 10:092013-08-28 11:18
Assigned Tocaseydk 
PrioritynormalSeverityminorReproducibilityhave not tried
PlatformOSOS Version
Product Version 
Target VersionFixed in Version3.0.0 
Summary0001217: dependency questions/confusions
Description1) can a dynamic task be dependent on another task, or should the earliest child be the dependent one? If the latter, the dependency settings should disappear in the edit box once dynamic is checked.

I did the following, which is confusing/buggy in its display

1) make the dynamic task the dependent. Gantt didn't change its start
2) make the first child the dependent. Child start is correctly shifted, but dynamic not updated (still starts at old date)
3) unset the dependency of the dynamic: now it is recalculated, everything looks fine
4) shift start date of the dependent task (which is the first task of the dynamic): addedit allows to set date, which then reverts back -> current setting is to force 0 days between end/start of dependent tasks -> setting start date should be disabled when dependent? Or checkbox to aloow to later (but not earlier) date? That might be preferable
5) shift the task which the other is dependent on by 2 weeks into another month:
the task is not shown shifted in gantt or task list but the start of the dependent task has been shifted
!!!! this task edit was done in FF in a new FF instance /window, by clicking the little edit icon and holding shift, on win 7

6) maybe also put into forum as question: there is a need to make dynamic tasks be able to be dependent on other tasks. (when a block of subtasks is dependent on an event, e.g. receive supplies). This cannot be mimicked by making the first task dependent - if the top task shifts, only that one wouuld be shifted.
One could make all children dependent, but that is tedious if there are many, creats many dependency arrows in gannt - it would be nicer just to make the dynamic parent dependent on that event.
TagsNo tags attached.
parent of 0001342closed caseydk importtasks broken (dates unusable) 
parent of 0001344closed caseydk workaround: importtasks sets wrong date for dynamic tasks 
Attached Files

2012-12-30 23:39   
(Last edited: 2013-01-17 23:53)
My observations would be that the dependency functionality has changed (broken) compared to V2.31. Opto's notes line up with my findings with V3 git 97669153748c28422b774b6da6bfb314557d77a5
Also - cannot remove dependency without deleting the task but can do this in V2.31.

Update as at 18 Jan - still can't remove dependency via Edit this Task but can remove it using Project Designer

2013-03-21 01:11   
I've done a lot of work on task dependencies, which should now work sensibly. You can get the patches at my (temporary) fork at

A dynamic task's start date can't depend on the end date of another task. What should be done is making the earliest child(s) dependant of that other task and make any other children dependant on those, if needed. This way the dynamic task's dates will match the dates of its children.
Nevertheless it is possible to make a task dependant on a dynamic task, in which case its start date will track the dynamic's end date.
2013-03-21 02:11   
(Last edited: 2013-03-21 02:12)
>A dynamic task's start date can't depend on the end date of another task.

that could be discussed. Example:

dynamic task: paint house
subtasks: buy paint, buy brush, paint etc.

dynamic task cannot be started before windows are installed.

It would make more sense to have the dynamic parent dependent on 'install windows'. than to have buy paint dependent on the windows.

It is a perspective of view: if the windows are late, I want to delay the whole dynamic painting, not only the buying paint.

1) allow dynamic task to be dependent
2) if needs to be shifted: search for earliest starting subtask, then shift that.

see also 6) in my original post: if I make the child dependent, and for some reason I now decide that I have to buy the brushes before the paint and forget to make that now dependent, my painting may start before the windows are installed.
In the example before, it really is the whole dynamic task (with all subtasks that are entered now or will be added in the future) that I want to shift, not an individual subtask.

I need a way to model that in w2p.

There is another dependency issue currently: tasks are not shifted backwards in time.

That can be a substantial blocker for using w2p: it does not allow to speed up a project in planning. Late tasks can shift the end to later.
But if I speed up something, the end will not be earlier. So if my customer asks for an early delivery, there is not way to model that in w2p.

2013-03-21 10:42   
Both are valid points but they require large changes in the code. For now my priority lie in getting the code usable for real-world deployment at our company group. I will try to get more work on this approved but for now no big changes unless its broken to the point of useless.
2013-08-03 22:40   
Reworked this whole thing in the latest development. You can see the changes in Github but here's one of the most important ones:

Issue History
2012-11-25 10:09optoNew Issue
2012-12-30 23:39sasquatch58Note Added: 0002760
2013-01-17 23:53sasquatch58Note Edited: 0002760
2013-03-21 01:11carlosazevedoNote Added: 0002862
2013-03-21 02:11optoNote Added: 0002864
2013-03-21 02:11optoNote Edited: 0002864
2013-03-21 02:12optoNote Edited: 0002864
2013-03-21 10:42carlosazevedoNote Added: 0002866
2013-08-03 15:12caseydkRelationship addedparent of 0001342
2013-08-03 15:12caseydkRelationship addedparent of 0001344
2013-08-03 22:40caseydkNote Added: 0002982
2013-08-03 22:40caseydkStatusnew => resolved
2013-08-03 22:40caseydkResolutionopen => fixed
2013-08-03 22:40caseydkAssigned To => caseydk
2013-08-28 11:14caseydkFixed in Version => 3.0.0
2013-08-28 11:18caseydkStatusresolved => closed