jsolka was the first to mention this pretty major problem...
(Major unless one is never aloud to work with inheritance "ON", or never should have more than the TLIs meeting the source... ;)
There are already mantis issues 213 and 214 :
1- Hierarchy problem : sub-item appears both as a sub-item and at top level when its main parent is not displayed in current grid
2- Hierarchy is not restored properly when the Parent and Grand-children meet the source/filter, but not the Children
Now there's another problem which pretty much invalidates the 2 other ones, maybe. (But let's see what happens when its fixed.)
In any case, when all items meet the source in a grid, Full hierarchy is completely broken and it's pretty challenging to have IQ display items the way the users intend it.
Here are 2 screenshot.
1- Grid Source = "Test"
2- There are no filters of any kind (no apha numeric, no date filter, no sort criteria, or whatever).
3- Save item state is ON
4- Full Hierarchy is ON.
5- All items meet the source
6- hierarchies are deeper than 2 levels.
The first screenshot shows how the items are organized, originally, in the grid. And this is how the user expect to see it also after a refresh.
The second one show what happens after a refresh :
As you can see, it's not exactly what one would expect.
I know I sound like a broken record, but I'd really like to see all these hierarchical bugs fixed once and for all... They are very annoying, to say the least.
Thanks Pierre.
[ EDIT : this problem seems to affect hoisting too -- in many cases, if I refresh a hoisted hierarchy (in full hierarchy mode) and I'll get many different items appearing as TLIs when they shouldn't -- it kind of defeats the purpose of hoisting (and of course, these TLIs that shouldn't be there as they weren't hoisted meet the source...) ]
Comments
[/quote]
Very true; IQ's performance is much improved this way.
[quote]So why do we have Inheritance On for the source field? I believe I had it set because of the experience we've had of Items that disappear from the grid upon promotion. They don't themselves meet the source...so once they're promoted to top level, they're either gone (and gone may mean gone after a refresh, so you don't really know), or Pierre has to do some internal toggling which will never be right. Clean as my present grid looks, there may now be some missing Items that I won't see unless I source (All Items).
[/quote]
I chose to turn inheritance ON for some fields (plus using "Auto assign the following fields (comma separated list)" for certain grids) for other reasons than the one you mention here (although... it is kind of related to what you evoke in the following paragraphs).
See this post where I explain in details why I do that : http://www.sqlnotes.net/drupal5/index.php?q=node/169#comment-560 (or ... complete thread : -- link to nonexistent node ID 169 -- )
For more explanations about the HOW I do that (not all source fields have inheritance turned ON...) : Flags for grid visibility - how to approach this?
Also, just so that we don't get lost here :
We (you, Pierre, others and me) had some rich discussions about these issues in the past :
--> Grid Source EditBox (see the comments)
--> Discussion about IQ's treatment of item field(s) auto-assignation in relation to the grids' sources
remember ? :)
I had other informal but long discussions with Pierre about making that process more transparent and have all "data auto-assignments" more explicit (when IQ make the TLI meet the source automatically, when an item is created in a grid, or when a child is promoted) . E.g. : in the grid management dialog "System auto assigned fields" should be specified in some way, so that there's no mystery happening in the background.
I don't know if he plans to make any changes based on these discussions and your suggestions.
Pierre ?
[quote]If that's indeed the dilemma, I think I can propose a fix. Pierre could code to protect the top level. Under this setting, all the dragging and arrowing we do to move Items around would never take them above Level 2 of the grid they were in. Thus they'd never disappear from the grid by transitional promotion. Yet they wouldn't meet the source, so they wouldn't proliferate at top level.
Additionally, we might create a field that is an auxiliary source. All items that appear in a grid with source X would have aux-X toggled On. We'd then have a grid available where those seemingly disappeared items show up, and we could keep it visible if needed. It would show parentless items with source aux-X that were inadvertently promoted out of the X hierarchy.
[/quote]
I've also discussed a similar solution (but not exactly the same) with Pierre a while ago -- about a field that is an "auxiliary source", so to speak.
1- an easy way to keep track of where (in which grid) an item has been displayed (even if not currently displayed), at any point in time. Users could then decide to remove these traces as needed (e.g. : an item which was accidentally displayed in the contact list, could have the contact list auxiliary source field manually deleted)
2- a no brainer way to display all items currently displayed (even potentially) in a grid as a "flat" list (something that's not currently possible without turning inheritance ON for the source field)
(Other possibilities are directly linked to these 2 "actions"...)
I have to go now for a few minutes, but will follow the discussion later.