filter by YAML tag

[midas0441]

I tend to keep all my files at the root --- it saves me the trouble of making sure files get created in the right folder and having to police whether files are in the right folder.

I use tags: in YAML to categorize files. I guess these tags could be viewed as applying to all content within the file, including TODOs. Is it possible to filter by "file-level tags"? Something like:

tag (includes|does not include) <tag>

This could apply to in-line tag (e.g., #sample-tag) or a YAML-based file-level tag, I suppose.

[schemar]

Hey, thanks for the idea. I haven’t really looked into tags/YAML frontmatter, yet. This is probably not too easy to do with the current code base, as this would mean all tasks need to track all tags from their file 🤔

[Steven-AA]

Need this to exclude tasks in projects with Suspended or Not Started tags. Or is there a better way to do this?

[Steven-AA]

For example, I have a note project A with multiple tasks. I want to exclude all tasks in this note when I add Suspended tag to the note, instead of add tag to every single tasks. Currently I have to move every task under single header add use heading filter,

[claremacrae]

Why do they all have to be under a single heading?

[Steven-AA]

Otherwise I would have to add Suspended tag to every heading in the note

[claremacrae]

Right. I suppose it depends how many headings you have, as to whether that is feasible or not - see my comments below...

Well, it was just a suggestion as a way forward that I thought was probably easier than adding the tag to every single task.

[Steven-AA]

Yes, so it would be wonderful to have a tag filter.

[claremacrae]

Suggestion/workaround

A workaround that involves fewer edits is to search on heading...

I have this kind of thing in my markdown... I chose to use the word "Deferred" in headings to treat all tasks in that section as deferred...

## Home Deferred

- [ ] ..
- [ ] ..

## House Deferred

- [ ] ..
- [ ] ..

Then in my queries, if I want to exclude deferred tasks I have:

```tasks
heading does not include Deferred
```

And to include deferred tasks:

```tasks
heading includes Deferred
```

So if you have whole files with Suspended or Not Started YAML tags, you could add a single highest-level heading at the top of the file that repeats the Tag name, and then you could use heading filters...

This would be quite a lot easier than editing every single task, I feel.

Extra ideas

It also has slightly finer granularity, so if I want to activate some deferred tasks, I only need to move them to a different section in a file, rather than a different file.

Where I have a file with all tasks for a particular topic, I tend to use this kind of heading pattern:

# Tasks - Us - Entertainment

## Entertainment

- [ ] ...

## Entertainment Routine

- [ ] ...


## Entertainment Deferred

- [ ] ...

It means that only the ... Routine section gets cluttered up with completed recurring tasks, and it makes it easier to spot the individual tasks in the first section...

[claremacrae]

I've shared the above in the new task-management channel on Discord:
https://discord.com/channels/686053708261228577/965681451297304596/965889686612606976

[claremacrae]

I came here whilst reviewing #716.

Now that we have the tag|tags search in Tasks, I feel it would be relatively easy for Tag searches to also search any tags in the frontmatter of the file a task is in.

Another example motivation: I use a tag pattern for contexts, like #context/home, #context/town.

Sometimes I have a whole file of tasks, all of which would be done in a particular location, and I currently have to remember to add that tag to every task in that file. It would be very convenient to add the tag to the file instead.

[claremacrae]

I believe this is the same as #318.

[claremacrae]

As a workaround until this is implemented, the following contains the code to do this using Dataview and Tasks combined:
#442 (comment)

[claremacrae]

I appreciate the value of this feature. However, the Tasks code will need quite a lot of refactoring before this feature could be added in a sustainable and maintainable way.

In the meantime, I wrote up a workaround that can be used right now, to find notes tasks in notes with particular tags:
https://github.com/obsidian-tasks-group/obsidian-tasks/blob/main/resources/sample_vaults/Tasks-Demo/How%20To/Find%20tasks%20in%20notes%20with%20particular%20tag.md

[claremacrae]

Another request:

• If a note is tagged, the task is treated as including the tag #1934

[sascha-wi]

I don't see how you really would want to organize your to do bullet points with creating tags for each point separately. So if tasks is not reading the tags of an obsidian note otherwise, I find it really difficult to use this plugin effectively.

[claremacrae]

Hi @sascha-wi,

I don't see how you really would want to organize your to do bullet points with creating tags for each point separately.

Of course, and I'm not going to try and change your mind...

However, lots and lots of people do use this plugin very successfully. And it's why I volunteered to maintain it last year, as I found it so useful.

So if tasks is not reading the tags of an obsidian note otherwise, I find it really difficult to use this plugin effectively.

That's fine. It's a free project. Nobody makes less money if there are fewer users... It's totally your choice.

I just released access to query.file.path and similar this morning, which is another step on the way towards providing access to metadata...

So although I've no idea on when I will be able to release access to YAML, it will happen at some point.

In the meantime, as long as you don't use recurring tasks, I recommend you use the dataview plugin instead.

Good luck.

[claremacrae]

See also:

• File tags filter #2334

[claremacrae]

Another one:

• Filter Tasks by Properties Frontmatter #2480

[c1rdan]

I think this will fit fine in the TaskFile class. We can add a getter and reference it as task.file.properties or task.file.frontmatter. In this way, it can be clearly differenced from the tasks' tags, and it will also allow to refer to all the Obsidian properties of the file, not only the tags.

For implementation, it seems like we should use the Obsidian metadataCache to get the file hash and extract the frontmatter from there. I'm not familiar with the codebase (or Obsidian API really) and I could not find any obvious way to access this data from the TaskFile class.

I considered changing the plugin Cache to a singleton and implementing a getInstance (or get it in some other way) but it feels like I'm missing an obvious, better way of doing it. How would you recommend implementing this?

[approximate]

Hi Clare, since 5.3.0 has been released a month ago, did you have a chance to look at this request?

BTW, thanks very much for maintaining this plugin -- despite what could be seen as "pestering" for this or that feature, many people appreciate all the hard (and unpaid!) work that goes into this project.

[claremacrae]

Hi @approximate, no I didn't. If anyone is willing to actively work on this, writing tests and documentation, the best thing is to send me an email (address is in my profile here) and we can set up a pairing/intro session, and I can show you what I know, and what needs to be done, based on the code at that point in time.

[claremacrae]

And thank you for the very kind words - they mean a lot.

[claremacrae]

To reply to @c1rdan's comments above....

I think this will fit fine in the TaskFile class. We can add a getter and reference it as task.file.properties or task.file.frontmatter. In this way, it can be clearly differenced from the tasks' tags, and it will also allow to refer to all the Obsidian properties of the file, not only the tags.

Yes, I'm sure that's the right approach.

For implementation, it seems like we should use the Obsidian metadataCache to get the file hash and extract the frontmatter from there. I'm not familiar with the codebase (or Obsidian API really) and I could not find any obvious way to access this data from the TaskFile class.

The .zip in my comment below has sample Tasks code blocks that show how to get the frontmatter. But they get the frontmatter each time a task is used in a custom filter, sort or group, which is very inefficient.

I considered changing the plugin Cache to a singleton and implementing a getInstance (or get it in some other way) but it feels like I'm missing an obvious, better way of doing it. How would you recommend implementing this?

I think the changes are going to be something like:

First Pull Request - pure refactoring

1. Change TaskLocation so that it also stores a TasksFile instead of path.

2. Change Task.file so that it returns the TasksFile from the TaskLocation, instead of this:

obsidian-tasks/src/Task/Task.ts

Lines 673 to 675 in 12d4c7d

	public get file(): TasksFile {
	return new TasksFile(this.path);
	}

Second pull request - pure refactoring

Similarly, adjust the code that sets up query.file to also return a stored TasksFile.

This is the code of interest:

obsidian-tasks/src/Scripting/QueryContext.ts

Lines 37 to 45 in b72640f

	export function makeQueryContextWithTasks(path: string, allTasks: Readonly<Task[]>): QueryContext {
	const tasksFile = new TasksFile(path);
	return {
	query: {
	file: tasksFile,
	allTasks: allTasks,
	},
	};
	}

See if you can make it so that the TaskFile is only created once per Query.

Third pull request

1. Create a class in src/Scripting/ that stores a copy of the frontmatter and provides convenient, safe access to its values - perhaps TaskFileProperties?

2. Change the following code so that it constructs the TaskFileProperties once, and then passes it in to new TaskLocation(... later in the same function.

obsidian-tasks/src/Obsidian/Cache.ts

Lines 274 to 282 in 3b18a9d

	private getTasksFromFileContent(
	fileContent: string,
	listItems: ListItemCache[],
	fileCache: CachedMetadata,
	file: TFile,
	): Task[] {
	const tasks: Task[] = [];
	const fileLines = fileContent.split('\n');
	const linesInFile = fileLines.length;

[claremacrae]

Last comment for now... 🤞

I wrote the Contributing Guide with a lot of useful information on how to develop and test the Tasks plugin.

[KonkaBass]

Hello, just adding a nonspecific encouragement to frontmatter reading for Task tags. The 6.0 is great and look forward to when YAML tags can be implemented. Thanks for all the hard work! 🙌🙏

[claremacrae]

Some time ago I did a bunch of experimenting with custom filters and custom groups, accessing values from the frontmatter.

Eventually Tasks should make these values available, but for now, they can be obtained directly from Obsidian.

What I got working was in no way good enough to write up as documentation and recommend to users.

But it was actually quite a useful experiment.

@c1rdan, based on your comment above, perhaps you could see if you add to task.file and query.file with info in the examples...

Here is the Zip of my folder of sample files and queries:
metadata-properties-yaml access.zip

[claremacrae]

On the assumption that nobody has actually started work on this, @ilandikov and I are going to start working together on it... 🎉

I'm mentioning this publicly to avoid duplicated work...

So before anyone asks, no idea when it will be released! 😉

[claremacrae]

On the assumption that nobody has actually started work on this, @ilandikov and I are going to start working together on it... 🎉

Just to mention that soon after we started working on this, some bug pull requests came in that required our attention, so we have put this down for now.

[axel-angel]

In the meantime, I've found a cleaner workaround (starting from #232 (comment)) thanks to filter by function combined with dataview:

```tasks
tag include #obsidian
not done
filter by function this.app.plugins.plugins["dataview"].api.page(task.path).tags.includes('daily')

where #obsidian is the tag found in the task and #daily is a tag found in the frontmatter note tags. As you can see anything dataview (dv) supports can be queried here. Also I wasn't able to access "dv" directly therefore the long line this.app etc.

This is probably not the most efficient since api.page look up the page again but during my testing this seems fine in time being 👌 . Thank you everyone for your hard work on Tasks and adding the great "by function" features.

[erikhe90]

That is helpful, thank you! I needed to make two changes: There was a .file missing and I needed to include the hash in the tag name. For example:

filter by function !this.app.plugins.plugins["dataview"].api.page(task.path).file.tags.includes('#notasks')