InfoQube IM - Community

Submitted by reesd on 2011/03/08 22:29

I originally put this in items, parents, hierarchy, full hierarchy, context parents, but decided it may be simpler to have it stand alone.

It seems that "Context Parents" only shows the first parent. Is there anyway to show the entire ancestor tree? That is how Ecco worked (see attachment image) and using a more recent example that is what Bonsai supports as well.

Using my original example of
testA
testA1
testA11

If testA11 passes the filter, then I want to see
testA
testA1
testA11

Instead all I see is
testA1
testA11

d

Comments

[quote=reesd]It seems that "Context Parents" only shows the first parent. Is there anyway to show the entire ancestor tree? That is how Ecco worked (see attachment image) and using a more recent example that is what Bonsai supports as well.
[/quote]

(I think this may have been requested in mantis - but I cannot find it there. It may even be planned..**)

the only way currently is using the properties pane >Item info >Parents

it will show the main parent of the selected item and you can expand it to work your way up the hierarchy.

The only problem is that if you move from one item to another (in the grid) it automatically collapses to only show the immediate parent (maybe this could be improved, Pierre?)

** a forum search gave these:

[quote=Pierre_Admin]

It is also planned to have the choice of how deep to show context parents

[/quote]

Context [grand] parent

[quote=Pierre_Admin]

It's already in Mantis, issue 013, and it is coming...

[/quote]

view full hierarchy

[quote=Tom][...]

the only way currently is using the properties pane >Item info >Parents

it will show the main parent of the selected item and you can expand it to work your way up the hierarchy.

The only problem is that if you move from one item to another (in the grid) it automatically collapses to only show the immediate parent (maybe this could be improved, Pierre?)

[/quote] Hi Tom, the hierarchy in the properties pane actually used to stay expanded, but it tremendously affected performance (especially with big hierarchies and multiple parents). The found solution was to leave it collapsed and expand it only when necessary. So I guess that the better and "cheaper" (less resources) solution is probably to implement the same functionality as ~~main parents~~ multi-level context parents in the grid.

[quote=Tom]

[quote=Pierre_Admin]

It's already in Mantis, issue 013, and it is coming...

view full hierarchy

[/quote]

Thanks for the links Tom! I did search, but apparently used the wrong keywords (full/ancestors vs deep, grandparent). Unfortunately that last one is from a year ago and it has no estimated fix version in Mantis. Sigh. Like Vianney says in issue 013, I have been forced to use hierarchy equations.

Hopefully "Ecco did it" helps give it some wings :), I find it an essential component of filtering outlines. Really, I don't think we have outline filtering without it. We just have list filtering with parents. Guess I'm stuck in Bonsai a little longer...

[quote=reesd]

[quote=Pierre_Admin]

It's already in Mantis, issue 013, and it is coming...

view full hierarchy

[/quote]

I knew it was there somewhere and found it with the 'grandfater'

Well you're making a good argument for it ! -
you could also add a note to the mantis issue to bring it to the top of the list (I'm not sure if that's PC, or if it even helps, but I have been known to do it myself EDIT/ see you've done that already

)

[quote=Tom]you could also add a note to the mantis issue to bring it to the top of the list (I'm not sure if that's PC, or if it even helps, but I have been known to do it myself EDIT/ see you've done that already

)

[/quote]

I like to think of it as bringing it up to date, but the bump is a very nice side effect :).

Now what we need is voting in Mantis. I wonder if we could do it just based on trackers (which is kind of how Google Code does it).

Could we get this added to the 0.9.26 roadmap? For me its on the short list of what is keeping me from really using IQ full time....

No, v0.9.26 is solely for the Calendar. Hopefully, v0.9.27 will follow shortly afterwards

[quote=Pierre_Admin]

No, v0.9.26 is solely for the Calendar. Hopefully, v0.9.27 will follow shortly afterwards

[/quote]

I'll be glad when you are done with calendar so you can get back to the "good" stuff (good being what I care about :).

John

[quote=Pierre_Admin]

No, v0.9.26 is solely for the Calendar. Hopefully, v0.9.27 will follow shortly afterwards

[/quote]

Ok, we are in 0.9.27, can this make it in, maybe as part of the grid work you are already doing? It really ruins the value of outline filtering not having it.

Thanks,

dave

Dave, I believe we are still in 9.25 - not 9.27

[quote=jan_rifkinson]

Dave, I believe we are still in 9.25 - not 9.27

[/quote]

Oops, you think I would realize that after 26 different 0.9.25 releases :). Thanks.

Ok, how about we put this in 0.9.25 before we get to 0.9.26 and the calendar focus :).

PS, While I am on the subject, my $.02 is I still that calendar would be better done as tight integration with Thunderbird and Outlook than writing a calendar into IQ.

[quote=Tom]

[quote=reesd]

[quote=Pierre_Admin]

It's already in Mantis, issue 013, and it is coming...

view full hierarchy

[/quote]

I knew it was there somewhere and found it with the 'grandfater'

Well you're making a good argument for it ! -

[/quote]

Just for the record I spent the day getting Bonsai --> InfoQube import working and then getting recurrence working using Armando excellent technique. I was very excited to start managing my ToDos in InfoQube when I realized (again) that InfoQube doesn't show all the ancestors for an item. Sigh. Really IQ doesn't do outline filtering, it does list filterting with first parent grouping.

My workaround so far is to create create a second column for every column I want to filter on. For example I have a PriInt and a PriIntH. I write a row equation for PriIntH that sets it from PriInt. Then I write a column equation that that sets PriIntH's parents to Min. Then I do all my filtering with PriIntH. I do that for every field I care about. Sigh again.

From another thread (Search grid)

[quote=Pierre_Admin]

Four (4) IQ features make implementing multi-level context parents more tricky:

Multiple parents (Ecco supports 1 single parent).
Item persistence. In IQ, all items are created equal and erasing a parent does not automatically mean the children will also be erased.
Ecco also has the concept of a TLI. TLI and sub-items are handled different. TLI don't really exist in IQ.
Recursion. In IQ, you can freely assign an item as a sub-item to any other item (except to itself). So ItemA->ItemB>ItemA is allowed

[/quote]

[quote=Pierre_Admin]

Four (4) IQ features make implementing multi-level context parents more tricky:

Multiple parents (Ecco supports 1 single parent).
Item persistence. In IQ, all items are created equal and erasing a parent does not automatically mean the children will also be erased.
Ecco also has the concept of a TLI. TLI and sub-items are handled different. TLI don't really exist in IQ.
Recursion. In IQ, you can freely assign an item as a sub-item to any other item (except to itself). So ItemA->ItemB>ItemA is allowed

[/quote]

Yes, but most of these apply for a single parent also don't they? So is the problem the performance of figuring them out for a deper hierarchy? Can we agree to certain limitations on these features in trade for seeing multiple parents?

[quote=Pierre_Admin]

Four (4) IQ features make implementing multi-level context parents more tricky:

[/quote]

You have to solve all these problems with the parents are in the grid and hierarchy is on. So I am missing why its harder problem when using "context parents". Why can't you just add all the parents then use the standard hierarchy logic?

A few additional thoughts on each feature/issue...

Multiple parents (Ecco supports 1 single parent).

Yes, but it also has the idea of a main parent (which all the majority of users use) . So just follow that.

Item persistence. In IQ, all items are created equal and erasing a parent does not automatically mean the children will also be erased.

That's fine, they become orphaned, just like are when the parents are in the grid.

Ecco also has the concept of a TLI. TLI and sub-items are handled different. TLI don't really exist in IQ.

I'm missing why this is a problem.

Recursion. In IQ, you can freely assign an item as a sub-item to any other item (except to itself). So ItemA->ItemB>ItemA is allowed

This is a problem when the parents are in the current grid also, so how do you solve it then?