What is the concept behind subtask date incrementing with parent recurrence?
Posted: Mon Apr 22, 2024 1:59 pm
Sorry for the fuzzy subject line, I had trouble deciding what to call this topic. 
I have a relatively complicated project that has to be completed once per year. It has about 50 or more subtasks in its tree. Generally, each of those subtasks retains the same month and day for its start and due date from year to year, only the year gets advanced when the task is completed.
Some time ago I discovered a behavior that I like to use for task trees like this.
Instead of making each individual task recurring, so that it recurs once per year, I only need to make the root parent task recur annually: all the subtasks occur only 'Once'. Then when the project is finished for the year, I only need to set the root parent attribute to completed, and all of the subtasks will automatically advance their 'Start' and 'Due' dates to the next year.
One of the key advantages to this is that when a subtask is completed, instead of advancing its date to the following year, it causes the strikeout line across the task. If it was set to recur, the date would be advanced and there would be no strikethrough line on the task to allow easy visual identification that it was completed for the year.
This has a couple of advantages.
First it allows me to look at each subtask branch and quickly see which subtasks have been completed. It's easy to see, they all have strikethrough font. If they were each set to occur individually this would not be the case and I would have to inspect each subtask carefully to see what year it is set to. I would only know if it was completed if it was set to the current year plus one. (Sidenote...If the project spanned two calendar years then it would really be confusing to figure out which tasks were completed and which tasks were not.).
The second benefit is that the tree and branches retain their sort order when the sort order includes 'Start' and/or 'Due' date. Since the subtasks are not recurring, the completed tasks will appear at the bottom of the tasks in the branch making them intuitively easy to identify. If they were set to recurring, they would follow the sort order which could be confusing since you will have next year's tasks mixed in with this year's tasks and no strike through to identify which ones are done for the year.
It seems clear that this behavior has to do with subtasks inheriting their parents' attributes in some way. But it doesn't seem to completely fit the inheritance concept. I'm fuzzy on this and hoping you can shed some light on it for me.
In addition to the pros, there is a con or two to this method also. But I'd like to try to understand this tree behavior better before explaining that since it's a bit mysterious to me.
My question:
The subtasks don't seem to be "inheriting" their parents' recurrence attributes exactly because they are still only set to 'Once' even though the root parent is set to recurring, but they are inheriting the date increment when the parent is set to completed. Is there a concept that explains this behavior?
I have a relatively complicated project that has to be completed once per year. It has about 50 or more subtasks in its tree. Generally, each of those subtasks retains the same month and day for its start and due date from year to year, only the year gets advanced when the task is completed.
Some time ago I discovered a behavior that I like to use for task trees like this.
Instead of making each individual task recurring, so that it recurs once per year, I only need to make the root parent task recur annually: all the subtasks occur only 'Once'. Then when the project is finished for the year, I only need to set the root parent attribute to completed, and all of the subtasks will automatically advance their 'Start' and 'Due' dates to the next year.
One of the key advantages to this is that when a subtask is completed, instead of advancing its date to the following year, it causes the strikeout line across the task. If it was set to recur, the date would be advanced and there would be no strikethrough line on the task to allow easy visual identification that it was completed for the year.
This has a couple of advantages.
First it allows me to look at each subtask branch and quickly see which subtasks have been completed. It's easy to see, they all have strikethrough font. If they were each set to occur individually this would not be the case and I would have to inspect each subtask carefully to see what year it is set to. I would only know if it was completed if it was set to the current year plus one. (Sidenote...If the project spanned two calendar years then it would really be confusing to figure out which tasks were completed and which tasks were not.).
The second benefit is that the tree and branches retain their sort order when the sort order includes 'Start' and/or 'Due' date. Since the subtasks are not recurring, the completed tasks will appear at the bottom of the tasks in the branch making them intuitively easy to identify. If they were set to recurring, they would follow the sort order which could be confusing since you will have next year's tasks mixed in with this year's tasks and no strike through to identify which ones are done for the year.
It seems clear that this behavior has to do with subtasks inheriting their parents' attributes in some way. But it doesn't seem to completely fit the inheritance concept. I'm fuzzy on this and hoping you can shed some light on it for me.
In addition to the pros, there is a con or two to this method also. But I'd like to try to understand this tree behavior better before explaining that since it's a bit mysterious to me.
My question:
The subtasks don't seem to be "inheriting" their parents' recurrence attributes exactly because they are still only set to 'Once' even though the root parent is set to recurring, but they are inheriting the date increment when the parent is set to completed. Is there a concept that explains this behavior?