Question: recurrence for dependent tasks

50 views
Skip to first unread message

G-Eric

unread,
Jan 18, 2018, 7:28:54 AM1/18/18
to ToDoList (AbstractSpoon) Support
Hi,

I have an issue with recurrence for dependent tasks - here is the context.
  • I often use independent tasks with recurrence to regenerate a record for tasks with a cycle: it works fine.
  • I often use dependent tasks without recurrence to order the sequence of execution of tasks: it works fine.
Now I have dependent tasks with recurrence, i.e. the sequence is important and the same must happen again later: it does not work fine.
As soon as I mark my first task of the sequence as 'completed':
  • the marked task is adjusting and the start & due dates jump jump to the next occurrence (2018 > 2019): ok as it is done for 2018
  • the dependent tasks are adjusting and their start & due dates jump to the next occurrence (2018 > 2019): not ok as they still need to be done for 2018 prior to be adjusted.
To calculate the 'next recurrence when I complete the task', I tried to use both 'create an new task' and 'reuse the existing task' (my preferred setup - no need to keep evidence or trace).
None of these settings did avoid the problem of "block change".

I attach the 'Introduction.TDL' file where I added 3 tasks (29, 30, 31) with yearly recurrence and dependency (29 > 30 > 31) and currently set to create a new task when completed.
If you click the completion checkbox of task 29, you will notice that:
  • task 29 does jump to 2019: ok
  • both tasks 30 and 31 also jump to 2019 even if not yet completed in 2018: not ok.

What is the obvious thing I miss to make this working fine?
Thanks in advance for any feedback / suggestion.

Have a nice day - Eric

Introduction.tdl

.dan.g.

unread,
Jan 20, 2018, 6:58:08 PM1/20/18
to ToDoList (AbstractSpoon) Support
Hi Eric, and thanks for the helpful report and data.

Unfortunately this is not a scenario I have ever considered so it's just not possible right now.

It combines two of the more complex elements of TDL and I will need to think about it very carefully.

It would be even more helpful if you could express what you believe the correct behaviour would be for your example?

G-Eric

unread,
Jan 30, 2018, 9:43:52 AM1/30/18
to ToDoList (AbstractSpoon) Support
( question not forgotten - thinking about it and testing )

BRXL1

unread,
Mar 30, 2018, 7:15:25 PM3/30/18
to ToDoList (AbstractSpoon) Support
Hi .dan.g. (and G-Erik)

new user here and I'm so happy to have found this application. I think it's fantastic and exactly what I was looking for my purposes (which is simply a team to-do-list for a LAN).

But I encountered the same problem as G-Eric and was looking in the group for an answer.

IMO the correct behaviour should simply be that the dependent tasks aren't automatically completed when the task they're dependent to is completed (since it isn't mandatory that the dependent tasks are already completed). So taking GEric's example:

31 can't be completed before 30 and 30 not before 29 like it is supposed to be.

But 29 should be able to be completed without 30 and 31 (as first step or task before the others), also 30 without 31.

Actually that was the behaviour I expected when I set up the dependencies in my tasklist, couldn't find anything in the documentation about it and wondered what I did wrong.

So it would be great if this could be implemented


 

.dan.g.

unread,
Mar 31, 2018, 3:02:35 AM3/31/18
to ToDoList (AbstractSpoon) Support
Welcome BRXL1.

Can you confirm that your issue relates to recurring tasks because your post doesn't mention that anywhere?

BRXL1

unread,
Mar 31, 2018, 8:44:41 PM3/31/18
to ToDoList (AbstractSpoon) Support
Yes, it was implied and I confirm.

BRXL1

unread,
Mar 31, 2018, 8:44:41 PM3/31/18
to ToDoList (AbstractSpoon) Support
Some additional info that might be relevant:

It happens for recurring tasks like this:

Main task: 

Mail (ID 1)

3 subtasks

1) get  (ID 2)
2) stamp  (ID 3)
3) scan  (ID 4)

All have due dates daily (workdays) with hour dates for the subtasks, too

Dependencies (dependent to):

1 > 4 > 3 > 2

So there should be a special order to complete.

But if you complete ID 2 it happens as mentioned, all tasks are completed and set to the next due date.

HTH

Best

Brix

BRXL1

unread,
Apr 9, 2018, 4:10:09 PM4/9/18
to ToDoList (AbstractSpoon) Support
Out of curiousity, Dan,

could you reproduce that behaviour and is that a bug you want to address?

Best

Brix

.dan.g.

unread,
Apr 23, 2018, 10:27:59 PM4/23/18
to ToDoList (AbstractSpoon) Support
Hi Brix

Unfortunately correcting this issue will require significant changes and so I want to 'sit' with it for a while until the right solution presents itself...

BRXL1

unread,
Apr 24, 2018, 11:47:42 AM4/24/18
to ToDoList (AbstractSpoon) Support
Am Dienstag, 24. April 2018 04:27:59 UTC+2 schrieb .dan.g.:
Unfortunately correcting this issue will require significant changes and so I want to 'sit' with it for a while until the right solution presents itself...

I suspected it could be tricky. But you're on the job and of course I'll wait until you figured it out. (Well, have to, actually :-) )

BRXL1

unread,
May 7, 2018, 11:33:45 AM5/7/18
to abstractspoon-t...@googlegroups.com
I just noticed that this doesn't necessarily stop at dependent tasks only.

For the time being I removed all these kind of dependencies in my task list. But I left the structure with the subtasks.

If I tick the main task (which is more something like a title in my task structure) it'll complete again all subtasks and/or rather pushes them to the next due date (since they're recurring).

So it might be more a thing of your design and architecture in general? 

IMO you have subtasks so you can complete them individually and at different times. So they shouldn't be pushed to a wrong date if they have been already completed and one only wants to close the
main task for the day.

(Was this coherent enough?) Anyway I think you should be able to complete the main task without any repercussions for the (already completed) subtasks, regardless of dependencies.
Reply all
Reply to author
Forward
0 new messages