|
Notes |
|
|
|
I NEED FEEDBACK ON THIS ONE.
In r366, I made some progress on the cascading task issues:
-- tasks move forward as preceeding tasks move later assuming you have "dependency tracking" set to "on";
-- tasks do not move backwards if the preceeding tasks are moved backwards;
-- this process travels down each branch of the dependency tree starting from the edited task, it does *not* update the entire project;
-- this method does allow a chain of A->B->C to be corrupted if someone manually moves B back before A.. not sure how to protect against dumb users here...;
I NEED FEEDBACK ON THIS ONE. |
|
|
|
|
|
And for the record... this isn't necessarily the final version. It's a version that works with my scenarios. Once I get some feedback/corrections/improvement, we can improve and eventually refactor it. |
|
|
|
|
Keith,
I can see that the edit task portion of the program does work now. But the log (When you delay a task) and the project designer (multiple selection, although just selecting 1 task) still do not. Good start though! :-) Gives our guys something to work with now. Out of all remaining errors though, the log one is the most critical.
Thanks |
|
|
|
|
Added calls to the function to get those additional places working.
Once I - and a few others - are confident in this working, I think it makes the most sense to be moved back to the Task store() method. That way *whenever* you save the Task, all of its dependencies will update down the line. There won't need to be a separate call at all.
Besides, then it's less code to consider in general. :) |
|
|
|
|
Can I get feedback/validation of this one? It's a critical one that I've been holding further updates for...
Thanks. |
|
|
|
|
cascade test - so far!
Using Update task in project designer
Tested on Project Archived
task 100% complete.
Date Increased but no affect observed on cascade
Tested on Project Archived
Milestone
Date Increased - Cascade successful
Tested on Project Archived
Sibling of dynamic task - dynamic task was a dependancy
Moved sibling - dynamic task did not cascade other tasks
Tested on Project Archived
Re-saved Dynamic task from above but didn't edit task.
Cascade now successful
Tested on Project Archived
Dependant task with tasks depending
Date Increased
Cascade successful
Using Multiple selection in web designer
Tested on Project archived
milestone at beginning of thread - start date changed
cascade successful
Tested on Project Archived
task 100% complete.
Changed Date but no affect observed on cascade
Observed date error if end date not entered as start date could be after end date. Gantt chart produces diagnal lines
Tested on Project Archived
Dependant task with tasks depending
Date Increased
Cascade successful
Task Logs
Tested on Project Archived
Dependant task with tasks depending
Date Increased
Cascade successful
Tested on Project Archived
Milestone
Date Increased - Date change not accepted but log created - Cascade failed (design feature?)
thanks
Ray |
|
|
|
|
Ray, you're my hero. :)
I'll dig into your results in the next few days and might ask for clarification or more info.
Thanks. |
|
|
|
(0000254)
|
|
caseydk
|
2009-05-01 21:34
(Last edited: 2009-05-01 21:35) |
|
Large_Fries,
I've tried to reproduce your results with little success... any chance you'd be willing to share a snapshot of your database?
Feel free to email to me directly: keith @ caseysoftware
Thanks.
|
|
|
|
|
I've manually run through another round of testing to make sure pushDependencies() is applied to milestones (yes!) and on all bulk updates. Instead of adding more calls to the function, I added it to the store() method of the Task object. Now, whenever someone saves a task the proper way, all tasks should cascade as expected.
This is in r400.
Of course, this doesn't work if someone just writes directly to the database.
Any testing, feedback, suggestions, or fixes would be appreciated. |
|
|
|
|
The "cascading" of the dependencies works only in dependency chains that are "single lined" (I do not know of to name it, but it's when they ar just one line of dependencies).
If taks C depends on both task B and A at the same time, if task A duration is changed in such a way that task C should be modified, it does not work.
In this case, the 'actions' block in the "design this project" is not useful, as only one task can be chosen to relink teh dependency of task C. |
|
|
|
|
Alright, I'm calling this one resolved. *Whenever* a Task end date is changed, it checks on all Tasks dependent on it and updates those... which then updates any Tasks dependent on those and so on and so on.
This includes whenever a Task is updated via the Task Edit screen, via the Tasklogs, via the Project Designer, via a subtask changing a dynamic Task, etc, etc. It's actually part of the store() method on the Task class.
I've just done another round of tests with:
A dynamic parent Task D with subtasks A->B->C dependent sequentially;
With another root Task E dependent on D (the dynamic task);
With another root Task F which is a dependency for B.
Updating A, B, or C updates D which updates E.
Updating D doesn't do anything... it's dynamic and defaults back to the A, B, C combo.
Updating E doesn't do anything.
Updating F updates B and C which updates D which updates E.
Of course, if there are modules - or custom code - which updates the db directly, this is completely bypassed. If you know of any of those, please let me know and I'll take care of them. |
|
|
|
|
Keith,
Sorry to give the bad news, but I'm pretty sure we still have a problem. I have spent 3 hours testing the latest version (422) and results are as follows.
All test were using the edit function through project designer.
Test 1
1. Conditions - 18 tasks in one continuous chain of dependency (2 dependent on 1, 3 dependent on 2, 4 dependent on 3 etc...all the way to 18.
2. Increased date of task 1 by 15 days.
3. Result - Only tasks 2 and 3 were cascaded, 4 and onwards missed the boat.
Test 2.
1. Conditions - 5 dynamic tasks with 3 siblings each. Each set of 3 siblings was set as dependent on the previous dynamic task.
2. Increased date of 1st sibling task in first dynamic, beyond the start of the next dynamic task.
3. Result - only next 2 dynamic task cascaded correctly. Balance of tasks remained with same start and finish date.
Test 3. Same as Test 2, but added milestones between each dynamic task and changed dependency as follows; milestone 1 dependent on end date of dynamic 1, sibling tasks of dynamic 2, all dependent on milestone. I followed this logic through to the end of the project.
3. Result as per test 1 and 2.
Note.
I created all these projects from scratch and used a mixture of project designer and standard task creation to create the projects. They were all new and not recycled from existing projects.
Summary.
There seems to be a block after 2 rounds of cascade checks. It obviously works on the first 2 headline dates it sees but doesn't go beyond that. There are no signs of any date changes after the first 2 tasks/dynamic tasks/milestones.
That's about it for now. I'll let you know if anything else crops up :-)
Cheers |
|
|
|
|
Bah.
I'm seeing some weird behavior on this one... I set up a new chain from scratch (A->B->C->D->E->F) with each task being 3 days and dependency tracking on for all.
With the previous version of code (r417), if I update the chain, the parent of the last task (F) is reset to the parent of the task I'm editing. For example, editing A sets F's parent to null while editing B sets F's parent to A.
Removing the following two lines:
$this->load($nextTask['task_parent']);
$this->updateDynamics(true);
make that a bit cleaner a prevent the parent from being loss... but it re-opens the issue where a task chain dependent on a dynamic task doesn't always get updated.
I'm willing to call that one a "known issue" and roll without it.
Large_Fries, to get deeper into your issue, I need a snapshot of your data. |
|
|
|
|
Large_Fries,
I am starting to work on creating unit tests for these particular problems and was wondering if I could get a snapshot of your data?
I may even be able to work from a screen shot if you'd prefer that, but will need to know which tasks have dependency tracking turned on.
Thanks,
Trevor |
|
|
|
|
Trevor, apologies for late reply. I will have to create a neutral project as the data I am using is confidential. Will advise back ASAP. NB: Good to see it back on the target list.
Regards
Ray |
|
|
|
|
|
Ray, that would be awesome! Muchly Appreciated. Hopefully with that data I can create some good unit tests and finally get this fixed up. |
|
|
|
|
|
Any update? We'll need to get some test data soon to get this into the v2.0 release.. |
|
|
|
(0001038)
|
|
opto
|
|
2010-06-15 08:31
|
|
I did some testing:
on initial making task A dependent on task B, the start of A is not updated with respect to the end of task B. I would expect it to update.
(2.0.0 14.6.2010)
When I then manually update the task end of B, that is reflected in A.
So maybe on storing A, we need to check: is change in dependency handling, if yes, recalculate the chain even if date has not changed.
Klaus |
|
|
|
(0001042)
|
|
opto
|
2010-06-15 10:30
(Last edited: 2010-06-15 10:36) |
|
well, I am blind, but the code showed what to do.
feature request: put the check box .. set start time according to dependencies
next to the use dependencies switch.
In principle, they are two sides of a coin:
a) store dependencies, but don't do anything about it (with respect to dates)
b) store dependencies and apply the dates.
Inconsistent is: on task edit, this needs to be checked to apply the new date.
on date change of the task this is dependent on, the date change is applied without asking. So maybe this should always be checked? Or be part of project options?
and: isn't the action of dependency tracking: off identical to not checking the set startdate upon dep. checkbox?
at least, even if setting the dep. tracking off, the tasks this one is dependent on are still displayed
|
|
|
|
|
Personally, I think Dependency Tracking should be on by default. If you've gone to the effort of setting up dependencies, you obviously care about them. As things are running late, you'd want to know.
Unfortunately, I don't know how others are/aren't using this at present. |
|
|
|
(0001044)
|
|
opto
|
|
2010-06-15 11:00
|
|
same for me.
so the checkbox should always be set (or removed, because dependency tracking on has the same meaning? |
|
|
|
|
Whew.. as of r2029 this evening, the vast majority of this one is solved.
The problem was four fold:
- First, the duration calculation was wrong;
- Next, the duration was being applied at the wrong step;
- Next, since it was using the w2p_Database_Query to update the Task instead of Task->store(), the cascading was not being applied consistently;
- Finally, timezones weren't being applied consistently so even when the calculation seemed right, it didn't save correctly.
The second portion of this issue - related to the Project Designer - should now be followed as 0000451 and 0000452. Once that is properly wired using the ->store() methods, etc, it should work as expected. |
|