If a parent task is recurring and its subtask's Start and/or Due Dates are null and you mark the parent task completed, then dates are automatically assigned to the Start and/or Due Dates of the subtask.
Is there a rationale for this behavior? Shouldn't the subtask's Start and Due Dates remain null?
Should null subtask dates be set when their recurring parent task is marked completed? Topic is solved
Moderator: abstr
Re: Should null subtask dates be set when their recurring parent task is marked completed?
Can you provide a simple demo tasklist please
Re: Should null subtask dates be set when their recurring parent task is marked completed?
Sure, thank you. I've attached it.
I think the issue here is mostly about the dialog that informs you that the task has subtasks and asks if you want to mark them completed too.
If the parent task is recurring, and the subtask has Start and/or Due dates, it doesn't matter whether you answer that dialog Yes or No. Either way it advances the date(s) of the subtask by the recurrence interval, or if the subtask's dates are null, it sets them to the parent task's date values regardless of whether you answer Yes or No.
So maybe the main issue is that that dialog isn't working as expected if the parent task is recurring. Seems like the expected behavior should be that if the parent task is recurring and you answer No, that the the subtasks should remain unchanged whether they have values or they are null.
=====
The steps to demonstrate with the attached demonstration file are as follows (also found in the comment of the first task):
Should null subtask dates be set when their recurring parent task is marked completed?
Steps to Demonstrate Example
1. Note that Task is recurring and that Subtask's Start and Due Date's are null.
2. Click box to left of Task to set it Completed.
3. Click either Yes or No to the dialog that appears.
3. Note that the Start and Due Date of the Subtask is automatically set when the task is set to Completed.
=====
Re: Should null subtask dates be set when their recurring parent task is marked completed?
Thanks for that Ryan.
FYI, this might take a while because I haven't had to revisit this code since 2017 and it's fairly involved.
>> it doesn't matter whether you answer that dialog Yes or No. Either way it advances the date ...
I think your question actually has multiple parts:
Q1. For recurring tasks that will be be reused (ie. Reset to some initial state) is it even relevant to ask whether subtasks should also be completed - because the subtasks' completion dates will be cleared anyway?
A: Not unless one or more of the subtasks are themselves recurring AND they have 'Create New Task' enabled... But nested recurring subtasks is probably a fairly rare use-case so let's deal with that separately because it becomes very confusing very quickly :)
Q2. When resetting the recurring task's state (clearing the completion date, bumping the start/due dates, etc), how should subtasks be reset (in general) ?
I'll deal with this question next and then hopefully Q3 will answer itself...
Q3. When a subtask of the recurring task has null dates AND is not configured to inherit its parent's dates, what should happen?
FYI, this might take a while because I haven't had to revisit this code since 2017 and it's fairly involved.
>> it doesn't matter whether you answer that dialog Yes or No. Either way it advances the date ...
I think your question actually has multiple parts:
Q1. For recurring tasks that will be be reused (ie. Reset to some initial state) is it even relevant to ask whether subtasks should also be completed - because the subtasks' completion dates will be cleared anyway?
A: Not unless one or more of the subtasks are themselves recurring AND they have 'Create New Task' enabled... But nested recurring subtasks is probably a fairly rare use-case so let's deal with that separately because it becomes very confusing very quickly :)
Q2. When resetting the recurring task's state (clearing the completion date, bumping the start/due dates, etc), how should subtasks be reset (in general) ?
I'll deal with this question next and then hopefully Q3 will answer itself...
Q3. When a subtask of the recurring task has null dates AND is not configured to inherit its parent's dates, what should happen?
Re: Should null subtask dates be set when their recurring parent task is marked completed?
Thanks much for that Dan. I am not ignoring your last comment, but struggling a little to fully wrap my mind around it since some of these concepts are different than what I am used to. Need to give it further thought and maybe break things down a little first to help me understand it if you will bear with me.
For the moment I would like to focus only on non-recurring subtasks that have a parent that is recurring if that's possible and what happens to the subtask's Due Date when the recurring parent is marked completed.
This is a fundamental issue for me, so I want to be sure I understand what's going on. I'm concerned about what happens to subtasks (most particularly to their dates) when parent task(s) are changed in large part because you can't always see the subtasks in a view when you are changing the parent task(s) and it could cause unintended and unwanted changes in subtasks that you are not even aware have been changed. That can be a potentially serious problem as you may be making blind changes to any number of other tasks. So it's important to me to have as much control as possible over what happens to subtasks, or, if that isn't possible to at least fully understand what to expect.
I had already thought about nested recurring subtasks and almost had a seizure going off on that tangent in my mind ... was hoping to leave that on the side for now to avoid complication. Could we do that for now just to take it one step at a time? This is about all my feeble mind can handle in one chunk! 🙂
Focusing on behavior of non-recurring subtasks with a recurring parent task, here is the current subtask [Due Date] behavior I observe.
=====
When a recurring parent task is marked completed:
Case1: If a subtask has no date, its date is set to the same date as the completed parent task.
Case2: If a subtask has a date, its date is advanced by the same interval as the parent task.
=====
Q1. Case2 isn't exactly the same as "inheritance" is it? In Case2, the subtask doesn't inherit the parent task's date, it only inherits its recurrence interval.
OR...
When you use the term "inheritance" is it only something that applies to initially null values?
Q2. Are there any setting options that modify the above behavior/inheritance properties of [Due Date]? I may or may not want to, but I am curious about whether or not such options exist as I believe they do with custom date fields.
=====
Thanks!
For the moment I would like to focus only on non-recurring subtasks that have a parent that is recurring if that's possible and what happens to the subtask's Due Date when the recurring parent is marked completed.
This is a fundamental issue for me, so I want to be sure I understand what's going on. I'm concerned about what happens to subtasks (most particularly to their dates) when parent task(s) are changed in large part because you can't always see the subtasks in a view when you are changing the parent task(s) and it could cause unintended and unwanted changes in subtasks that you are not even aware have been changed. That can be a potentially serious problem as you may be making blind changes to any number of other tasks. So it's important to me to have as much control as possible over what happens to subtasks, or, if that isn't possible to at least fully understand what to expect.
I had already thought about nested recurring subtasks and almost had a seizure going off on that tangent in my mind ... was hoping to leave that on the side for now to avoid complication. Could we do that for now just to take it one step at a time? This is about all my feeble mind can handle in one chunk! 🙂
Focusing on behavior of non-recurring subtasks with a recurring parent task, here is the current subtask [Due Date] behavior I observe.
=====
When a recurring parent task is marked completed:
Case1: If a subtask has no date, its date is set to the same date as the completed parent task.
Case2: If a subtask has a date, its date is advanced by the same interval as the parent task.
=====
Q1. Case2 isn't exactly the same as "inheritance" is it? In Case2, the subtask doesn't inherit the parent task's date, it only inherits its recurrence interval.
OR...
When you use the term "inheritance" is it only something that applies to initially null values?
Q2. Are there any setting options that modify the above behavior/inheritance properties of [Due Date]? I may or may not want to, but I am curious about whether or not such options exist as I believe they do with custom date fields.
=====
Thanks!
Last edited by Ryan on Sat Mar 06, 2021 9:22 pm, edited 1 time in total.
Re: Should null subtask dates be set when their recurring parent task is marked completed?
Throwing the next step into the mix in case I don't already appear befuddled enough! 😲
Still plan to get back to the questions you asked, but need more discussion and understanding to try to make my comments sound something resembling coherent.
Again keeping nested recurring subtasks on the side for now if possible, here is an example of my current issue. Maybe there is a way around this?
Say you have a root level (Level 0) recurring task with a dozen or two subtasks at various levels from the root.
It doesn't take a lot of subtasks before the tree becomes confusing so you want to try to group them for clarity.
Some of the subtasks are related so you create a (Level 1) subtask with no dates as a "folder" with no Start or Due dates just to be used as a parent to the related tasks to organize them as subtasks at Level 2 under the "folder" subtask.
But when you set the completion date of the recurring root Level 0 task, it will assign a date to the "folder" task even though it should have no date.
Other examples of tasks with no Start and Due dates that I sometimes use:
*Tasks that I know will eventually be assigned dates, but I don't know what they are at the time I organize/set up/plan the task tree for that set of tasks.
*Sometimes I want to create additional "subtasks" of a task as a sort of an outline structure to help break down the task and comments into organized pieces. The "subtasks" aren't really tasks but rather part of the same task and just used for organizing and clarity. And I only want the task itself to be dated, not the "subtasks."
But the problem is that all of these tasks with null Start and Due Dates will be assigned dates if I mark the Level 0 parent completed.
I can think of some clumsy workarounds such as setting the dates of the tasks that I don't need dates on to some date in the past so they will never appear on the (future) Calendar for example, but I am hoping for a better way to handle this.
=====
I'm starting to formulate the way I *THINK* I would like this to work.
The more I think about it the more I *think* that these are the changes I would like to see. This is just a rough-in, subject to change if there is a reason to change them.
1. Absolute protection against unintended changes in subtasks.
A dialog warning pops up in *every case* where a parent task is changed in a way that will also change *any* attribute of a subtask (maybe this already happens?).
The dialog warns that you are making a change that could affect one or more subtasks and asks if you want to make changes only to the task, or also want to make changes to the subtasks. If you choose only the task, the subtasks remain completely unchanged (in every case). This way I can decide when and if I want the subtasks to change because in some cases I might and in others not. And I would never have a change made without my knowledge.
2. An option to have everything work the same way it does now (except for the above dialog), but in the case that a subtask has null Start and/or Due and/or Completion Dates, they will remain unchanged regardless of changes to a parent's dates.
Now I'll ask the expert. Is there any reason why I would *not* want these changes? Is there a better solution? Does this conflict with anything or cause a problem I am not aware of? What are the risks if any?
I'm grateful for any additional insight you can offer. Thanks again!
Still plan to get back to the questions you asked, but need more discussion and understanding to try to make my comments sound something resembling coherent.
Again keeping nested recurring subtasks on the side for now if possible, here is an example of my current issue. Maybe there is a way around this?
Say you have a root level (Level 0) recurring task with a dozen or two subtasks at various levels from the root.
It doesn't take a lot of subtasks before the tree becomes confusing so you want to try to group them for clarity.
Some of the subtasks are related so you create a (Level 1) subtask with no dates as a "folder" with no Start or Due dates just to be used as a parent to the related tasks to organize them as subtasks at Level 2 under the "folder" subtask.
But when you set the completion date of the recurring root Level 0 task, it will assign a date to the "folder" task even though it should have no date.
Other examples of tasks with no Start and Due dates that I sometimes use:
*Tasks that I know will eventually be assigned dates, but I don't know what they are at the time I organize/set up/plan the task tree for that set of tasks.
*Sometimes I want to create additional "subtasks" of a task as a sort of an outline structure to help break down the task and comments into organized pieces. The "subtasks" aren't really tasks but rather part of the same task and just used for organizing and clarity. And I only want the task itself to be dated, not the "subtasks."
But the problem is that all of these tasks with null Start and Due Dates will be assigned dates if I mark the Level 0 parent completed.
I can think of some clumsy workarounds such as setting the dates of the tasks that I don't need dates on to some date in the past so they will never appear on the (future) Calendar for example, but I am hoping for a better way to handle this.
=====
I'm starting to formulate the way I *THINK* I would like this to work.
The more I think about it the more I *think* that these are the changes I would like to see. This is just a rough-in, subject to change if there is a reason to change them.
1. Absolute protection against unintended changes in subtasks.
A dialog warning pops up in *every case* where a parent task is changed in a way that will also change *any* attribute of a subtask (maybe this already happens?).
The dialog warns that you are making a change that could affect one or more subtasks and asks if you want to make changes only to the task, or also want to make changes to the subtasks. If you choose only the task, the subtasks remain completely unchanged (in every case). This way I can decide when and if I want the subtasks to change because in some cases I might and in others not. And I would never have a change made without my knowledge.
2. An option to have everything work the same way it does now (except for the above dialog), but in the case that a subtask has null Start and/or Due and/or Completion Dates, they will remain unchanged regardless of changes to a parent's dates.
Now I'll ask the expert. Is there any reason why I would *not* want these changes? Is there a better solution? Does this conflict with anything or cause a problem I am not aware of? What are the risks if any?
I'm grateful for any additional insight you can offer. Thanks again!
Re: Should null subtask dates be set when their recurring parent task is marked completed?
When the dates of a recurring task are recalculated:
1. Its subtasks' completion dates are cleared
2. its subtasks' start and due dates are offset by the same amount as the parent
3. If a subtask does not have dates (aka 'null') it is given dates << I am prepared to change this
ps. In future could you edit your responses down to the essentials please... Just bullet points... Otherwise it's unlikely that I will read it all and something important may therefore get missed.
1. Its subtasks' completion dates are cleared
2. its subtasks' start and due dates are offset by the same amount as the parent
3. If a subtask does not have dates (aka 'null') it is given dates << I am prepared to change this
ps. In future could you edit your responses down to the essentials please... Just bullet points... Otherwise it's unlikely that I will read it all and something important may therefore get missed.