Anonymous Login
2022-10-05 17:26 PDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001217v3.0 Release[All Projects] Generalpublic2013-08-28 11:18
Assigned Tocaseydk 
PrioritynormalSeverityminorReproducibilityhave not tried
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.
Attached Files

parent of 0001342closedcaseydk importtasks broken (dates unusable) 
parent of 0001344closedcaseydk workaround: importtasks sets wrong date for dynamic tasks 



sasquatch58 (reporter)

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


carlosazevedo (reporter)

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.


opto (manager)

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.


carlosazevedo (reporter)

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.


caseydk (administrator)

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
Date Modified Username Field Change
2012-11-25 10:09 opto New Issue
2012-12-30 23:39 sasquatch58 Note Added: 0002760
2013-01-17 23:53 sasquatch58 Note Edited: 0002760
2013-03-21 01:11 carlosazevedo Note Added: 0002862
2013-03-21 02:11 opto Note Added: 0002864
2013-03-21 02:11 opto Note Edited: 0002864
2013-03-21 02:12 opto Note Edited: 0002864
2013-03-21 10:42 carlosazevedo Note Added: 0002866
2013-08-03 15:12 caseydk Relationship added parent of 0001342
2013-08-03 15:12 caseydk Relationship added parent of 0001344
2013-08-03 22:40 caseydk Note Added: 0002982
2013-08-03 22:40 caseydk Status new => resolved
2013-08-03 22:40 caseydk Resolution open => fixed
2013-08-03 22:40 caseydk Assigned To => caseydk
2013-08-28 11:14 caseydk Fixed in Version => 3.0.0
2013-08-28 11:18 caseydk Status resolved => closed
+Issue History