Actual get_due_date implementation causes side effects

[Bertrand Rousseau]

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.

[Bertrand Rousseau (bertrand-rousseau)]

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.

[Lionel Dricot (ploum-deactivatedaccount)]

I think that this bug report merge three different issues:

1. Technical. If a child task has no due date and you add a parent with a due date then remove the parent, the child should continue to have no due date (even if it had a due date when it had a parent). I think GTG got it right but, else, it's a bug that should be fixed.

2. UX. It's not possible to know if a due date is inherited or not, hence leading to frustration when trying to change a due date which is, in fact, inherited. Some UI work is needed.

3. Conceptual. Here again, I think that GTG got it right and the reporter has it wrong. There's no way you could possibly change the due date of a child to something later than its parent.

[Bertrand Rousseau (bertrand-rousseau)]

The central point here is 2. With this behavior, GTG's UI (in particular, the task editor) must reflect that tasks have undefined due dates even when they have a parent with a due date (else, you get a confusion). At the time this bug was reported, when opening a task, the task editor due date entry of a child task with an inherited due date was automatically populated with the inherited due date. This caused a side effect: when closing the editor, the task due date was then saved with the inherited due date! So, basically, the due date wasn't left as undefined and you didn't get the "undefined due date means you get the most constrining due date" behavior anymore. (btw, this is actually the situation I'm describing in this bug report).

Now, since this merge (https://code.launchpad.net/~bertrand-rousseau/gtg/get_due_date/+merge/109534), this behavior is not a side effect anymore: the due date are now explicitely set to respect all due date conditions. In some ways, it's still the 'wrong' behavior (you cannot get an undefined due date when you have a parent), but at least it's not an accidental side effect anymore and it presents a consistent behavior to the users.

However, as you mentioned it, we should maybe rather adopt another behavior, and arrange the UI (and GTG's internals) so that users can decide to leave some task due dates as "undefined" and let GTG automatically determine the due date. However, the UI and the business logic must be made consistent then. The business logic part is probably not a strong issue. Regarding the UI, rather than displaying the constrained due date in the due date entry (=the original behavior), we could maybe leave it blank (optionally, we could display the constraining due date next to it, as a comment).

Regarding 3, I think you should elaborate a little. I don't follow you on this one.

[Izidor Matušov (izidor)]

Okay, what do we want to do about this issue? I am surprise about the lengthy discussion under "Invalid" bug.

[Bertrand Rousseau (bertrand-rousseau)]

This one can be considered as closed, it's actually been fixed. The discussion started here should now happen on this one instead: https://bugs.launchpad.net/gtg/+bug/1038662