Apply (default) properties to all tasks in a file via YAML frontmatter

[gffhcks]

⚠️ Please check that this feature request hasn't been suggested before.

• I searched previous Ideas in Discussions didn't find any similar feature requests.
• I searched previous Issues didn't find any similar feature requests.
• I am only requesting a single feature. Multiple changes should be split into individual requests, with links between them.
• I believe my requested feature will be generally applicable to other users, not just me: it is not uniquely tied to my personal workflow.

🔖 Feature description

I want to be able to set 'default' values for task properties, for all tasks within a specific file.

Say I'm planning a party. I have a hard due date (the party itself) for all of the tasks, but most of the individual tasks don't have specific timeline requirements. I'd like to set the due date for them in one place, and be able to change it in one place if needed.

Or maybe I have a file full of recurring daily tasks. Instead of setting them to delete on completion individually, I could just set it for the entire file.

YAML frontmatter seems ideal for this.

✔️ Solution

I imagine it working something like this:

1. If a task property is defined in the YAML frontmatter, queries treat it as the default value for that property, for any task in the file.
2. An explicit value set on the task itself overrides the file's default.

❓ Alternatives

A 'bulk edit' feature would be a decent alternative - i.e., select a group of tasks, and apply a property to all of them at once. This is a slightly different use case, though - and honestly, I'd prefer to see both features implemented.

📝 Additional Context

No response

[claremacrae]

I do think this is a good idea, and in fact I thought it had been suggested already, but cannot find it.

@gffhcks Please help us out by making this more specific.

For example, please record what you would suggest the frontmatter properties should be called, for each property you would want to be handled, to start the planning going.

[gffhcks]

With the obvious caveat that I have no idea how the code is structured, or whether this would be harder for some properties: I would think that essentially every property (except maybe description or ID) could be exposed for a default. They could inherit their names from the advanced query syntax.

Maybe something like this - I assume you'd want the keys to be in a unique namespace to avoid collision with other plugins.

---
obsidian-tasks:
    defaults:
        created:
        start:
        scheduled:
        priority:
        depends_on:
        created:
        recurs:
        on_completion:
        ...    # and so on. I'm still pretty new to Obsidian and haven't actually found an exhaustive list.
---

Honestly I can think of a legitimate use case for basically any task property.

Hopefully that helps - if not I'm happy to discuss the idea further.

[claremacrae]

Thank you...

Ah, that's interesting - Obsidian does not support nested properties:
https://help.obsidian.md/Editing+and+formatting/Properties#Not+supported

Which means people would not be able to use the handy File Properties editor to change properties. Which would be a shame.

So probably we should use non-nested names that were meaningful and did not conflict with obvious existing uses. So simple things like created are perhaps out of the question, as people may use them for the creation date of the markdown files themselves.

The Breadcrumbs plugin uses these names:

Excalidraw uses:

[claremacrae]

I assume you'd want the keys to be in a unique namespace to avoid collision with other plugins

Yes, that is a good point.

[gffhcks]

Ah, that's interesting - Obsidian does not support nested properties: https://help.obsidian.md/Editing+and+formatting/Properties#Not+supported

Which means people would not be able to use the handy File Properties editor to change properties. Which would be a shame.

So probably we should use non-nested names that were meaningful and did not conflict with obvious existing uses. So simple things like created are perhaps out of the question, as people may use them for the creation date of the markdown files themselves.

Wow... Not displaying nested data for a nested data format isn't a limitation I expected... Very good call out though, it's better to support the built-in editor.

[claremacrae]

Thank you.

I also thought we might want to enable override of some settings on a per-file basis. There may even be a feature request for it.

So perhaps this leans us towards something of this sort - format not checked:

tasks-settings-add-done-date: false
tasks-default-due-date: 2024-09-30

[gffhcks]

That makes sense to me.

Actually, another related enhancement - not sure if it'd be in scope for this change, or if it'd be a separate request - but you could have configuration like this applied at the folder level as well.

You could define a specific config file name for folders, maybe a dotfile - .tasksconfig.md or something. It would behave like this:

• Any supported yaml config in .tasksconfig.md is treated as if it was applied to all files in the same folder.
• Any explicit yaml within a note file takes precedence over the contents of .tasksconfig.md.

Then if I want to have one set of default behaviors for my Personal GTD focus, and another for my Work GTD focus, I can easily do that.

[claremacrae]

That makes sense to me.

Actually, another related enhancement - not sure if it'd be in scope for this change, or if it'd be a separate request - but you could have configuration like this applied at the folder level as well.

It's a nice idea, but as you suggest, a long, long way away from this PR.

Let's first see when and if this one gets implemented.