Multilevel [parent:] Search or Alternative Methods?

❓Help
#1

I’m working with a GTD inspired system in Dynalist. I keep a list of projects, with next actions, plans & notes under each project node. The Next Actions node is tagged with @next and I have a search for [parent:@next] to gather all next actions into a single view. This is all great.

As the system evolves, I’m getting to the point where I need to move a few projects to the old someday/maybe bucket. I was thinking that I’d just tag the someday/maybe node with @someday and then move any such projects under that node and exclude their next actions from the above mentioned search with [-parent:@someday]. I quickly learned though, that the parent: search operator is only good for a single level, which means that my exclusion search does nothing, since the actions are nested a few levels underneath the actual @someday tag. I’m assuming that there is a specific reason for this and a feature request is likely to, at best, provide me with that reason.

So I’m here looking for other ideas for how to get this going. I dislike needing to dig around in under each project node to, for example, add a @someday tag to each @next actions list or to delete the @next tag or other solutions along those lines. That’s a recipe for me not keeping things up to date. I’m hoping that there is some other form of ninja searching that would allow this overall structure to work still or at least something with similar maintenance requirements.

Thoughts, ideas? Any input is appreciated.

-Jon

#2

There is a simpler way.

  1. Tag all tasks with a task tag
  2. Set the task that must be done before the next task as a child of the “blocked” task
  3. Search to only see the very next actions with “task -has:child”. Remember to choose flat search to only see next actions not the hierarchy

For instance:

Project X

  • Task A
    – Task A1
    —Task A1A
    -Task B
    – Task B1

A search for “task -has:child” flat search will return this result:

Task A1A
Task B1

#3

Hmm, also maybe the ‘ancestor’ search term would work for you?

image

#4

Stephen, ‘ancestor:’ does indeed work for me. I changed my search to [ancestor:@next -ancestor:@someday] and got exactly what I want.
I’m not clear if I fully understand why though. Is this just an artifact of how Dynalist returns the search results? I’d like to understand this better, for future searches and to make sure I’m not creating something that is going to stop working suddenly with a future seemingly unrelated update.

Below, is roughly my hierarchy. Let me see if I can parse this out for myself, please correct if I’m getting something wrong here.

[ancestor:@next] search is returning: Project1 AND Project2, since each has a nested node (ancestor) that contains the @next tag.

[ancestor:@next -ancestor:@someday] then excludes Project2 because…the top level node (Someday/Maybe @someday) has @someday in it? This is the part that doesn’t equate for me. Is [ancestor:] inclusive of a parent node PLUS all of its ancestors?

-Projects
–Project1
—next actions @next
----[] action1
-Someday/Maybe @someday
–Project2
—next actions @next
----[] action1

#5

Jonathan, I think the ancestor tag is what you’re looking for. You should be able to exclude the next actions you don’t want by using [-ancestor:@someday].

My method is to move completed/canceled projects to a separate document so they don’t clutter up my active workspace.

1 Like
#6

Hi Jonathan, yes parent only looks one level above, ancestor looks at any level above i.e. parent / grandparent / great-grandparent etc

I think your search is not technically returning Project 1 / project 2 - it’s returning action1 (within Project 1) and action1 (within Project 2). Both of these have an @next parent, neither have an @someday parent but the second one has an @someday ancestor (a great grandparent in this case)

So parent:@next -ancestor:@someday might be the most precise search for what you want

1 Like
#7

Stephen…thank you!
Your slow explanation finally made me realize that I need to review my elementary school vocabulary. I was reversing ancestor and descendant in my head. So I was thinking that [ancestor:] would be searching “down” from a given node within its children.
This all makes much more sense now. Thanks again for the patient explanations.

2 Likes
#8

Haha I ran a quick internet search to confirm my definition of ancestor before writing that explanation for the exact same reason :grinning: