GothenburgBitFactory / taskwarrior

Taskwarrior - Command line Task Management
https://taskwarrior.org
MIT License
4.35k stars 296 forks source link

[TW-1508] The until, wait and scheduled attributes are not shifted by the recurrence span #1534

Open taskwarrior opened 6 years ago

taskwarrior commented 6 years ago

Tomas Babej on 2015-01-13T10:16:42Z says:

If you create task like:

task add test due:2014-01-12T22:00:00 until:2014-01-12T23:00:00 recur:daily

(today is 2014-01-13)

You will see that the child tasks created for this recurrent task do not have shifted until attribute by the reccurence span:

Name          Value                                     
ID            3
Description   test                                      
Status        Pending
Recurrence    daily                                     
Parent task   f6470fad-4879-4281-a6b9-75664222d80c
Mask Index    1.000000                                  
Entered       2015-01-13 10:59:13 (32 seconds)
Due           2014-01-13 22:00:00                       
Until         2014-01-12 23:00:00
Last modified 2015-01-13 10:59:10 (35 seconds)          
UUID          d4e99ba5-34d9-4d65-a551-5d589be8086b
Urgency       12                                        
                               due     1  *   12 =    12

The same behaviour is present for wait and scheduled attributes.

taskwarrior commented 6 years ago

Migrated metadata:

Created: 2015-01-13T10:16:42Z
Modified: 2016-05-04T12:54:32Z
taskwarrior commented 6 years ago

Tomas Babej on 2015-01-19T18:06:07Z says:

I wrote a hook to workaround this issue. See:

https://github.com/tbabej/taskwarrior-shift-all-recurrence-hook

taskwarrior commented 6 years ago

slaven ʙanovic on 2016-05-04T12:54:32Z says:

This bug has a bigger impact than it seems at first. It actually deletes the template and thus all childs that should be created after the first roundabout.

Verify with the following script: {code} d0=date "+%FT%T" d1=date "+%FT%T" --date "1 min" d2=date "+%FT%T" --date "2 min" echo $d0 $d1 $d2 task add +twdebug new task with desc 1 due:$d1 wait:$d0 until:$d2 recur:5min sleep 3 task all +twdebug sleep 70 task all +twdebug sleep 60 task all +twdebug {code}

{code:title=one line paste-able} $ d0=date "+%FT%T"; d1=date "+%FT%T" --date "1 min"; d2=date "+%FT%T" --date "2 min"; echo $d0 $d1 $d2; task add +twdebug new task with desc 1 due:$d1 wait:$d0 until:$d2 recur:5min ; sleep 3; task all +twdebug; sleep 70; task all +twdebug; sleep 60; task all +twdebug; {code}

This command should yield a recurring task every 5 minutes with a 1-minute wait period. It should also be deleted (until) 1 minute after the due date.

{code} 2016-05-04T14:49:08 2016-05-04T14:50:08 2016-05-04T14:51:08 Created task 49 (recurrence template).

ID St UUID Age Tags R Due Until Description 50 W 8a411675 - [1] R 2016-05-04 1min new task with desc 1 49 R 81433757 3s [1] R 2016-05-04 1min new task with desc 1

2 tasks Creating recurring task instance 'new task with desc 1' There are local changes. Sync required.

ID St UUID Age Tags R Wait Due Until Description 51 W ce1b2968 - [1] R 3min 2016-05-04 47s new task with desc 1 50 P 8a411675 1min [1] R 2016-05-04 47s new task with desc 1 49 R 81433757 1min [1] R 2016-05-04 47s new task with desc 1

3 tasks Un-waiting task 'new task with desc 1' Creating recurring task instance 'new task with desc 1' There are local changes. Sync required.

ID St UUID Age Done Tags R Wait Due Description 51 D ce1b2968 1min - [1] R 2min 2016-05-04 new task with desc 1 50 D 8a411675 2min - [1] R 2016-05-04 new task with desc 1 49 D 81433757 2min - [1] R 2016-05-04 new task with desc 1

3 tasks Task 49 'new task with desc 1' expired and was deleted. Task 50 'new task with desc 1' expired and was deleted. Task 51 'new task with desc 1' expired and was deleted. There are local changes. Sync required. {code}

As you can see from the final task output all tasks have been deleted. Deleting data should have critical impact IMO.

abesto commented 6 years ago

FWIW, the current behavior seems consistent with the documentation at https://taskwarrior.org/docs/recurrence.html:

This task has a due date, a monthly recurrence, and an optional until date coinciding with the end of the lease.

That is, an until: on a recurring task defines the end of the recurrence.

At the same time, I found this issue looking for the same functionality described in OP, and provided as a hook in https://github.com/tbabej/task.shift-recurrence (which I've just set up, don't know if it's working yet).

This means changing the behavior of recur+until would likely break existing workflows. Maybe introducing another field would be best, like until-delta or until-relative or children-until or... all of those are clumsy, no better ideas ATM.

ghost commented 5 years ago

Related: https://github.com/GothenburgBitFactory/taskwarrior/issues/97 ; https://github.com/GothenburgBitFactory/taskwarrior/issues/203 .

kaushikgopal commented 3 years ago

FWIW, the current behavior seems consistent with the documentation at https://taskwarrior.org/docs/recurrence.html:

This task has a due date, a monthly recurrence, and an optional until date coinciding with the end of the lease.

That is, an until: on a recurring task defines the end of the recurrence.

At the same time, I found this issue looking for the same functionality described in OP, and provided as a hook in https://github.com/tbabej/task.shift-recurrence (which I've just set up, don't know if it's working yet).

This means changing the behavior of recur+until would likely break existing workflows. Maybe introducing another field would be best, like until-delta or until-relative or children-until or... all of those are clumsy, no better ideas ATM.

Related: https://github.com/GothenburgBitFactory/taskwarrior/issues/2308

I like the suggestion being made In this issue viz. using “runtil” as the default.

runtil - recur until (basically how until behaves today). The lease expires on this date. until - stands for the proposed change i.e Date applies only to Instances or child tasks

only potential downside is it “changes” existing behavior but one could argue it’s more natural and what folks might expect anyway for until behavior in the context of a recurring task.

mhalano commented 3 years ago

I have some recurrence tasks (like to replace my toothbrush every two months) but I prefer not to see the task until the date. I can't find a generic value to set the wait option. Is this could be related to this bug, or I just don't understand how wait with recurring tasks work?

madduck commented 3 years ago

I have some recurrence tasks (like to replace my toothbrush every two months) but I prefer not to see the task until the date. I can't find a generic value to set the wait option. Is this could be related to this bug, or I just don't understand how wait with recurring tasks work?

Have you tried the hook, as described above?

mhalano commented 3 years ago

@madduck I tried but doesn't work so well. It demands a due date, but I just need the "wait" option. Let me give you an example: every two weeks I have a task to check my credit score. I prefer not to be reminded until the date, but when the date arrives I want to see the task. The problem is: I don't have a timeframe which would demand the "due" option. I can do this in any moment in the future.

tbabej commented 3 years ago

@mhalano This is good feedback for the upcoming recurrence overhaul! For now what I would recommend is setting a due date at some point in the future, perhaps 5 years down the line.

mhalano commented 3 years ago

I used due:someday to solve that for now. Maybe until then we already have a more elegant and integrated solution, Am I right? I still don't like to use the taskpirate to do that. Maybe it's a good solution, I don't know, but I think it's an overhead to automate its installation. Maybe I just should keep all the files inside ~/.task/hooks in my dotfiles git repo or the ~/.task/ backup git repo and move on.

mhalano commented 2 years ago

@tbabej Did we have any news about this question in the new release of Taskwarrior?

MerzDaniel commented 1 year ago

The issue still exists

K-L-R-3 commented 11 months ago

Related: #2308

I like the suggestion being made In this issue viz. using “runtil” as the default.

runtil - recur until (basically how until behaves today). The lease expires on this date. until - stands for the proposed change i.e Date applies only to Instances or child tasks

only potential downside is it “changes” existing behavior but one could argue it’s more natural and what folks might expect anyway for until behavior in the context of a recurring task.

what if the changes were made to function only when a certain value exist in the taskrc. something like "improved-recurrance=1" that way it won't automaticly break legacy functionality but anyone who wanted to use runtil and have until work like it does outside of recurance, can easily do so by setting that value. additionaly someone using the legacy behavior could selectively use the rc overide when they add new tasks and be able to take advantage of the new functionality. (I don't know if that last bit would actually work that way but what a win if it does.)

K-L-R-3 commented 11 months ago

Related: #2308 I like the suggestion being made In this issue viz. using “runtil” as the default. runtil - recur until (basically how until behaves today). The lease expires on this date. until - stands for the proposed change i.e Date applies only to Instances or child tasks only potential downside is it “changes” existing behavior but one could argue it’s more natural and what folks might expect anyway for until behavior in the context of a recurring task.

what if the changes were made to function only when a certain value exist in the taskrc. something like "improved-recurrance=1" that way it won't automaticly break legacy functionality but anyone who wanted to use runtil and have until work like it does outside of recurance, can easily do so by setting that value. additionaly someone using the legacy behavior could selectively use the rc overide when they add new tasks and be able to take advantage of the new functionality. (I don't know if that last bit would actually work that way but what a win if it does.)

Or better yet use "runtil:" to define the end of the recurrence and the word "expires:" to replace until. "expires:" will not affect the parent task and will increment for each new child task and behave the way until behaves on non recurring tasks. "until" can be left alone for legacy useage. There will be no ambiguity for expires. Problem solved. Huzzah!