Anonymous Login
2022-10-02 04:54 PDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001013v3.0 Release[All Projects] Generalpublic2013-08-28 11:22
Assigned Tocaseydk 
Product Version 
Target VersionFixed in Version3.0.0 
Summary0001013: creating a dependent task does not set its start date acc to dependency
Descriptioncreate a task, make it dependent on task 'A'. Nevertheless, it keeps it soriginal start date upon save.
Go to A, change dates, then, the dependent task will be updated.

So whether dependencies work depends on the order the tasks are entered.
Meaning, tasks should be entered end to start to have depenencies correct.
TagsNo tags attached.
Attached Files




caseydk (administrator)

Are you using the "Set task start date based on dependency" checkbox?

When you create that second Task, if you make it dependent on A and use that checkbox, the second Task's start date will be based on A. Then, as Task A moves later, the second Task with shift as expected.

There are two potential oddities:
- if Task A shifts earlier, the second Task will not shift earlier;
- if you edit the second Task again, this checkbox does not remain set. This makes sense if you think of the checkbox as a macro/helper as opposed to a setting.


opto (manager)

1) checkbox does not remain set:

That is a major bug.
Do I reassign the assignees every time I edit something else in a task?
Do I reenter the task description every time I edit a date?

Whatever is part of the task edit screen must be a permanent entry between different editing times of the task (after save). If checked, stay checked until I uncheck it in a future edit.

Having to recheck this everytime I do any unrelated edit on the task? Which employees will be expect this or will be able to remember this?

Do you reset the paper format everytime when you change the page margin in OOO?
Like, it is hardcoded to letter, I set to A4, but next time I do an edit on a different setting, it falls back to letter?

This defineitely is a bug, not a feature.

2) Even if i assign a start date to the dependent task, I would expect it to bring over the dependencey on its (!) first and on all concecutive save.

At the moment, editing A shifts the second task (at least to later,I would opt also to earlier).

But any save on the second task should also set its start start date dependent on task A.
Otherwise, the second task's start date may be declared to be dependent, but NEVER be adjusted if I first create task A, then second task, but then never change task A.

Now, everybody would expect the second task to be dependent on A, but its date has never been adjusted from what was entered on creation, because we start the dependency mechanism only on edit of the 'father' task, not upon edit of the children.


caseydk (administrator)

Until we support offsets between dependent tasks, I'm going to set the "Set task start date based on dependency" checkbox to be marked by default.

I don't think it's ideal but it should be right in the vast majority of situations.. and if people *do* want to have a gap between the current task and its predecessors, the Dates tab is available right there.


opto (manager)

fine, but that does not deal with the other issue:

if I first create parent, then dependent child, the child's date is NOT adjusted upon save. (see first post/description).
That is a major bug.


caseydk (administrator)

If the "Set task start date based on dependency" checkbox is set, you should be able to enter them in any order you want as long as you set the dependencies correctly.

That checkbox will do the date update the first time and then any time a task is updated, all of its dependent tasks will update as expected down the entire chain..


opto (manager)

no, not in the version active when I wrote the bug message.

At that time, even a set checkbox did not update the dates upon save of the dependent child. See description of bug. At that time, dependencies were never updated on save of the dependent task. They were only updated upon save of the task it is dependent on.

I looked at the code and it was set explicitly like that somewhere in save or save-check.


caseydk (administrator)

Specific patch:

-Issue History
Date Modified Username Field Change
2011-11-11 11:56 opto New Issue
2011-11-24 16:59 caseydk Priority normal => urgent
2011-11-25 10:26 caseydk Note Added: 0002311
2011-11-25 10:26 caseydk Status new => feedback
2011-11-28 04:21 opto Note Added: 0002332
2012-08-07 21:13 caseydk Note Added: 0002631
2012-08-07 21:13 caseydk Status feedback => assigned
2012-08-07 21:13 caseydk Assigned To => caseydk
2012-08-07 22:11 opto Note Added: 0002633
2012-08-08 19:39 caseydk Note Added: 0002634
2012-08-08 21:59 opto Note Added: 0002635
2012-09-17 21:15 caseydk Note Added: 0002652
2012-09-17 21:15 caseydk Status assigned => resolved
2012-09-17 21:15 caseydk Resolution open => fixed
2013-08-28 11:14 caseydk Fixed in Version => 3.0.0
2013-08-28 11:22 caseydk Status resolved => closed
+Issue History