Recurring tasks

[Rsose]

Hi Marcusolsson Is it any possible to set up recurring tasks into your plugin? I've been using full calendar before,but it got RECURRING TATSK feature Full Calendar YAML format

title: Example of recurring task allDay: false startTime: 10:00 endTime: 12:00 date: 2022-10-25 type: recurring daysOfWeek: [R,W,T,U,M] startRecur: 2022-10-26

I need some similar feature to see recurring tasks someday in the future!Look at screenshots you may get it what I want 😄 Waiting for a reply Thanks

[marcusolsson]

I can see how this would be useful in a calendar for project management.

Today, the Projects plugin merely renders already existing notes. Calendar events and notes are mapped 1-1. I'm guessing this feature would mean that calendar events could exists without a matching note. Otherwise you'd create infinite notes for recurring events without end time.

I'd like to see this implemented, but since it's a major feature that might require bigger changes, I don't know when I'll get around to it.

[jebeaudoin]

Marcus, just a note to chime in to support the 1:1 mapping. I’m excited about Project because it uses a note as a record, which is intuitive to non-technical users. It has the additional virtue of portability—should Obsidian one day shut down (God forbid). I could see recurring events based on one note in future development, where future events are stored in array, but in general I favor tethering display data to actual notes whenever possible for Kansan and tabular presentation. Suggestions for single-file projects (“Single-file projects #77”) and the like should require a user setting to deviate from the note-as-record default. Just my opinion…

[zedryas]

Hello

Why can't multiple event matches the same note ? I've seen that phylosophically you do not want to have a footprint, but could it be in the meta data of a note to have recuring information contained, and if such be displayed recursively in the calendar ?

[marcusolsson]

The way I see it, there are two parts to this:

• Task definition, i.e. when does recurring tasks start, how often to they recur, and maybe an end date, the template to use for each task.
• Task instance, i.e. the actual task.

The task instance would be a Markdown note, but I'm not sure the definition should be. I think we should consider storing the task definition in the plugin's configuration file to avoid creating new standards for how these notes should look.

Let's assume then that the user have created a task definition, when should the task instance (the note) be created? I'm thinking maybe it gets created once the date for the previous has passed. It could of course be configurable, i.e. "Number of notes to create in advance".

The last aspect is how future notes should appear in the views, since they technically don't exist. We'd need to visually distinguish between the actual notes and the "placeholders". Obviously, if you click to open one of the placeholders, the actual notes gets created.

Also, how many placeholders/ghost notes should appear in the views? Let's say you want a recurring "Daily meeting" task in a Backlog column in the Board view, how many should the plugin display?

If you have any ideas on what would make for a great experience, let me know!

[Acylation]

Awesome! As you described, the information of recursive tasks can be divided into two parts, recurring settings and detailed notes. Based on this nature, we can apply different strategies in different views.

I'm thinking maybe it gets created once the date for the previous one has passed. It could of course be configurable, i.e. "Number of notes to create in advance".

Also, how many placeholders/ghost notes should appear in the views? Let's say you want a recurring "Daily meeting" task in a Backlog column in the Board view, how many should the plugin display?

Reply on this, as a personal preference, I'd like to keep my table view and board view clean, rather than filled with outdated/precreated notes. And that's why single-file recurring task is often asked.

So in my proposal, I would only display the upcoming note of a recursive task, figure out ways to exclude former notes, and only create future notes manually when needed. (More details in Automation section). The 1-1 mapping principle and "leave no trace" philosophy are strictly obeyed.

How to display recursive notes in different views?

Calendar View

We'd need to visually distinguish between the actual notes and the "placeholders".

This is the major concern for Calendar view to support recursive tasks, since ALL the potential tasks, whether the corresponding actual notes exist or not, are expected to be rendered. Now that actual notes are displayed as "links" in Calendar view currently, it's natural to render nonexistent notes as "resolved links", just like what happens when we link a nonexistent file in the obsidian markdown editor.

Since the recurring configs are implied by all the notes rendered in the Calendar, so there is no need to display the recurring config explicitly. I simply modified the style of the CalendarEntry and here's what it looks like.

To distinguish them from nonrecursive notes, some rules/marks can be attached. For example, provide a color rule for recursive/nonrecursive notes.

Board View & Table View

Different from the Calendar view, the Board view & Table view should always only render existing notes, which means only actual notes (outdated ones, an upcoming note & precreated future notes) will be rendered.

To support recursive tasks, we can append interactive labels on board cards, showing that "this is a recursive task", and provide detailed recurring configs when the cursor hovers above. The feature is related to #53. GitHub Projects' label in cards looks good, I took it as a reference when typing this.

As for table view, an icon can be used to indicate a recursive item. Here shows the lucide "refresh-cw", inspired by Microsoft Todo, mentioned below. "Repeat" icon is also recommended.

Settings & Interactions

How to describe a recursive item?

About the setting options and setting modal, Microsoft Todo comes to mind. Notice that the recursive item card owns a "repeat" icon.

To define a recursive setting, we need

• A list of related actual notes
• Start
• End
• Rules
  • a number to describe the period
  • a selection of [days, weeks, months, years]
  • select single/multiple weekdays (use the start day's weekday attribute as default)

Only "repeat every * weeks" have further settings.

Create/Modify recursive settings

Click on the icon in Table view, click on the card in Board view and entry of Calendar will call out the modal for metadata editing. In the modal, a checkbox is used to enable/disable the recursive settings.

However, metadata modal in Table view seems duplicate from directly editing table cells. Since the recursive icons only attach to the recursive notes, I suggest that the table call out the recursive modal directly, though there will be no way to set a recursive in Table view.

In all, the consistency of the UI should be well considered.

Manually create future notes in advance

In Table view and Board view, this action would be realized by a button in the setting modal. While in Calendar view, ctrl/cmd+click is enough.

Automation

Auto create upcoming notes

 I'm thinking maybe it gets created once the date for the previous has passed.

Can't agree more.

New feature: Archive & Auto-Archive

This is introduced to deal with outdated notes, inspired by kanban's archive & GitHub Projects' archive. Create a subfolder called "Archived" and move items into it to stop tracking, or leave them as is, but mark them as archived in the project config. Archived items will not be rendered in Table view and Board view naturally, and in the Calendar view, they can be rendered as resolved links. The feature should be configurable.

New feature: Inherit previous note

This allows upcoming notes to inherit all the contents and most of the metadata from the previous note, as recursive tasks always have similar metadata. This is an alternation to the note template.

More ideas

Manage related notes

What if the recursive setting is modified after some notes are generated in advance? Should the notes stay and go wild, or still be kept in the setting list as a member of the recursive task? What will happen to the data if the wild notes are set to be deleted?

Stacking cards

Another possible way to display multi-notes under the same recursive task in the Board view is stacking the cards. Always display the upcoming task at the front, and stack others. Correspondingly, the click event should be modified. Only call out the item modal when clicking on the link, while expanding/folding the stack when clicking on the blank area of the card. Or, a list-like chevron-controlled expand/fold effect is also acceptable.

This method has no limit to the number of ghost notes. The number of stacked cards in a card set can be declared by users. In the card set, ghost notes are still not rendered as normal cards, but show "click to create" prompts instead.

[zedryas]

The task instance would be a Markdown note, but I'm not sure the definition should be. I think we should consider storing the task definition in the plugin's configuration file to avoid creating new standards for how these notes should look.

Sorry was away for christmas and new eve. The thing for is to think of repeating task not so much as task but as habits. If so the recurring of the task would not have to differ and you would not have task instances but only one.

Maybe introduce a concept of habits that would have only one instance but repeated in time ?

[0xrusowsky]

any expectations to work on recursive tasks soonish? imo it would be a killer feature :)

what as been outlined in https://github.com/marcusolsson/obsidian-projects/issues/69#issuecomment-1367512426 makes a lot of sense to me, and would be a great design!

[HilkopterBob]

this is a great feature! absolutely needed IMO!