lp:~bertrand-rousseau/gtg/get_due_date
- Get this branch:
- bzr branch lp:~bertrand-rousseau/gtg/get_due_date
Branch merges
- Izidor Matušov: Approve (code, running)
-
Diff: 309 lines (+69/-54)4 files modifiedCHANGELOG (+1/-0)
GTG/core/task.py (+44/-18)
GTG/gtk/browser/taskbrowser.glade (+24/-24)
GTG/gtk/editor/editor.py (+0/-12)
Related source package recipes
Branch information
Recent revisions
- 1200. By Bertrand Rousseau
-
Merge trunk, and fix the self-description in about dialog which was shortened for som reason.
- 1198. By Bertrand Rousseau
-
After giving it (even) more thoughts, I think it's better to set the due
date to the most urgent parents due date when clearing it (instead of
setting it to undefine as I did in the previous version of this patch).Indeed, it reinforces the rule imposing that "task due date < parents
due dates" at all times. Since this the GTG policy, it's probably better
to insist on it (it requires to discover or learn the policy, but it
reduces the confusion once it is learned - a better doc would certainly
help here btw).Moreover, in order to provide a better feedback on the fact that there
is a "default value" for a task due date depending on related task due
dates, I changed a "set due date" context menu label from "clear due
date" to "reset to default", since it could let one think that this
would actually unset the due date instead of setting it to its current
most constrained value (according to the due date policy).All that being said, I think this actually corresponds to the previous
behavior, so this should not be a big deal... - 1197. By Bertrand Rousseau
-
Remove the implicit interpretation of due date through get_due_date:
With this patch, GTG uses the actual value of the task object's due date
when accessing it through get_due_date.It seems to me that it's saner than the current mechanism that relies
on an on-the-fly interpretation when accessing the due date. Indeed,
this can hide mismatches between the stored value and the returned due
date.Typical example: a parent task with due date A and a child task
with no due date: the child has no due date set, but get_due_date
will return 'A'.Now, you get what you really have stored, but therefore it's up to the
code to make sure you store a correct value!Therefore, from now on all code dealing with tasks due dates and
tasks relations MUST be written so that the due dates are always set
correctly (=they respect the date constraints). This is actually not
a big deal since most of this is actually cared for by set_due_date().set_due_date() has thus been slightly modified (pursuing previous
work by Nimit Shah), so that when you set/update the due date, all
related tasks dates are modified to respect the constraints.However, D&D'ing tasks can still create situations where a parent task due
date and its child due date are not compatible. This cannot be fixed
now since D&D is done in liblarch and there are no hooks available
from the GTG code to handle tasks updates when reparenting them...This patch also means that from now on, undefined due date are presented
explicitely in the list as not being set, even when constrained by a
parent. Therefore, it's up to the user to explicitely define it if needed
(which she/he can do by directly setting the due date of the task, or by
setting the due date of the parent). It's possibly more work for her/him,
but at least the outcome is clear and therefore predictable/usable: explicit
is always better than implicit.Note: some code from the task editor that checks if the start and due
date are compatible has been removed, since it's done in set_due_date
now. - 1196. By Bertrand Rousseau
-
Fix for bug #826916: When planing through right-click menu, time constraints are not applied, by Nimit Shah
Branch metadata
- Branch format:
- Branch format 7
- Repository format:
- Bazaar repository format 2a (needs bzr 1.16 or later)
- Stacked on:
- lp:~gtg/gtg/old-trunk
