Suggestion: Recurring tasks need to be their own notes

[same774]

Suggestion:
I think the recurring tasks module should automatically create a new note per instance of the recurring task, on the scheduled date (or after the previous instance). Users would also be able to manually create a note for a future instance of a recurring task if they wanted to link to it, or add notes to it. This would allow them to be handled like any other task and streamline the design of Tasknotes.

Explanation:
My existing TaskNotes workflow involves a dynamic query of tasks in my daily note, giving me an immediate and complete to do list for the day. When recurring tasks do not have specific associated notes they may not be pulled into queries in bases like any other task. To see what I need to do, I need to access two views and often miss things. This makes TaskNotes a far less dynamic tool and prohibits workflows like these.

I think this is a particularly relevant feature to add given the migration to a more streamlined bases-integrated TaskNotes, and it seems the obvious choice for a plugin built on a task-per-note design.

[aubreyz]

I really would not want tasknotes replicating my notes. Some of them are massive, and then there will be huge redundancy of information that will somehow need to be reconciled.

[same774]

I think there’s been a misunderstanding - this feature would not clone any of your notes or the contents of them, merely create a concrete task-note for a recurring task after the last one was completed.

It would merely serve to make a recurring task behave like any other task.

[renatomen]

Hi @same774 ,

Thank you for your suggestion. I understand how creating concrete instances of recurring tasks would benefit workflows like yours.
I'd probably prefer that myself the feature was solidly implemented.

However, as a contributor to some of the features in this plugin, it's challenging to implement them robustly without orders of magnitude more effort.

The happy path is relatively straightforward. But there will be multiple scenarios, e.g. When editing a task
a) Allow users to change the current instance only or apply to future or previous instances?
b) Allow users to replicate not only dates, but the contents (e.g. Agenda template, participants, embedded files, attachments).
c) Consider that 20 instances were created, the first 5 were already completed, instance 12 and 13 have been deleted. When the user edits the date and time of the next instance (Instance 6) moving it from Wed 9 am weekly to Wed 10 am weekly:
c1) If the user wants to update all future instances, how will the plugin know that isntances 12 and 13 should be ignored? Or should instances 12 and 13 be recreated and warn the user about that?
d) What do you do when the user changes the recurring frequency (e.g. future tasks change from weekly to fortnightly)?

There will be many more scenarios, each of which may require dozens of tests.
There will be integration scenarios (displaying the task in the calendar, timezones etc).

The maintenance complexity may grow exponentially, and I don't know whether that extra complexity bring substantial more benefits.

I'm currently on the fence.
There may be hard-and-fast constraints to simplify nuanced scenarios. E.g., when editing recurring tasks, all future instances are deleted and new ones are created. Even in this case, the existing instances might already be referenced by other notes, which would now have broken links in some users' workflows.

So there's a lot to think about....
I don't mean to discourage implementing this request. Just want to consider the costs and risks that could come with the benefits.