#1374 Tasks should not inherit due date of parents (see discussion below)
THE PROBLEM:
Subtask doesn't inherit due date if added as a subtask by dragging.
Actually it simply keeps the due date settings it comes with.
HOW I FOUND IT:
1. If I create an independent new task (I tried this by clicking the "New Task" button in particular) and DON'T SET DUE DATE and then set it as a subtask to another task THAT HAS DUE DATE by dragging, the task (the first) remains without due date. No due date inheritance occurred. 2. If I create an independent new task(clicking "New Task") and SET ITS OWN SPECIFIC DUE DATE, but then set the task as subtask to another by dragging, the first task remains with Its original due date of creation (I know this in particular makes sense, I'm just telling you what makes me think tasks always keep due dates they come with) 3. If I create a subtask to some task (I did this by clicking on the parent task and then "New Subtask") the subtask inherits the parent's due date. So far so good. But, If I move that subtask to another parent by drag/drop, the subtask remains with its old parent's due date.
HOW IT SHOULD BE:
Tasks shouldn't always preserve the due date settings they come with when they are added as a subtask to some task but ONLY SOMETIMES. In detail:
Case 1: State of task before dragging: DOESN'T HAVE DUE DATE; Suggested outcome after dropping on another task: Task is set as subtask and INHERITS DUE DATE, unless manually changed Case 2: State of task before dragging: HAS INHERITED DUE DATE (from another parent task) Suggested outcome after dropping on another task: Task is set as subtask and INHERITS DUE DATE, unless manually changed Case 3: State of task before dragging: HAS NON-INHERITED DUE DATE Suggested outcome after dropping on another task: Task is set as subtask and PRESERVES DUE DATE, unless manually changed
It is probably important for case 3 that manual change of due date (via the task edit box) supports the option for the task to inherit due date from parent task by providing users with some sort of checkbox. I know that technically we can just type the date, but if we did the computer will see that as a non-inherited due date and if we wish to move the task to another parent the outcome of case 3 will happen i.e. task will preserve due date when it should not.
If a checkbox for inheritance is employed, it should just be left checked by default for case 1 and case 2 and unchecked for case 3. That should solve the problem.
Sorry if I sound like a robot or a know-it-all, I'm just trying to be helpful :-}
Hi Sabrina, I appreciate your thoughts, but I think your answer isn't quite right.
What we've already done is a much better system: instead of inheriting dates at all, there is a sort of effective-date. What happens is: if you put a task with a due date within a parent that has a later or no due date, it forces the parent to show as though it had the subtask's due date, but it doesn't actually have it marked. This mechanism preserves the distinction between a marked due date and a due-date that relates a subtask to the parent task. When the parent task is collapsed, the due date is marked as being the subtask's due date, but it is marked with parentheses to show that it isn't the actual marked due date of the parent itself.
The solution to what you are asking is to make this same thing work in reverse!
Here's what we should do:
no tasks should ever inherit fully the dates from other tasks simply by being dragged. Instead, only dates actually marked for any task, sub or parent, should be marked; and then they should be maintained.
but when a task without a marked due date is dragged into a parent task that has a due date, it should work like it currently does for the reverse situation. In other words, the subtask should be treated as though it had the due date from the parent, and we could potentially mark this in the column view by showing the parent's due date but in parentheses for the subtask.
Now, I'm not sure if this is the very best way to do it, but we should definitely stop the permanent inheriting of dates when they are dropped. My feeling is that nothing ever other than the user choosing to set a date should actually change any date. The rest of the details involve how to effectively sort and mark related tasks given their connected dates; but doing this should not involve actually marking a date change.
I hope that's clear. Feel free to add your thoughts. And hopefully Jerome and Frank, you understand what I mean and we can work out how to fix this the best way.
Cheers,
Aaron
Last edit: Aaron Wolf 2013-02-13
First, thank you for the extremely fast response :)
I think I understand what you are proposing but just to make sure:
If tasks have a marked (manually entered) due date then they should
travel with it everywhere, unless again manually changed. This marked
due date also serves as their "effective" due date i.e. used in
sorting.
If tasks don't have marked due date they will have their
"effective" due date settings set to the MARKED due date settings of
the parent task (So if there is no parent task, or if there is a
parent task with an effective due date (because of a child), but blank
marked due date, the subtasks will not inherit any kind of due date.)
2.1. If tasks without marked due date have an effective date
(because of a parent), the effective date will be displayed in the due
date column in parentheses.
Did I understand you correctly? If yes then I think this is a much
better solution then mine to my original "problem" but...i'm also
starting to think there is no problem at all :D Because really when i
think about it - why would tasks need to inherit due date? (even just
effective.) Sorting will remain unaffected - tasks will just go to the
bottom of the parent task, just like they would without due date,
unless some parallel tasks have their due date set to later than that
of the parent (which seems unreasonable). So why exactly are you in
favor of due date inheritance (even of just effective due date)?
Also, right now subtasks inherit MARKED due date if they are created
as subtasks from scratch (by clicking on parent and then "new
subtask"). I think you should disable this. Will you? If not why not?
Thanks again for your attention,
Sabrina
2013/2/13 Aaron Wolf wolftune@users.sf.net:
Related
Bugs: #1374
Sabrina, you seem to understand now. Indeed we need to fix the situation where new subtasks inherit dates. There should never be hard inheriting of dates, period. But soft effective inheritance of dates could still make sense in this direction, such as viewing the tasks in list mode instead of tree mode. However, whether that makes sense is totally debatable. At a minimum, everything will work if we just stop the hard inheriting.
Cheers