Wonkish: Obsidian's Query Control Plug-in

Better than Dataview for project task status

my Query Control settings

Warning: This post is likely only to be of interest to Obsidian users, and even then, only for those who tinker.

---

I have been using the Obsidian Dataview plugin as a means to search for and organize the many tasks associated with projects and subprojects.

For example, I define a project in Obsidian using the dataview inline metadata, like this:

- [!]  [ø:: project]  [øø:: subproject] other text

A data view query to find all the tasks for `project` would look like this, where I search across several folders in my vault for incomplete tasks associated with the ‘reworked’ project, and grouped by subproject:

```dataview 
TASK 
FROM "2022 journal" OR "00 work futures" OR "2021 journal" OR "00 reworked"
WHERE (ø = "reworked") AND (status != "x") AND (status != "X") AND (status != "-")
GROUP BY øø
```

But dataview results are not ‘concrete’. You can click on the results one by one, but the results aren’t fixed and can't be copied.

I presume this will be fixed in future releases of dataview, but it is a headache when I’d like a dataview query to yield something like a dashboard.

Enter the Query Control plugin. The plugin builds on the built-in Obsidian embedded search query, providing exactly what I want. So instead of the dataview query above, I would have to create a ‘reworked search’ file with a series of queries to find various subprojects by name, like this:

## decision-making

```query
line: ("ø:: reworked" "øø:: decision-making" (- "- [x]") (- "- [X]") (- "- [-]"))
```

This query finds all incomplete tasks on the same line as the ‘reworked’ project and ‘decision-making’ subproject metadata. This treats the metadata as text but I don’t really care.¹

The results are displayed like the built-in search, but the plugin provides a number of controls, with values defined in the plugin’s settings:

These controls, from left to right, allow you to expand/collapse results, show more context, change sort settings, hide the ‘title’ (the search query), hide the results, render into markdown, and (highlighted) copy results. This last element is something that the builtin search capability lacks.

Results can be clicked on to open the source files and the line where the task resides. Just as important, a given result can be clicked to show more context around where the line is:

When clicked, that reveals this expanded context for the task:

This makes the query results very manipulable. Hover Editor can also pop edit these results.

When I define a subproject — often during researching a topic for a post or preparing materials for a client engagement — I create a folder for the subproject in the (generally already existing) project folder. And when I get to the point where I want to collate all the active tasks for that subproject I will create a status file with a query of the form above. In this case, this is the folder/file structure:

+ 00 reworked
…
++ decision-making
…
+++ decision-making status

I expect that in general, I will include a section at the bottom of the query control status file that displays completed tasks. That would require a query of this form:

```query
line: ("ø:: reworked" "øø:: decision-making" (("- [x]") OR ("- [X]") OR ("- [-]"))) - "line: ("

```

The string `- “line: (“` blocks the query from returning the query itself.

Conclusions and an Idea

I am likely to adopt query control queries for all my project and subproject status tracking, at least until the point where the dataview system provides the ability to create concrete results that can be manipulated, copied, linked to, or archived.

The last use case is interesting. With query control, I can copy the results of a query, timestamp it, and perhaps place it at the end of the status file. This could be helpful but requires the user to make sense of all the tasks changing statuses, over time.

What would ultimately be most helpful would be a plugin that would manage the microhistory of each task and its changes over time. For example, I indicate a possible task with the status `- [?]`, and I change the status to `- [>]` when I create a file dedicated to the work associated with that task, such as copying some or all of the contents of an article I am reviewing, or a note I am creating as part of a larger essay. Ultimately, the task is completed or canceled. I would like to be able to see the timeline for each task, on demand, perhaps by hovering over the task status, and one of the pop-up options would be a display of the task timeline. Something like this:

To implement this, an underlying plugin would have to be registering state changes in tasks and manage them in a database. In such a case, there could be other ways to expose and leverage such information.

1. I could not use the obvious search option of `task-todo: (…)` because the built-in search capability has not been upgraded to support alternative tasks. So all tasks with any character in the check box, like `- [!]` or `- [?]`, are considered completed tasks. That’s why I have to go to such lengths to enumerate the various variants of completed tasks to filter them out in the `line: (…)` search.