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!
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.
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:
Currently, we have three limitations in hierarchical views:
- One-to-many relations only;
- Every type can be selected only once (it’s your case I guess);
- Same-type reference can be selected only on the top level.
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
Implemented in the latest release CHANGELOG: March 23 / Many-to-many relations in Lists and Smart Folders, Open Entities in panel from Board & Table View
@ihartrafimovich am I correct in assuming that the current release only addresses the first item? Is there a plan for the other limitations on the list in the near future?
@ihartrafimovich, I went back to an app I was building that ran into issues with this view. The improvements help somewhat, but I ran into an issue trying to visualize something I thought would be supported.
I have a hierarchy of “Seats”, which represents our roles in our organization. This is a methodology leveraged by EOS, which has you define the roles as Seats you have to fill with someone. So, the idea is you could have a single individual filling multiple seats for some time before you hire on more people to divide the Seats up. For example, maybe an employee “Susan” is both our Product Designer under the Product Lead and is the Graphic Designer under Marketing Lead.
In this image, you can see Susan assigned as the Employee in the Visionary seat (role). However, you can’t select the Employee from the Levels configuration.
I can show the one-to-many relationships from Seat, but not the many-to-one relationship to Employees. I assume that the many-to-many work should enable this visualization as well, right? Or, is that what you are referring to below:
Honestly, I never thought about List from this perspective.
It looked like a useless case for me, and I would prefer not to pollute the List setup with options that nobody won’t use. But you have opened my eyes now .
It seems that is not so hard to implement, but I don’t know when I will have a timeframe to come back to the feature.
For now, I can offer two workarounds, which you yourself have probably already guessed:
You can select the Employer field to display on Seat cards, and easily open it in a panel by clicking with a pressed Alt key. Besides that, such pieces of data one day will become editable, so will be a quick option to choose the Employer.
You can convert the relation to many-to-many and manage data consistency manually. Or maybe it can be done with Automations, I’m not sure.
Thanks, just wanted to check before creating a separate request. I just created this: Use Many-to-One Relationships in List View