Task without predecessor are moved

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open a file that contains tasks without predecessors (ie not incoming 
relations)
2. See that these tasks are moved to the start date (of their super task)

I have noticed it first since the GanttProject 2.6 Brno RC IV release, and it 
is still present when I build the latest source.

Maybe something went wrong in the fix of issue #646 ?

Original issue reported on code.google.com by maarten....@gmail.com on 19 Nov 2012 at 10:18

[GoogleCodeExporter]

See my PhD thesis planning :)
 * All completed tasks are left alone, but the tasks that still need to be done are all shifted to the start date of their super task (which have incoming dependencies and are left alone)
 * Also note the warning of GP that the tasks have been updated

Original comment by maarten....@gmail.com on 19 Nov 2012 at 10:21

Attachments:

• proefschrift_planning.gan

[GoogleCodeExporter]

revision 7250d31ea036 
(http://code.google.com/p/ganttproject/source/detail?name=a9e36e583f9a&r=7250d31
ea03683f7c5694af01300b097507d146e) is the first revision where this problem 
seem to occur.

As the scheduling algorithm is activated and breaks I am not 100% certain, but 
1 revision earlier is able to correctly load the attached file.

Original comment by maarten....@gmail.com on 19 Nov 2012 at 10:37

[GoogleCodeExporter]

Interesting. Thanks for reporting, Maarten!

Original comment by dbarashev on 19 Nov 2012 at 11:04

• Changed state: Accepted
• Added labels: __Target-Brno

[GoogleCodeExporter]

Well, it happens because of dependencies drawn to supertasks and it raises a 
number of questions. 

For instance, in your project, if you make task #0 1 day longer, so that it 
ends on Nov 5 (e.g. by making longer one of its subtasks), shall task #21 be 
shifted to start on Nov 6? Probably yes. How shall its subtask be shifted? 
Shall task #30 start on Nov 20 or rather stay on Nov 19? Probably the latter, 
but that's not so obvious. 

Another question: if you manually shift tasks #22 and #23 so that they start on 
Nov 6, then their supertask #21 start date will also become Nov 6. Shall it be 
shifted by its dependency back to Nov 5? 

I think that the solution is to make dependencies drawn to supertasks always 
weak, but if you see any drawbacks or other solutions, let me know

Original comment by dbarashev on 19 Nov 2012 at 12:22

[GoogleCodeExporter]

In this situation I would expect that the supertask (#21) is shifted (due to 
the dependency). I think this will indeed happen..?

As the super task (#21) is shifted, I would expect that all sub-tasks (#22, 
#23, #30) of this super task are also shifted. Especially since they have no 
dependencies outside the super-task.

I would think so yes... Although it seems weird to the user, it is perfectly 
explainable by the dependency to super task #0
If the user does not like this, the dependency should be set to rubber/weak, 
or removed all together...

I wonder whether this will solve this issue: the sub-tasks to not use this 
dependency? So they are still moved to the start of the super-task

I think, the problem is, that I cannot create non-depending sub-tasks with an 
arbitrary start date. (And that the old sub-tasks are moved to the start of 
the super-task (since revision 7250d31ea036))

It is even more a problem, since there are seemingly no limitations 
(dependencies) for these sub-tasks and still it is not possible to move them 
around (within the super-task).

Original comment by maarten....@gmail.com on 19 Nov 2012 at 12:46

[GoogleCodeExporter]

Hm... the quoted texts are removed...

The first two paragraphs are a response on your first question and the third to 
your second ('another') question.

Original comment by maarten....@gmail.com on 19 Nov 2012 at 12:48

[GoogleCodeExporter]

I've made inherited dependencies weak and it works more or less good. You can 
try it locally if you change implementation of 
DependencyGraph.ImplicitInheritedDependency.isWeak() to "return true"

The only problem which I see is that should predecessor change its end date to 
earlier date (e.g. end date of task #0 to Nov 1) then its successor supertask 
#21 stays on its place instead of moving back. We can add, say, "compact 
schedule" action to solve this issue.

In my opinion, the answer "yes" to my second question will frustrate and 
confuse users, since moving a bunch of tasks backward (supertask and possible 
dependencies from that supertask) is probably not what they want when they move 
a single task forward

Original comment by dbarashev on 19 Nov 2012 at 1:08

[GoogleCodeExporter]

This issue was closed by revision 4826ebb24e0f.

Original comment by dbarashev on 19 Nov 2012 at 2:12

• Changed state: Fixed

[GoogleCodeExporter]

I can open my planning again and it works as expected (without confusion)! :)

Original comment by maarten....@gmail.com on 19 Nov 2012 at 2:59

[GoogleCodeExporter]

Original comment by dbarashev on 22 Sep 2014 at 12:22

• Changed state: Verified