| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0000078 | v2.4 Release (Closed) | [All Projects] General | public | 2008-11-13 01:39 | 2011-08-16 23:48 | ||||
| Reporter | Large_Fries | ||||||||
| Assigned To | trevormorse | ||||||||
| Priority | immediate | Severity | major | Reproducibility | always | ||||
| Status | closed | Resolution | fixed | ||||||
| Product Version | |||||||||
| Target Version | Fixed in Version | 2.4 | |||||||
| Summary | 0000078: Task dependencies not cascading | ||||||||
| Description | When 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 Information | 1. 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. | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files |
| ||||||||
 Relationships |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Relationships |
| Notes |
|
|
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. |
|
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. |
|
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 |
|
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. :) |
|
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. |
|
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 |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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 |
|
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. |
|
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 |
|
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 |
|
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. |
|
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.. |
|
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 |
|
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 |
|
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. |
|
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? |
|
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 |