Actual get_due_date implementation causes side effects
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
GTG |
Fix Released
|
Medium
|
Bertrand Rousseau |
Bug Description
There's basically two different informations regarding the due date of a task: its actual due date, as defined in the task, and its constrained due date, as set by its parents hierarchy. Right now, the definition of get_due_date blurs the two. This has a side-effect: if you clear the due date, but the task parents have a due date, when calling get_due_date(), you will get the parent due date. Since this due date is sometimes also used to defined the task due date (notably when setting up the task editor), some manipulations in GTG will cause the task due date to be set although it should left undefined.
For instance, if you do the following:
- undefine a child task due date (if previously defined)
- define its parent due date to B
- open the child task in the editor
What you expect is:
- child task due date is undefined
What you get is:
- child task due date is B
Consequences:
- After that, the child task due date is set to B, where it should be left undefined
This is consistent with the interpretation of due dates in the previous GTG versions, but I think this behavior is wrong in regard to the latest changes in date management policy. Undefined due dates should stay undefined. The interpretation of undefined due dates is a matter of display logic policy and should not be enforced by explicitly defining the due date in the date.
Indeed, an undefined due date is "automically adapted" to its parent due date, whereas a defined date stays the same. The current implementation therefore prevents having automatically adapted dates.
This can only be fixed by identifying the places in the code where we should access the actual due date and the constrained due date, and use a different due date accessor.
Changed in gtg: | |
status: | Fix Committed → Fix Released |
Having thought about this, I think it's not true, or at least it doesn't point out the correct problem. Until I can point it out more clearly I'm closing this bug.