In some apps, I have type A that is a parent to type B, which is in turn a parent to type A. It would be nice if it was possible to represent this in some way (like in whiteboards, smart folders, and/or the newly released hierarchical lists :slight_smile: )

Ah, that makes sense. Thanks! Definitely hope it can change it the future :slight_smile:

I can relate to that also from the PRINCE2 perspective. There is the workaround as used in other SWs and Excel sheets in Excel managed organizations :slight_smile: Using the basic setup of: Portfolio – Programme ---- Project You create an “empty” programme for the cases of projects being directly in the portfolio. You just need to agree on the broadly accepted name of such “empty” programme.

@Polina_Zenevich and @Chr1sG I was wondering if there was any updates on this idea/request. It is one of the things that has been really bugging me. In fairness, I don’t know if any other apps do this (or do this well). However, it seems to that fibery’s relations allow you to setup the nesting relationships within the data model but then that power is not available in the UI/Views (i.e. smart folders and hierarchical views) based on this fundamental design limitation: [image] Polina_Zenevich: 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. While this makes sense, I wonder why this issue can’t be resolved through some rules/process which establishes one parent. For example, I believe the simplest case would be to first start with the current database relation as the primary parent and if no relation is defined to the same database (i.e. relation is null), then we would go up one level and use that relation as the parent relation (if it exists). And so on up the levels until you get to the first level at which point if no relation exists, it gets captured under a “no parent” bucket. I think this would be a logical approach, although there may be edge cases that could benefit from later allowing this rule to be customizable in some way. Example So in this example: [image] where we have three databases where each database can have records of the same type nested under each other (i.e. Portfolios could have Sub-Portfolios and Program could have Sub-Programs and Projects could have Sub-Projects). In addition, you could also have projects be either part of the program or discrete projects under a portfolio: [image] Approach/Process With the approach I suggested above, I believe you start by building each databases’s nested structure first (which is what fibery does for the first level): [image] Then in step 2, you start from highest level and move up and try to map all the root/level 1 items in the lower level databases: [image] So in the above example, after creating the individual nested structure for Portfolio, Program and Project, you then go to the Project tree and for every Project that is at the root of tree (i.e. has no parent Project), you will see if a Program relation is specified. If yes, then we insert/nest the Project (and any associated sub-Projects) inside that Program. If not, you will see if a Portfolio is defined and nest the Project there. If all fails, then the Project would be added to the “No Portfolio” list (again with any nested sub-Projects). After Projects are done, then you move one level up to Programs and do the same process with all the root level Programs. I believe with this approach you will be able to get something like this: [image] This doesn’t assign a one true parent to any entity (I think that would diminish fibery’s flexibility and I don’t see why that would be necessary). However, it allows unlimited visual nesting by using a rule to determine each items parent based on the levels defined in the view. I am sure I am missing important implementation details but would be curious to get fibery teams’ thoughts on if something like this is doable. If it can be accomplished for Smart Folders and Hierarchical Views, I think it would also be a very useful addition to the Whiteboard to allow things like org charts.

You’re suggestion is totally logical, but for your example, there is nothing to stop a Project being linked to a Program and a Portfolio at the same time. So if Project D is linked to Portfolio Alpha (as well as being linked to Program 03 - Year 2) where would it show in the hierarchical list? The obvious answer is under both of them, but at the moment, the underlying tech doesn’t allow an item to appear twice in the same hierarchical list view. So any time that there is recursion at a level other than the top level, or where there are multiple ‘upward looking’ relations, you are prevented from choosing to display those databases (in hierarchical list view or smart folders).

[image] Chr1sG: So if Project D is linked to Portfolio Alpha (as well as being linked to Program 03 - Year 2) where would it show in the hierarchical list? The obvious answer is under both of them I could be wrong, but I think my approach would actually mean that Project D would actually only appear once under “Program 03 - Year 2” and the process would ignore any relations to the Portfolio database. That is because in Step 2, I start from the highest level (level 3 Project) and try to first find their parent in Programs database. If I find a Program where the Project can be nested, then the process stops. In this way we preserve the one object/one parent paradigm by applying a rule/sequence on how the parent is found. If no parent is found all the way to the top-most level (e.g. Portfolio in this case) then the View will just add that entity to the “No Portfolio” list (which is what it does currently. I do see your point that a user might specify conflicting relations (i.e. a Program that is in a different Portfolio). I think you can solve that by using automations and by adding conditionals to the entity view that would allow you to hide fields and/or filter relation fields based on another field (i.e. if you choose a Portfolio, the list of Programs is limited to Programs under that Portfolio). [image] Chr1sG: at the moment, the underlying tech doesn’t allow an item to appear twice in the same hierarchical list view. While my suggestion above guarantees (I hope) an item only would appear once, I hope you are able to actually have the same item appear multiple times in the future as I think it might be useful in some cases (e.g. a person works in two departments/faculties/etc.). When this is a possibility, I think you should be able to control whether items can appear more than once or would be nested per the suggested method.

[image] cannibalflea: filter relation fields based on another field (i.e. if you choose a Portfolio, the list of Programs is limited to Programs under that Portfolio). https://help.fibery.io/en/articles/3310832-hierarchical-relations :slightly_smiling_face: [image] cannibalflea: I hope you are able to actually have the same item appear multiple times in the future as I think it might be useful in some cases I totally agree that this will be a useful addition. [image] cannibalflea: I start from the highest level (level 3 Project) and try to first find their parent in Programs database. I think your logic is fine for the example you showed, but potentially the biggest challenge is that Fibery users (by virtue of the tool’s inherent flexibility) can make some really interesting spaces with relationship networks that would present insoluble problems to any logic. Take something like the Usability Testing template. How should your logic apply in this case? [image] or even worse… [image] Whatever the dev team decide to do, it has to work without any assumptions about how a user might have arranged relations in their spaces.

@Chr1sG I totally agree that whatever solution that is considered, it would have to be evaluated for unforeseen impacts. And I don’t doubt the issues you are raising, however, I am not seeing how the two cases you provided would conflict with the suggested logic. I don’t use these two templates, but I just installed them to see how they are configured. For one, as far as I can see, unlike the example I shared, neither app have any databases that have relations to themselves (i.e. have entities that could have sub-entities of the same type): [nesting_2-01] As you know, as it stands you cannot currently have any self-nesting beyond first level of hierarchical list. This is primarily what I am trying to address with this suggested logic. And if this type of nesting is not desirable in a particular case, I think there is already a switch to turn it off (currently implemented for first level only): [nesting_2-02] The second thing I wanted to achieve was being able to have: Projects that are part of a Program or Independent Projects under a Portfolio (I would have to make sure the Program field for the Project is null) As far as I was able to see, this behaviour doesn’t affect either of the apps you referenced (there were actually no hierarchical lists in those templates but I created some based on the smart folders): Test Management [nesting_2-03] Usability Testing [nesting_2-04] Could you elaborate on how the approach I’ve been suggesting would break those existing apps or constrain hierarchical views in them?

[image] cannibalflea: neither app have any databases that have relations to themselves Sorry, I guess I wasn’t clear :confused: When I presented the two examples, I was just trying to imagine that a user could have developed a space with similar complexity and included self-relation for one or more of the lower levels. In your example, you wrote: [image] cannibalflea: for every Project that is at the root of tree (i.e. has no parent Project), you will see if a Program relation is specified. If yes, then we insert/nest the Project (and any associated sub-Projects) inside that Program. If not, you will see if a Portfolio is defined and nest the Project there. If all fails, then the Project would be added to the “No Portfolio” list This is based on an implicit assumption that Program-as-parent relation takes priority over Portfolio-as-parent relation. When looking at the hierarchy diagram, that is a reasonable deduction. However, taking the Usability Testing as an example (and assuming that Attempt is self-related) I am struggling to see how your logic could work reliably. Based on your ‘rules’: Build each database’s nested structure :heavy_check_mark: Try to map root items :question: If a hierarchical list is to display all databases, I can’t see how Fibery can determine whether an Attempt should be prioritised to be mapped under a Participant or a Task? I guess the answer is that the user is required to choose a single ‘hierarchical path’ (either Test → Participant → Attempt or Test → Task → Attempt) and that resolves it. Maybe that’s OK. But this is a constraint that is acceptable/valid for one-to-many relations. I am aware though that any changes made to support self-relations need to be compatible with (future) support of many-to-many relations: [image] [DONE] Many-to-many relationships should be usable for levels in lists Ideas & Features 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? Implementing specific logic for self-relations might hinder that future development. To be honest, I totally want to see self-relations at lower levels, so I hope the dev team can figure it out without painting themselves into a corner.

FYI, this thread originally started as a discussion about recursion, where relations between databases A → B → A is possible, but not able to be shown in Smart folders or hierarchical lists. It’s turned into a discussion about self-relation, which is fine, but perhaps the topics need splitting?

[image] Chr1sG: If a hierarchical list is to display all databases, I can’t see how Fibery can determine whether an Attempt should be prioritised to be mapped under a Participant or a Task? I guess the answer is that the user is required to choose a single ‘hierarchical path’ (either Test → Participant → Attempt or Test → Task → Attempt) and that resolves it. Maybe that’s OK. 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 [image] Chr1sG: I totally want to see self-relations at lower levels, so I hope the dev team can figure it out without painting themselves into a corner 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: [image][DONE] Many-to-many relationships should be usable for levels in lists You simply need to start with all the pages that have no parent. 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: [image][DONE] 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). 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) [image] Add each Product to every Feature (assumes Feature is at level 1 and Product at level 2) [image] 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: [nesting_2-05] 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.

Representing nested relations

Ideas & Features

mdubakov February 1, 2024, 2:50pm 25

Self-relations in all levels were added in latest release

Topic		Replies	Views
[DONE] Many-to-many relationships should be usable for levels in lists Ideas & Features list-view	24	3585	May 6, 2022
CHANGELOG: February 25 / Hierarchical Lists (beta), some improvements Changelog	28	3255	June 7, 2021
Relationship properties Ideas & Features flexible-domain	42	3511	March 10, 2026
[Essay] The Knowledge Organization — looking for the most natural way to organize collective knowledge Methods	5	1805	September 7, 2020
🌰 Fibery major conceptual (yet) unsolved problems News & Announcements	33	1388	October 8, 2026

Representing nested relations

Related topics