Hi - let’s say I’m in my DAILY NOTE. Here, I have the following things written down (example):
Client 1 (first level bullet)
note 1, note 2, note, 3
#followup on note 4
Client 2 (first level bullet)
#followup on this thing that I’m working on
In the example above, I had a first level bullet for Client 1 and Client 2 and sub-bullets for the other text. Now I want to do a search for all instances of a tag (#followup), and filter it to show me ONLY the instances where it sits under Client 1.
If you make the #followup lines task list items and the client names into headings instead of list items, I think the Tasks community plugin that can list tasks that are under particular headings (I could be mistaken, tho).
Another, even more different, option would be to process your daily note each day, extracting each client section to somewhere specific to that client and leaving a link or embed in the daily note. The Note Composer core plugin makes this easier, and the Note Refactor community plugin offers additional related features if wanted.
(Also, I’ve moved this thread from Knowledge Management to Help.)
I actually figured out a really easy solution without much work. Here’s what I’m doing.
Instead of creating first-level bullets for “Client 1” and “Client 2”, I use a header now. So “Client 1” or “Client 2” would be preceded by “#” (or multiple hashtags) to give it the status of a header or sub-header.
Then, I embed a query phrased as such:
section:(#followup "Client 1" -query)
That’s it - I’ll get a result of everything with the tag #followup that sits inside the “Client 1” section. I won’t get any other #followup tags and I won’t get any results about the query itself.
The following code is untested but it shouldn’t be too hard to do using list syntax either.
```dataview
TABLE WITHOUT ID item.text, followUps
FLATTEN file.lists as item
FLATTEN filter(item.children, (c) => contains(c.tags, "#followup")) as followUps
WHERE item.text = "Client 1" AND length(followUps)
```
The trick is to keep the focus on the main element with the client information, and then filter out interesting information from the children of that main element.
Could most likely also be written as LIST query if need be, but I’m a bit safer in the TABLE environment doing untested stuff like this. The idea should be solid, though.