Tasks as First-Class Object

[sheeley]

I've been taking a look at the different open PRs/discussions relating to tasks, and would love to contribute to their support. The things I've caught, in order of important (to me) are:

• Document tasks and their fields (like pages), provide more complete examples
• Filter tasks based on completion status
• Potential: inherit fields from pages and ancestor tasks, reducing the need to filter both pages and tasks
• Support filtering based on due and completion dates like Obsidian Tasks
• Sort tasks by priority like #p:0 to #p:5 or similar
• Task editor
• Repeating tasks

Query Example

This query is nonsense, but provides an example of all the functionality I'm thinking about in one spot.

task from #tag AND -#not-tag
where not complete
or completed < 2021-02-04
or due > 2021-08-09
and text contains "@person"
sort #p desc, cday desc

Data Examples

* [ ] Normal task, tags inherited from page
* [ ] Task with a #tag, adds to inherited page tags
  * [ ] Task that inherits #tag and page tags
* [x] Completed task ✅ 2021-08-05
* [ ] Scheduled task 📅 2021-08-05
* [ ] Task that overrides creation date of file ➕2021-08-05
* [ ] Repeating task 🔁Mondays
* [ ] #tell @person some important thing #p:0

I have a few specific use cases that I've been thinking about, and I think the above (and existing filtering) should take care of the most broad cases.

• Triage - new tasks that have no tags or due dates
• What's next - due today or all uncategorized tasks, sorted by priority and creation
• What's coming soon - filter by due date
• What's been finished in a certain period - filter by completion date
• What tasks exist for a particular context like @person
• What's the overall status of #project?

Next Steps

I'll be checking out the codebase and trying to ensure I understand what's already available today and what the path to working with Obsidian data is. I'm ignorant, so any guidance would be terrific.

Additionally, I'd love to hear feedback about the general approach. I've tried to follow similar patterns to Obsidian Tasks so data is transferable, and I'd like to ensure that the query language matches with your existing patterns.

[sheeley]

Draft documentation changes here: https://github.com/blacksmithgu/obsidian-dataview/compare/master...sheeley:task-draft?expand=1

[blacksmithgu]

I agree with this vision for tasks in general; the final query language will likely look a little different to fit with dataview-isms (we'll need to add common inline operators like contains / in / not, though this is achievable). Default support for priorities, tags, and links all seem good - I would perhaps offer a possible extension in that you can add arbitrary metadata to your task via a simple syntax:

- [ ] This is a thing #tag #tag2 meta1:yes meta2:no

The actual syntax of this "inline metadata" is up for debate; it may be easiest to prefix it with a glyph like $meta1:value or something similar.

[sheeley]

Terrific! I'd been thinking that a dynamic configuration would be sensible, as well. If Obsidian Tasks didn't use emoji, I'd likely have defaulted to some text.

Would you consider that metadata:task to be like frontmatter:file? Unstructured but available for querying?

Have thoughts on how I could modify the examples to fit with your vision of dataview's patterns?

[blacksmithgu]

I actually think we can make your example work exactly (#p might need to just be priority, though we can figure that out later).

[blacksmithgu]

And yes, the metadata:value entries would effectively show up the same way that YAML frontmatter shows up in queries. So you could write queries like

TASKS FROM #tag WHERE custom-field = 19

Or something.

[blacksmithgu]

Improving the task index to hold all this metadata should be a straightforward task, so I would start with that (see how this is all done currently in src/data/file.ts). The harder part is improving TASK queries, though it is achievable with modest changes to src/query/engine.ts.

[sheeley]

Here's how I handled explicit values: sheeley@dba57ff

I'd expect to modify this to look for \W(\w+):(\w+)\Wor similar, to handle the generalized case I believe you're suggesting above. Does that fit with your thinking?

I haven't fully grokked the code in engine, yet. I'll play around with it later this week.

[blacksmithgu]

That implementation looks perfectly fine to me.

[blacksmithgu]

If you are comfortable with these fields, I would start a PR sooner than later, since this data is useful for people using DataviewJS even if the query language doesn't support them yet.

[m-paul]

I like the spirit of this change but not the implementation. This change forces everyone to use the same paradigm in defining task metadata if they want to use dataview, even if they’d prefer an alternate approach or syntax. It starts with autopopulating metadata properties when a task is checked or unchecked. Next it evolves into support for recurring tasks. Then notifications, projects, etc etc.

I’m not necessarily opposed to dataview being used that way, I just feel a more extensible solution would be to support task, line, or block level metadata and hooks, so that users can use scripts to choose what they want to happen when that task, line, or block metadata changes. That way dataview isn’t in the business of task management, but supporting users who want those options.

An alternative like that could allow for various implementations of tasks. One approach (if someone didn’t want to clutter their pages with what amounts to task configuration data) would be to use a csv to store metadata associated with a task via a block id, and a view that to render that information and let a user iteract with it. Another approach would be to let users define alternate syntax solutions or store recurring information on another page. In any case, it puts the choice and control in the user’s hand instead of making users interact with tasks one particular proscribed way.

[blacksmithgu]

I deliberated how best to respond to this for a while. I do agree with extensibility and giving enough "hook-in" points for users to heavily customize their workflow - things like letting users change markdown parsing, add metadata, or completely change where metadata comes from, and so on. Obsidian has a lot of power users who could do very cool things with it, which I look forward to.

I haven't prioritized this for several reasons:

• Custom user scripts make changing Dataview much harder for me - anything I change which is accessible from a user script could potentially cause a breaking change. I'd like to reach a relatively stable point with the index and API before I freeze them.
• Bugs with user scripts shared with others will likely be posted in the Dataview bug tracker, causing frustration (from me only being able to redirect them to whoever wrote the script) and additional triage overhaed.
• Adding in very generic and powerful hooks limits my design space, particularly for performance - Dataview uses background web workers for markdown parsing which have no access to the Obsidian API or Dataview Index, for example, which are difficult to work with but dramatically improve performance. User scripts would have to be written very particularly and would break if I change things (such as changing how pages are keyed/indexed, and so on).
• The proportion of users who would fully use the functionality is relatively low. To be clear, I really like power users (I am one, and most of my bug reports come from them), but Dataview needs to have strong defaults and a good core feature set for most users.

Having reasonable default features, like the task metadata that @sheeley has implemented, also has pluses:

• I can ensure that features all work together harmoniously, which is very important for UX and general applicability. Tasks are now rendered specially in any view, for example, and will be checkable no matter where you render them in coming updates. Links and inline metadata will also work in task views later on, letting you define custom metadata that way.
• I can keep the default implementation fully up to date and change it when I make changes to the rest of Dataview.
• Users who stick to default features can expect a consistent Dataview experience across vaults, including vaults of other people. Data archiving is also easier - the more customization, the harder it becomes to export all of the metadata to another note taking system. (To be fair, this is not currently very good in Dataview currently since I have not implemented enough for it).

With all of this said, I am making my first steps towards allowing extension by adding custom functions support (which are available in the JS API). I will be looking at custom metadata support later on as well (by allowing you to "post-process" parsed metadata and add new metadata), though it will likely not be enough to performantly support the use cases you suggested.

For dramatic changes, it's also worth noting that you can always just fork Dataview - a few users who wanted features I was slow to implement have done this already.

[blacksmithgu]

On a more short-term note, I am also focusing on documentation, general user experience, and improved indexing capabilities, so I have not put much time to a more powerful extension API.

[DryIce1]

Hello,

I have mused over at #475 about Task Management using Atomic Notes in contrast to Task Lists within notes.

Using Atomic Notes would give the user the freedom to define their own field properties outside of the List-Task metadata constraints being defined above at #391 (comment)

Perhaps different users would want both options!