Update: added “parent:” search operator. Cheers!
3 Likes
Brilliant feature, Erica. Any plans to allow the user to use the search operator for more than one level of parent/child?
We’re thinking of either using an option to enable using the “parent:” operator for all levels of parents, or adding another operator (e.g. “ancestor:”) to explicitly do that.
Because searching in more levels will give more results, I’m not sure that everyone wants that.
3 Likes
Glad to hear you’re thinking about expanding this! I suggest going with the “ancestor” keyword, because they are separate use cases. For example, I use parent:Waiting to easily find the items immediately under “Waiting” nodes. On the other hand I think I would would use -ancestor:#comment to exclude entire sections of the document, e.g. for printing.
Yes I think I’d want these separate as well - having only ‘ancestor’ would remove some uses of the current ‘parent’ search (by polluting it with irrelevant results) which would be a shame
Edit: Would be lovely to have both though 
But surely the amount of results in this type of search will be far less than the amount of results in a search without any qualifier?
And if we take the problem from another perspective :
Searching in the search.
I mean : you do your first search. Then in the search results, you can narrow your research with another research… and then again :
search this…
then this…
then this…
…
1 Like
no need to type # please
inherit the tag
and the tagged list becomes a bookmark
Example:
I have a list of jobs
Each job requires materials
Materials come from different sources
I would like to have a list item in each job list called “#materials”
ie job1/#materials
under #materials I would like to have another tag called
#amazon
so now I find
job1/#materials/amazon/item1, item2, etc
combined with
job2/#materials/amazon/item3, item4, etc
and when i get to amazon I can just go to one location and see the combined lists =four items
but when i am at the job I can drop requisitions into the silo in each job
they are aggregated when needed
=>you know, like a database
so the children inherit the tag in the list
because i cant be typing #whatever each time in the list
I just list them under /#materials/#amazon
and the tagged list becomes a bookmark
right now you would have to type #tag at each item
if you put #amazon and then make a list, it shows naked and then is in a search result screen with limited operators
and some materials could be sourced from different suppliers
so you would drop them in #materials and then sort later ie
ebay, amazon whatever
but job materials aggregate under one inheritable tag bookmark
Hi Paul,
I’m not sure I fully understand your use case, but it sounds like one where the parent and ancestor operators might help. If this were your document:
…then you could find all the amazon items by searching parent:#amazon:
…and you could find all materials by searching for ancestor:#materials:
…is this something like what you’re trying to do?
1 Like