I find it a little inconvenient that the main, container task, which is essentially a title of a "project", shows up in the lists along with its subtasks, which represent actual tasks itself. So, when you are changing something in a subtask, say, priority or due date, you need to decide also what to do to the container task; otherwise, it will show up in situations where you do not want it to. Does anybody have a practice, set of rules how to handle this situation?
I don't have a solution, but will sympathize with this issue. It seems that the TD parent/sub tasks relationship are in structure only and are not "smart."
Years ago I wrote a goal-tracking program that used algorithms to update a parent task based on its children. For example: the time required would be at least a sum of all the time required for the sub-tasks; the due date of all the sub-tasks would be at-latest the due date of the parent (unless one of the subs' due dates are changed), etc.
It can really be a can-o-worms to implement especially on a live system like TD.
Very problematic, especially when everyone in these forums would want it differently that everyone else.
U Back to topic home
R Post a reply
To participate in these forums, you must be signed in.