|
Notes |
|
|
|
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.
Thoughts? |
|
|
|
|
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. |
|
|
|
(0001738)
|
|
pedroa
|
|
2011-03-22 03:33
|
|
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. |
|
|
|
|
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. |
|
|
|
|
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.
Thoughts? |
|
|
|
|
Okay,
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 ? |
|
|
|
|
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. |
|
|
|
|
|
|
|
|
|
Resolved as noted in r1782 |
|
|
|
|
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.
Directorytrunk/modules/tasks/addedit.php
Directorytrunk/modules/tasks/do_task_aed.php
Directorytrunk/modules/tasks/tasks.class.php |
|
|
|
|
|
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. |
|
|
|
|
|
Closed in preparation for v2.3 |
|
BugMove1.JPG (160,584) 1969-12-31 16:00