That is precisely what I was thinking. When you create your view, you have to define the levels and the path that makes sense for the view that you are building. You can’t just add the databases and let Fibery to decide the hierarchy.
To be clear I think I am asking for two things:
1) Self-relations at deeper/lower levels of hierarchy
I understand that by doing this you are prioritizing self-relations for determining the parent over the higher level of the hierarchy. But doesn’t Fibery already have a way of disabling this with the red circle. Wouldn’t that guarantee that this behaviour can be disabled if it is not desirable in particular circumstances?
Adding this capability would really enhance things like organizational structures, page structures, project/task breakdowns, etc. .
2) Extend search path for parent node to higher levels of hierarchy
This would be use the “hierarchical path” to search for where to place entities into higher levels of the hierarchy. Fibery already does this with the level immediately above it (e.g. maps Projects to Programs and Programs to Portfolios). But it stops there and places anything that has no immediate parent into the “No Portfolio” / “No Program” section. However, when there are higher levels of hierarchy available, I think it makes sense to continue the search for matches at those levels. As you said this is still limited to realm of one-to-many relations (Projects have maximum one Program and/or one Portfolio).
Again, if this is not desired in all cases, I think adding a switch or setting to prevent it would be the answer (i.e. enforce strict hierarchy).
My comment about the “root items” was simply that in case you have self-referencing items, you only need to do this extended search for items that have no self-parents (i.e. Projects that have no Projects as parents). That should save some time in the process. I think @Matt_Blais was thinking along the same lines:
Many-to-Many Relations
I don’t think there is any way of allowing hierarchical lists to display many-to-many relations without allowing the entities to appear more than once in the view. If there is a technical reason that is not possible, then this will likely never be possible, unless a very complex logic/rule engine is added to decide where to put one and only one instance of the object.
However, if an item can appear more than once, then in the case that @jean1 offered:
the solution seems simple in this case. Depending on how the view hierarchy is setup you would either:
-
Add each Feature to every Product (assumes Product is at level 1 and Feature at level 2)
-
Add each Product to every Feature (assumes Feature is at level 1 and Product at level 2)
Now lets say that you add another database called “Bugs” and establish many-to-many relations like [Product] *------* [Bug] and [Feature] *------* [Bug]. In this case we assume that Products generally can have bugs as well as specific Features. I think this is probably the most complicated you can get with the structure.
I think the search path proposal described above would still be the way to go here. However, instead of stopping when you find the first parent, you keep going up the hierarchy to find other matches.
So if the view is setup like this:
Then again (assuming Bugs, Features and Products are not self-referencing databases), you would start with the list of Bugs and for each Bug, try and find all related Features and add it to all of them. If the switch (added to mockup above) is set, the algorithm continues to higher level of hierarchy and see if the Bug also has any relations to Products and adds them where the relation exists. Once that is done, the we move onto Features. From here the process the same as what we described above (item 1 of the list).
Apologies if this is belaboring the point. But this is one of the features that I really like to see in Fibery and thought I should offer every bit of thinking that I’ve had on it in case there is something here that would help make this happen.