Anonymous Login
2022-10-05 17:12 PDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000744v2.3 Release (Closed)[All Projects] Generalpublic2011-03-29 22:26
Assigned Totrevormorse 
Product Version 
Target VersionFixed in Version2.3 
Summary0000744: The "Move" functionality doesn't work
DescriptionWhen you type 20 (days) or anything else in the field Move, the task doesn't move.

But It does work when there is no dependancy
TagsNo tags attached.
Attached Files




trevormorse (manager)

web2project checks that the task is not dynamic and does not have dependencies before allow a bulk move.

If either of these is true we do not do the move, but also aren't displaying any kind of message. I think adding messaging will work.



ckwanhu (reporter)

I think the initial idea was to allow bulk move.

It does work that way on the demo.

If you can't move a task which has dependancies, imagine a project with dependancies for all the task, then something happens and you delay the start of the project. In that case, you also want the end to be delayed.

Then I do understand that if you move a task with a dependancy, you can move it after the task which should start after the task you are moving.
Then I think a warning should be that you won't check it and that the user must be careful.


pedroa (administrator)

I think that when dependencies are involved, at least the tasks that are not dependent on any of the others should be able to be moved.
In web2Project case would probably be the first in time, since the others "depend" on that one.
So if you move that first task 20 days, the others would also move, not by the effect of ProjectDesigners move, but rather due to the Dependencies algorithm.

Pedro A.


ckwanhu (reporter)

I am okay with pedroa on
"So if you move that first task 20 days, the others would also move, not by the effect of ProjectDesigners move, but rather due to the Dependencies algorithm."

But when you try it, it doesn't move.

I really think that you should be able to move tasks in a bulk whether you move all the tasks you select or you move the first task and the depending task move by themself with the dependancy algorithm.


trevormorse (manager)

Hi There,

To test this I created a project with two tasks "task 1" and "task 2" with task 2 being dependant on task 1.

If I attempt to move task 2 nothing happens, but if I move task 1 then task 2 is update appropriately.

It looks like we are refusing to move tasks that depend on other tasks. I think this is to protect against the scenario where you moved both of these tasks, causing task 2 to be much later then you expected.

For instance if you moved both tasks 10 days, task 1 would be moved 10 days and task 2 would be moved appropriately. Then task 2 would be moved another 10 days for a total of 20 days.

In my mind that would be unexpected behaviour.



ckwanhu (reporter)


that means that if you have 5 tasks

Task1 -> Task2
                  -> Task 5
Task3 -> Task4

Task 5 is dependant on Task 2 and 4.

If you move Task 1, nothing will move since it will trigger the move of task 2 and task 5 and the move of task 5 is not possible (You said "If I attempt to move task 2 nothing happens")

If what I say is correct, it is impossible to move a complex project with a lot of dependancies.

As is said, it is working on the demo (v2.01).
Is the dependancy algorithm not used on the demo ?


trevormorse (manager)

So, after some very deep digging you are correct. There is a bug in here causing this move not to cascade when it should.

Fix will be coming this weekend and will hopefully be included in the 2.3 release due next week.

I will post back here when it is fixed.


trevormorse (manager)

Hi there,

This has been fixed in this commit: and should be included in v2.3

Now, when you move task 1, the tasks dependent on it will move the same number of days.

Please let me know if this fixes the problem for you as well.


caseydk (administrator)

Resolved as noted in r1782


ckwanhu (reporter)

I replaced all the files given in r1782.

But, it leads to problems with the project importer.

The importer only adds the first task without any child, and it isn't written Success when you import.

I know that the files involved are the three files from the Tasks module.



caseydk (administrator)

You can't just update those files.. you have to update everything through r1782. I've validated it with the latest and greatest and all is well.


caseydk (administrator)

Closed in preparation for v2.3

-Issue History
Date Modified Username Field Change
2011-03-11 03:44 ckwanhu New Issue
2011-03-11 03:44 ckwanhu File Added: BugMove1.JPG
2011-03-21 15:42 trevormorse Status new => assigned
2011-03-21 15:42 trevormorse Assigned To => trevormorse
2011-03-21 15:44 trevormorse Note Added: 0001736
2011-03-21 15:44 trevormorse Status assigned => confirmed
2011-03-22 02:21 ckwanhu Note Added: 0001737
2011-03-22 03:33 pedroa Note Added: 0001738
2011-03-22 04:55 ckwanhu Note Added: 0001739
2011-03-22 15:31 trevormorse Note Added: 0001743
2011-03-22 23:12 caseydk Project v2.3 Release (Closed) => v2.4 Release (Closed)
2011-03-23 02:27 ckwanhu Note Added: 0001752
2011-03-24 17:43 trevormorse Note Added: 0001786
2011-03-26 11:47 trevormorse Note Added: 0001799
2011-03-27 23:36 caseydk Project v2.4 Release (Closed) => v2.3 Release (Closed)
2011-03-27 23:36 caseydk Note Added: 0001812
2011-03-27 23:36 caseydk Status confirmed => resolved
2011-03-27 23:36 caseydk Fixed in Version => 2.3
2011-03-27 23:36 caseydk Resolution open => fixed
2011-03-29 04:47 ckwanhu Note Added: 0001816
2011-03-29 04:47 ckwanhu Status resolved => feedback
2011-03-29 04:47 ckwanhu Resolution fixed => reopened
2011-03-29 21:40 caseydk Note Added: 0001819
2011-03-29 21:40 caseydk Status feedback => resolved
2011-03-29 21:40 caseydk Resolution reopened => fixed
2011-03-29 22:26 caseydk Note Added: 0001825
2011-03-29 22:26 caseydk Status resolved => closed
+Issue History