Get parents of currently selected item
1 Attachment(s)
I am trying to use the nested search to get all immediate parents of the currently selected item.
The hierarchy is: test1 parent1 parent2test2 parent1 parent2parent1 child1 child2parent2 child3 child4The first saved search is "limit search to selected...." with "parent count" greater than 1. The next search is Item is "parent of" the search above without the "limit search to selected...." selected. Now click on Parent1 and this search. This returns all items which have linked items. Is there a way I can get the search to return only test1 and test2 ? Sample of the above is attached. As an aside from this, 2 enhancements which would be very useful are a) getting the current item id and b) allowing direct SQL queries which return one or more itemIds |
ctrl+6 :)
|
yes I am aware of the Item Parents pane but if I get the results in the child pane I can see all the other columns and sort accordingly. It's more about organizing the data from where it is to where it should be.
|
As a side-note to this - and I've said this before, elsewhere -, it should be possible to have a "natural / main parent", and several "adoptive / secondary parents" for such multi-parented items - whilst currently, once you've assigned a second parent to an item, they're undistinguishable, i.e. later on, you cannot "say" which one was the original, and which are just secondary parents.
This distinction becomes highly interesting whenever you want to print or export a tree / subtree, and do NOT want to have clones (or complete clones) there: By option, the printed / exported / [EDIT:] DISPLAYED!!! subtree would be constructed: - incl. any clones, incl. their content - ditto, but just the title (not also the content), with a little hint, e.g. "Title [cloned from xyz(=name of main parent)]" - all clones omitted, i.e. any item that is cloned, i.e. has two or more parents, only shows up under its MAIN parent (meaning, if it's its "natural" sub-tree, any item (even if cloned elsewhere) shows up, but not in its "secondary" sub-trees, i.e. where the same item is just listed "also"). I don't have to say that this distinction between the "original" of an item and its possible "clones" (the "original" NOT being a "clone" in this sense) does resolve any problem any "multi-dimensional" IMS like UR, TheBrain or whatever otherwise might encounter when "flattening out" its information stock for printing or exporting - TheBrain people even falsely "explain" their export problems by this 3-dimensionality, not seeing this easy way out (I had seen - and implemented - 15 years ago in my own IMS then). It also goes without saying that when you introduce the distinction between "original" (= child of the "original" parent) and "clones" (= the same item, but as child of another parent), you should be able to set up ANY of the secondary parents of the item as the main parent, i.e. there should be a function that allows for easy switching of the main parent of any cloned item, e.g. by right-click menu within the "parents" pane. Finally, if a program like UR introduces a function that does this switching group-wise, semi-automatically, you'll come near multiple tree views, that high-brow subject that has been treated here years ago, and that's as difficult to implement as it is fascinating as a subject for discussion. (So there will always be room for improvement, every prayer answered giving birth to even more insolent ones.) |
All times are GMT -5. The time now is 06:14 PM. |
Copyright © 1999-2023 Kinook Software, Inc.