Self-replicating Repeating Tasks

Let’s start with an example:
Accounting needs to be done, checked and submitted for each year, but not necessarily within the year. Currently we are doing the Accounting for 2020-2023 - in the future it would be nice to have a task autogenerated every year for that at the end of the year, i.e. “Accounting COMPANY YEAR” such as “Accounting Vikunja 2024” being generated for example on the 31.12.2024. I think this should be fairly easy if repetition modes could be uncoupled from repetition cycles, such that we have the repetition modes:

  • relative / recur: set next date relative to done date
  • absolute / repeat: next date relative to previous due date
  • replicate: basically repeat but create a new task each time the (due) date is reached regardless of whether it has been checked, maybe with the latest task tracking the next recurrence item like taskwarrior does it

Then the options requested in More repeating intervals could still be configured separately - for example if you want a task to repeat every two weeks on a Tuesday, you have the following options, assuming Day 1 is a Monday and initial due date is Day 2:

  • relative: done on Day 1 it is rescheduled to Day 9, done on Day 2 or later it is rescheduled to Day 16, unless you do it on Day 9 or later in which case it moves to Day 23 and so forth
  • absolute: regardless of when you complete it, next due date is Day 16
  • replicate: on Day 2, regardless of when you complete the initial task, a new task is created with a due date on Day 16, and the replication schedule is removed from the initial task and added to the new one

Similar thing for X day of the month, year etc. all the magic the CalDAV recurrence standard also allows afaik.

When it comes to having the respective year as part of the task title, there might be templating or we will do this specific case in n8n after all, which seems to be the ideal solution for that particular example. Could also be that the “replicate” mode recognizes dates of a particular pattern in the title and shifts them along.

1 Like

I like that way of thinking about it.

Dropping the caldav spec in here as well:

Recurrence is an important part of the data model because it governs
how many resources are expected to exist. This specification models
a recurring calendar component and its recurrence exceptions as a
single resource. In this model, recurrence rules, recurrence dates,
exception rules, and exception dates are all part of the data in a
single calendar object resource. This model avoids problems of
limiting how many recurrence instances to store in the repository,
how to keep recurrence instances in sync with the recurring calendar
component, and how to link recurrence exceptions with the recurring
calendar component. It also results in less data to synchronize
between client and server, and makes it easier to make changes to all
recurrence instances or to a recurrence rule. It makes it easier to
create a recurring calendar component and to delete all recurrence