I have [Product] *------* [Feature]. (Features belong to products, but some features span multiple products; e.g. “2FA” is a feature of both the backend CMS and of the mobile app).
There is also a [Product] ----* [Bug]. (A product can have bugs.)
When I create a list, I can add Bug as a second level, but not Feature. Why not?
Hi, Jean!
The paradox is that an entity can have two parents in such situations.
And it’s like with many to many - a lot of questions rendering. By the way, we can formulate the limitations of our hierarchies as follows: there is only one parent for an entity. This also explains why only the top type can be self-nested.
Some cases are also limited by our lack of polymorphic relations, as far as I can see your child Entity can have only one parent at the same time, but there is a possibility for another one as well, so we treat it like it has (can) two parents at the same time.
We understand that such cases were pretty common, but we just don’t have a good solution in mind. 
This is exactly the kind of problem that I have with Fibery’s views. It isn’t just the list view, but also smart folders, and boards. Fibery can create many to many relationships, but there aren’t very effective ways to visualize it or manage it. This is not a limitation in most other apps.
That is one way to look at it. You can also look at it having two relationships. Fibery seems to have this very strict hierarchical model it wants the users to follow, when in reality things aren’t quite that simple. There are ways to work around this, but it requires a lot of thought and more unique entities.
For example, @jean1 would need to redefine the relationship so that a feature only has one product, then create two features, 2FA associated with CMS and 2FA associated with Mobile App. So, now you have two features named the same thing, but will show up in different places and aren’t really linked together. So, when you search or reference 2FA you end up with both showing up and not knowing which is which. A solution to this is to use a formula to produce the name that says, if you have a product associated with a feature, then add it to the name “2FA (CMS)” and “2FA (Mobile App)”.
I work on a product that has a set of common features across multiple “channels” or “platforms,” and at the moment there isn’t a really good solution I’ve found to managing this problem that doesn’t require a bunch of manual work and complexity.
I don’t understand why there must be the limitation that lower-levels of a hierarchical list cannot also be recursive/hierarchical, when the entities adhere to a strict tree structure:
Here is a my hierarchical list:
The “Page” type is self-referential with a strict parent-child relationship (1:many):
I don’t understand why, in this situation, where Pages are always organized in a strict tree, the Page entities cannot be displayed as a hierarchy. You simply need to start with all the pages that have no parent.
It would be extremely useful! Otherwise I see no way to automatically generate a hierarchical list of a Project’s Pages, for every Project.
Is it (or will it be) possible to duplicate and customize a Hierarchical List view via an Automation action?
I don’t see any support for Views in the API.
If we will have the ability to customize entity views/dashboards, then this may not be important. Otherwise it is.
Can an Action button (e.g. in an Entity view) open a specific View?
In your example, a Page could be a child of a Project and a child of another Page. It seems that Fibery can’t cope with an entity appearing in two different places in the same list view. Who knows the underlying technical reason why :-/
Many cases, including my data, should never have that occur, because I want to model a strict tree structure. But it still could occur, as Fibery does nothing to enforce such relationship constraints.
Perhaps an option for relations, to enforce a strict tree structure, could make it feasible?
As you propose, this is a constraint that would need to be set up at the Type definition. And thus would be enforced when someone try to add a child that is already in the parent hierachy, thus preventing cycles.
The View has nothing to do with that, Views cannot enforce the model constraints. So they should display anything: tree, graph.
I have lots of cases where withe many to many, for example Employees and Companies. If I select a List View with Companies as the first level, then Employee as the second level, it is normal to have the same Employee entities appearing under multiple Companies.
I don’t see where is the problem, nor where is the technical complexity (since List View is showing a fixed number of level, and is not doing a recursive traversal of the hierarchy)
Same for self-referential links, it does not change the complexity.
Indeed, the limitation of many views to only one-to-many relations is a bit frustrating 
I don’t think that’s so bad — it will just show up more than once in the list …
Interestingly, I was just playing around with a hierarchical list (using a one-to-many self-relation) and although circular relations are allowed (X is parent to Y and Y is parent to X) the involved entities disappear completely from the list!
Hi all!
Glad to say that we have some ideas of how to fix that issue in the hierarchical lists (Lists can support many-to-many relations)
Currently, the developer is pretty busy, but the item was added to the backlog 
That is fantastic news!
Allowing an entity to be listed under two or more parents would allow a lot more flexibility in the list view.
A useful UI affordance would then be to highlight or colour all other visible instances of the selected entity. 
Implementation started
This is very exciting 
@mdubakov I had two questions:
Will this apply to all hierarchical structures (i.e. both hierarchical lists and smart folders)?
Is there a chance that as part of the implementation, the more complex nested relations would also be addressed? By this I mean something like:
Or the following example:
There was a discussion with @Chr1sG around this as part of this thread which I think might be helpful in illustrating what is desired and some ideas on how it might be possible.
Hi, there!
Currently, we have three limitations in hierarchical views:
Such limitations are based on a simple desire to avoid the case when the same entity is presented on the tree several times.
Now I’m working on allowing to choose many-to-many relations as the most requested feature for these hierarchical views. As a result, we will be able to handle representing the same entity in the tree several times.
And if everything will be fine with the new approach, we would consider removing the other two limitations with a small effort
I think the cases I am presenting are actually one-to-many relations but they involve nesting of entities that have multiple parent types.
This is not exactly true. In my case, an entity can have parents of different types but those are one-to-many relations.
For example a person works for a company but can also be part of a department within than company. When I create a hierarchy of organization → organizational unit (department) → contact, Fibery gets confused on where to position the contact: under the organization or the department.
I described a possible solution in this post, basically suggesting to work from the deepest level of the hierarchy upwards to find the first “parent” for the entity.
Now when many-to-many relations are involved, I think the above process could simply be ignored so that the same entity appears multiple times in the hierarchy.
I think the approach that I am suggesting above will also address the same-type reference issues at deeper levels of the hierarchy as well. Those situations are generally one-to-many relations between the child and parent nodes.
Apologies if this still doesn’t make sense. It is a rather interesting and challenging issue. If it helps, I can try and describe it to you in a short screen capture or a short zoom call.
The problem I see in your solution is Fibery allows hundreds of configurations and the heuristic (I mean, find the first “parent” for the entity), that will work for your case may break someone else solution, so we are trying to avoid any implicit behavior in the system. That’s why we did Context Filters configurable, for example.
In addition, it’s always hard to explain such behavior to the users.
Addressing your case, I would allow choosing Contact type twice, as a child of Organisation and as a child of Org Unit. After that, you may apply the Filter that hides Organisation children Contacts if their Org Unit is selected. The only issue I see is you need to maintain data consistency manually, a Contact may have selected an Org Unit that doesn’t correspond selected Organisation.
I understand what you mean and I have to admit that I haven’t thought about too many other situations than those I’ve listed before. So I accept that there might be a case in which this approach is not desirable. However, I don’t really know how we can solve the “same-type reference” problem at lower levels of the hierarchy (i.e. beyond the top level) without a similar approach (i.e. finding a parent within the same type first before nesting the elements without parents inside the higher level nodes).
I also think that there are still situations where designers want to present an entity (with one-to-many relations) only once in the tree structure. I think this is where my proposed solution would again work quite well and consistently and would be customizable based on how the levels of the hierarchy are setup. So I would ask that you consider making it available as an option/switch or setting that can be triggered by those who would benefit from it.
I am not sure how this is going to be setup but if there is a way to achieve this, I think that solve my problem.
That is very true. I am hoping that this issue might be solved when/if we have Dependent Dropdown Fields as well as Loopback Relation, so that we can maintain consistency. At the moment I use automations to auto-populate the organization when an org unit is chosen.
I really appreciate you thinking about this and listening and responding to our feedback. This has been a long-standing item for me so I eagerly look forward to seeing the solution