Paul Beckingham on 2012-07-22T03:53:31Z says:
Now that UDAs are here, it is possible to define a new date, called 'review'. Then an external script could run through all the pending tasks, updating 'review' as it goes. Perhaps it would call (at)task < IDs > edit@.
This issue is a placeholder for a discussion about how this should be done.
UPDATE:
We are closer than we think..
In recent discussions.. mostly between me and me.. and Paul, the whole post-2.x landscape is coming into focus.
A lot of work went into taskwarrior to give it capabilities to do cool stuff,
now it's time to do cool stuff.
I'm going to use the "review process" to illustrate how a number of features-in-development might/can/will be used to review. In the process I hope to illustrate how a few of these future-features will work in concert. There are (positive) usage implications from all angles, good stuff coming down the pipe.
To start with, let's set aside the old term "review script" in favour of the term "review process", this because the action of this-thing-after-that-thing will be easily accomplished with (upcoming?) new internal functions and behaviours, specifically (# ) command separators "++". The "internal pipe" that will allow the construction of complex sequences, including random shell execution calls. The ability to "chain" arbitrary, complex task queries interspersed with arbitrary shell commands (mostly echo and cat) obviates the need for an external review "script" in python or perl or anything else. Layer-after-layer of abstraction, a "review", a complex report, and most other things boil down to a "simple" alias call, like review-week-by-project.
The heavy-lifting of the interactivity will be carried by a combination of task ask (#1079) %variables (#1073) and VIRTUALS, (http://taskwarrior.org/boards/6/topics/2414) which will jump onto centre stage as everybodys favourite way to do everything.
The following stack is worthy of a flow-chart, and I will make one when I can, but with it I will try to indicate the levels of abstraction and the degrees of subtlety available to us, in creating a review. Perhaps amusingly, this description will not include the full GTD-specific ramifications, that's a subsequent layer ;-)
so a typical task review process (and most other complex functions) might consist of
* full set of core attributes
* unlimited User Defined Attributes
* rich set of attribute modifiers (attmods)
* full use of regex logic If AND OR GALORE (available at every (?) following step)
wrapped in
Complex strings of VIRTUALS; vfilters, vconfigs and vmods,
condensing arbitrary-length conditional logic statements and complex modification-sets
into a set of deceptively simple, modal terms like +DUE, +HOME and +READY.
wrapped in
arbitrary-length compound-command strings delimited by "++", allowing any number of
task commands and/or shell-calls (echo and cat, etc) to be issued sequentially,
accumulating the output into a final result.
wrapped in
command aliases that take the hairiest of that, and calls it by
something logical and easy to remember, like *review-goals*
and you have a stack of layers of abstraction limited only by your imagination.
The stack above is by no means the only way these features could be combined, and in every-day use, different features will be combined at different layers, but this is sort of the conceptual stack I would suggest for us to design complex features around.
... in progress