Iterative tasks proof of concept#729
Conversation
|
|
||
| Second, the next due date and wait are calculated from the RRule. For fixed or fixed+ styles, this is a single RRule library call. For chained, it requires updating the RRULEs DTSTART before calling. | ||
|
|
||
| Yes, this is basically an inversion of the current recurring system, where a hidden “parent” task spawns new pending tasks. The advantage is that since the spawned tasks are completed, it’s not possible to end up with multiple pending tasks that are all copies of each other. In case of a sync issue, there may be multiple copies of completed tasks, but that is far less important. Iterative tasks also require less special handling, as there is no need to hide a parent task most of the time and then still have a way to find it when the user wants to edit or delete it. |
There was a problem hiding this comment.
This is really clever!
I don't see how sync issues would create multiple copies? I can see that if I mark a task as Completed in two replicas before they have sync'd with each other, I'll get two copies -- is that what you mean?
There was a problem hiding this comment.
Thanks! And yes, thats exactly what I mean. I also haven't fully worked out the implications for the original iterative task and how due dates will be affected in that situation, but think that the general sync mechanisms should take care of it.
|
|
||
| First, pre-3.0 based applications are completely left out as all iterative functionality is implemented in TaskChampion. | ||
|
|
||
| Second, all applications that haven’t been updated to recognize the Iterative status may hide or mishandle Iterative tasks. The biggest issue is likely to be marking an Iterative task done and then losing it as an iterative task. If that happens, it will disappear from that client's perspective and the iteration never advances. There are a few possible mitigations, such as a secondary UDA flag that legacy clients wouldn't set, but this might just need to be documented as a possible issue during a transition phase. This is the largest risk in the proposal. |
There was a problem hiding this comment.
We could do a major update to Taskwarrior, with instructions to not create iterative tasks until all replicas are updated to that major version.
djmitche
left a comment
djmitche
left a comment
There was a problem hiding this comment.
I'm excited about this! I read the doc but haven't looked at the source yet, and left a few comments. I'll be glad to see more people looking at this!
The primary change is that Iterative tasks now update their dependencies and dependents upon completion.
|
After a few days of using this for my personal tasks, I found a few rough edges and have fixed them. |
3 participants
This is a proof of concept of iterative tasks, or recurrence v2. In the pr is a document describing the general approach and design.
Going this route would allow TaskWarrior a way to address many of the reported issues with recurring tasks, either in the PR or in future work.
It definitely has not been sufficiently tested in the real world yet and there are some missing features, but I wanted to start a conversation before moving forward any more on this.
The basics of creating and iterating iterative tasks is in this PR. Still missing are: