Anonymous Login
2019-12-12 21:05 PST
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000078v2.4 Release (Closed)[All Projects] Generalpublic2008-11-13 01:392011-08-16 23:48
ReporterLarge_Fries 
Assigned Totrevormorse 
PriorityimmediateSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
Product Version 
Target VersionFixed in Version2.4 
Summary0000078: Task dependencies not cascading
DescriptionWhen updating the end date of a task which is at the beggining/middle of a dependency chain, none of the following task dates are updated correctly. This leads to an inaccurate representation of the finish date.
Additional Information1. Task Logs have the same problem.
2. If you use the 'Design this Project' module there is still no date cascading when you change the date of the first task in the dependency chain. However, if you then go to the next task in the dependency chain and (Using the 'actions' block of 'Design this Project') relink the dependency to the first task, all following tasks are updated correctly! This works all the way through the chain.
ie If I was to change the finish date of a task in the middle of the chain and re-link the dependency of the next item will cascade the dates of all the following tasks. Tasks before this are obviously not affected.
TagsNo tags attached.
Attached Files

-Relationships
related to 0000161closed Pending Requests Dependent tasks: changes in duration are not correctly applied to dependent tasks 
related to 0000216new Pending Requests Support Additional Task Dependency Types 
related to 0000422new Pending Requests implementation of Critical Path Method (CPM) to program 
related to 0000162closedcaseydk Pending Requests Should task dependencies cascade to earlier dates? 
related to 0000828closedcaseydk v2.4 Release (Closed) "Set task start date based on dependency" causes crash of database 
related to 0000829closedcaseydk v2.4 Release (Closed) Dependency tracking has no effect 
related to 0000832closedcaseydk v2.4 Release (Closed) Set time by dependancy 
related to 0000800closedcaseydk v2.4 Release (Closed) problem for changing dependant tasks 
related to 0000604closedcaseydk v2.4 Release (Closed) dependence issue between tasks 
related to 0000560closedcaseydk v2.4 Release (Closed) Incorrect start/stop date when Dependency tracking on 
related to 0000215new Pending Requests Task Dependency UI 
related to 0000163new Pending Requests Tracking Start Dates & Dependencies 
related to 0000452new Pending Requests Changing task duration does not re-calculate the task end date 
related to 0000451new Pending Requests Moving tasks by days in Project designer ignores non-working days 
+Relationships

-Notes

~0000188

caseydk (administrator)

2009-04-07 19:08

 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.

~0000189

caseydk (administrator)

2009-04-07 19:13

 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.

~0000195

Large_Fries (reporter)

2009-04-08 01:24

 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

~0000203

caseydk (administrator)

2009-04-09 14:34

 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. :)

~0000238

caseydk (administrator)

2009-04-27 19:36

 Can I get feedback/validation of this one? It's a critical one that I've been holding further updates for...

Thanks.

~0000245

Large_Fries (reporter)

2009-04-28 02:31

 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

~0000246

caseydk (administrator)

2009-04-28 05:38

 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 (administrator)

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.

~0000267

caseydk (administrator)

2009-05-06 18:52

 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.

~0000281

jortigosa (reporter)

2009-05-15 05:54

 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.

~0000284

caseydk (administrator)

2009-05-24 19:34

 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.

~0000291

Large_Fries (reporter)

2009-05-27 02:35

 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

~0000295

caseydk (administrator)

2009-05-31 21:17

 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.

~0000834

trevormorse (manager)

2010-04-22 04:20

 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

~0000863

Large_Fries (reporter)

2010-05-11 04:58

 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

~0000864

trevormorse (manager)

2010-05-11 16:38

 Ray, that would be awesome! Muchly Appreciated. Hopefully with that data I can create some good unit tests and finally get this fixed up.

~0000910

caseydk (administrator)

2010-05-29 22:21

 Any update? We'll need to get some test data soon to get this into the v2.0 release..

~0001038

opto (manager)

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 (manager)

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

~0001043

caseydk (administrator)

2010-06-15 10:55

 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 (manager)

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?

~0002148

caseydk (administrator)

2011-08-13 22:29

 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.
+Notes

-Issue History
Date Modified Username Field Change
2008-11-13 01:39 Large_Fries New Issue
2008-11-13 02:03 pedroa Status new => assigned
2008-11-13 02:03 pedroa Assigned To => pedroa
2008-11-13 02:04 pedroa Status assigned => acknowledged
2009-02-03 19:44 caseydk Project Pending Requests => v1.0 Release (Closed)
2009-04-07 19:08 caseydk Note Added: 0000188
2009-04-07 19:13 caseydk Note Added: 0000189
2009-04-08 01:24 Large_Fries Note Added: 0000195
2009-04-09 14:34 caseydk Note Added: 0000203
2009-04-27 19:36 caseydk Note Added: 0000238
2009-04-27 22:33 caseydk Priority normal => immediate
2009-04-27 22:33 caseydk Severity major => block
2009-04-28 02:31 Large_Fries Note Added: 0000245
2009-04-28 05:38 caseydk Note Added: 0000246
2009-05-01 21:34 caseydk Note Added: 0000254
2009-05-01 21:35 caseydk Note Edited: 0000254
2009-05-06 18:52 caseydk Note Added: 0000267
2009-05-15 05:54 jortigosa Note Added: 0000281
2009-05-15 08:00 caseydk Relationship added related to 0000161
2009-05-24 19:34 caseydk Status acknowledged => resolved
2009-05-24 19:34 caseydk Resolution open => fixed
2009-05-24 19:34 caseydk Note Added: 0000284
2009-05-27 02:35 Large_Fries Status resolved => feedback
2009-05-27 02:35 Large_Fries Resolution fixed => reopened
2009-05-27 02:35 Large_Fries Note Added: 0000291
2009-05-31 21:17 caseydk Note Added: 0000295
2009-06-21 12:47 caseydk Project v1.0 Release (Closed) => v1.1 Release (Closed)
2009-07-26 13:18 caseydk Relationship added related to 0000216
2009-09-08 22:54 caseydk Project v1.1 Release (Closed) => Pending Requests
2009-09-12 09:47 pedroa Severity block => major
2009-12-08 11:48 caseydk Project Pending Requests => v1.3 Release (Closed)
2010-03-25 04:08 caseydk Project v1.3 Release (Closed) => v2.0 Release (Closed)
2010-04-22 04:20 trevormorse Note Added: 0000834
2010-05-03 07:00 caseydk Relationship added related to 0000422
2010-05-11 04:58 Large_Fries Note Added: 0000863
2010-05-11 16:38 trevormorse Note Added: 0000864
2010-05-29 22:21 caseydk Note Added: 0000910
2010-06-04 11:11 caseydk Status feedback => assigned
2010-06-04 11:11 caseydk Assigned To pedroa => trevormorse
2010-06-13 16:53 caseydk Project v2.0 Release (Closed) => Pending Requests
2010-06-15 08:31 opto Note Added: 0001038
2010-06-15 10:30 opto Note Added: 0001042
2010-06-15 10:36 opto Note Edited: 0001042
2010-06-15 10:55 caseydk Note Added: 0001043
2010-06-15 11:00 opto Note Added: 0001044
2010-06-26 21:12 caseydk Relationship added related to 0000162
2011-07-03 23:34 caseydk Relationship added related to 0000828
2011-07-03 23:34 caseydk Relationship added related to 0000829
2011-07-03 23:35 caseydk Relationship added related to 0000832
2011-07-03 23:35 caseydk Relationship added related to 0000800
2011-07-03 23:48 caseydk Relationship added related to 0000604
2011-07-03 23:49 caseydk Relationship added related to 0000560
2011-07-03 23:49 caseydk Relationship added related to 0000215
2011-07-03 23:50 caseydk Relationship added related to 0000163
2011-07-03 23:54 caseydk Relationship added related to 0000452
2011-07-03 23:54 caseydk Relationship added related to 0000451
2011-08-09 12:54 caseydk Project Pending Requests => v3.0 Release
2011-08-13 22:24 caseydk Project v3.0 Release => v2.4 Release (Closed)
2011-08-13 22:29 caseydk Note Added: 0002148
2011-08-13 22:29 caseydk Status assigned => resolved
2011-08-13 22:29 caseydk Resolution reopened => fixed
2011-08-16 23:48 caseydk Status resolved => closed
2011-08-16 23:48 caseydk Fixed in Version => 2.4
+Issue History