Many-to-many relationships should be usable for levels in lists

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. :disappointed_relieved:

1 Like

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.

1 Like

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?

1 Like

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.

1 Like

Indeed, the limitation of many views to only one-to-many relations is a bit frustrating :frowning:

I don’t think that’s so bad — it will just show up more than once in the list …

1 Like

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!
circular refs

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 :sparkling_heart:


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. :grinning: