How to achieve "Filtered View" with search

[Spliff]

UR users want Filtered Views, there has been a discussion on this in 2007, and another one in 2017. You suggest using Search, results ordered by Tree Order column, and then, in case, also displaying Indent Level and Lineage columns.

I now have found these again, in "Options" - "Attributes" - "System Attributes to display" - in fact, almost every attribute in the Related Panes Dialogue is superfluous for most people, so I don't really understand why, for the, much more important, System attributes, I have a choice to hide them, when I always have to scroll thru the non-system attributes anyway, but so my problem is resolved. Can't edit the title for adding a question mark though. ;-)

(P.S.: The jumping-around within the tree has NOT been resolved in any way, in the recent August update, whilst you mention it within the "Done" list though; in fact, I could not see any amelioration, in any situation - would have loved to say otherwise!)

[Spliff]

Unfortunately, "Tree order" does NOT show the search results in tree order.

I have a tree with thousands of items, the hierarchy of it not being very deep. Then, I search for a search term which occurs quite often, but not too often, let's say some dozens of times; I have got the columns Tree Order and Item Title, and I sort by Tree Order, the indicator symbol there "going up".

Then, I get many results "-1", then many results "0", many results "1", and so on, even some results "30", and it's just the very last results in the list which only show a non-repeated number, up to "159"... whilst there are thousands of items within the tree.

Then, I check the real tree position of the results, one-by-one, for some of them, and it becomes obvious that the result list is NOT in tree order, even for non-equal numbers, i.e. many "lower" numbers (which, as said, come first in the list) are references to items much later in the tree.

Hence:

1) I don't understand what this "Tree Order" does, after all; could you explain why I see what I see (and have described above)?

2) My problem, that I need to "filter the tree", i.e. must get "search results" in tree order, is not resolved, with "Tree Order" alone at least; how would I do it then?


(EDIT: To specify this further: You said once, "The Lineage column will show the tree hierarchy. This [= There, supposedly] is also an Indent Level attribute that can be displayed." - I don't need the hierarchy, nor the indent level, but I need the the results in the order they should appear when the routine "reads" the tree from start to finish, following the depths;

without having checked this in real, the weird numbers I get in the example above seem to indicate that your routine, by "Tree Order", might (?) follow the tree on indentation level 1 from top to bottom, then on indentation level 2 from top to bottom, and so on? But anyway, my tree is quite flat, I nowhere have items beyond indentation level 5, or, perhaps in very rare cases, 6, whilst getting much higher numbers than that. I can't explain how those numbers are "calculated" then.

You also said once, "It isn't possible to filter the tree in that way, but you can show and sort on the Hierarchy and Tree Order system attributes / columns in search results to display the hierarchy there.", but there isn't a "Hierarchy" attribute/column it seems.

And another thought: Might I have encountered a bug in "Tree Order" sorting since there are too many items to search in and/or too many results; would the order possibly be correct if the record set was just several hundreds of items, and some 2 dozens of search results?)

[PureMoxie]

The Tree Order column indicates an item's position in the tree relative to its immediate siblings (items with the same parent), not the overall tree.

[Spliff]

Thank you, PureMoxie, that's interesting news (albeit I don't know then what the -1 and 0 values would mean), and it easily explains why I get, for a very big tree, many very low values here, and values like "1408" and the like just once! ;-)

What I'm looking for, obviously, is a sort according to the inherent "line numbering" you'd get if, in the tree, you'd do "Expand All". (This is a more explicit description than the identical, "Follow the hierarchy in depth, then only navigate to the next sibling", or whatever experts might call it.)

Hence:

XXXXXXXXXX
Is there no way I could get such a "filtered tree view", even by means of search results?
XXXXXXXXXX

There has been a discussion of this subject in this forum in 2007 (!), and then again, another one, in 2017 (!), and Kyle's answers to such demands seem to indicate

THAT THERE IS A WAY INDEED.

But how?

1) I'm in a relative "need" for this functionality for better search-and-consolidate in very big trees (interminable inboxes and the like), where I could thus identify my search results which are NOT yet in their "right place", i.e. within "their" specific sub-tree; some months ago, I mentioned this problem: There are attributes (Direct) Parent and Original Parent, but there is no attribute "Level-1-Parent", so there is currently no way to identify search results by their belonging (or not) to specific (higher-up) sub-trees, and thus, tree-position (not: position within their immediate siblings range: that one might be an attribute easily available but of limited usefulness I would suggest) could at least identify, after some tries, which ones are the search results before the relevant sub-tree, and which ones are the ones below that; currently, they are all mixed up with those which already are at their "correct" position.

2) And I absolutely NEED this, for just trees with a 3-digit number of items, in order to navigate to items deeper-down in the hierarchy (i.e. not on levels 1 or 2, counting the source item as level 0), and especially for all my EXPORT purposes.*

It is obvious that the respective IDs can't help here, since they just indicate the creation date of the item in question.


And, please, Kyle, could you rename this thread into "How to Realize "Filtered View" by Search"?


*=If this is not possible in the end, my whole work-flow breaks!

(And, obviously, the necessary info for that is "somewhere", possibly gathered on-the-fly, since otherwise, it would not be possible to build up the tree, to begin with.)

[kinook]

Add the Lineage column to your search results (View | Choose Columns or F9), and sort first on Lineage, then on Tree Order (hold down Ctrl key to sort on multiple columns). A negative Tree Order value indicates that the item and its siblings are not manually ordered, and instead are sorted in ascending (-1) or descending (-2) order, via View | Alphabetic or right-click -> Sort Siblings.

https://kinook.com/UltraRecall/Manua...attributes.htm

https://kinook.com/UltraRecall/Manua...tomization.htm

https://kinook.com/UltraRecall/Manual/treemenu.htm

[Spliff]

Thank you so much, Kyle, that does it!

Also, the "Lineage" attribute (in the file system, we would call it "path") is the solution to what I had mentioned: an indication of the respective "top" parent item(s), in order to "position" the search results: this is EXTREMELY HELPFUL (even without the correct tree order, but all the more so, of course, with it) for my problem 1) above.


EDIT: Sorry for bothering you with the "Flag" problem, I was fortunately able to delete the thread within minutes; here again, I fell in the trap of the "Flag" attribute not being "checked" in the "Tools - Options - Attributes" list; I have now checked ALL system attributes in that dialogue, in order to not encounter a similar problem some months in the future (my memory is failing...).

Above, I had mentioned the length of the attributes-list to browse, in order to get to the system attributes, within the Choose Columns dialogue of the Related Items Pane; the real "problem" in there being that the "Collapse All" setting in there is NOT persistent, so that every time, I either have to click on the button (which I systematically miss to do for whatever reason), or then have to scroll the list again...

That's a very minor "problem" remaining though; thank you so much again for your very kind help, Kyle!