Comment 3 for bug 1011094

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.