Representing nested relations

It looks like a bug, we should fix it

1 Like

No, just PEBKAC (problem exists between keyboard and chair).
I hadn’t clocked the need to enable recursive nesting with the little icon :crazy_face:

Thanks @mdubakov, I know you have a lot of priorities :slight_smile:

I was wondering if there will be a possibility to also look into representing the more complex entity relationships like this:

I am able to setup the relations and add the entries, but when it comes to setting up the smart folders, it seems having the “contact” entities at both levels (i.e. under “Organization” and “Organizational Unit”) is not supported:

Is this at all possible?

1 Like

Hi!
Will send the text here as well, maybe that would be helpful for other users to check.
The paradox if anything 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.

Your certain case is 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. Curious case to think about.

We understand that such cases were pretty common, but we just don’t have a good solution in mind. So now we are collecting all of them and later will have a fresh look at it :slight_smile:

4 Likes

I’m very glad to hear about Polymorphic relations again, I really think they will help a lot of problems I am having in Fibery as well with trying to create folder-like hierarchy, but instead of being able to just add an extra individual item on a lower level, I need an *entire level because I have to create a whole new child Type to do that.

3 Likes

Just wanted to add another example of this type of nested relation in the area of project management (as defined by PMBOK):

  • A project is a temporary endeavor undertaken by a company or organization (such as the creation of a new product, service, or result)
  • A program is a group of projects that are similar or related to one another, and which are often managed and coordinated as a group instead of independently
  • A portfolio is a group of different programs and/or projects within the same organization, which may be related or unrelated to one another

Portfolios will be the top layer, but then both programs and individual/stand-alone projects would be nested inside the portfolio. The programs in turn would have some nested projects. I’ve modeled it in Fibery like this:

image

It would be great to be able to view this type of relation in the UI.

1 Like

Am I correctly interpreting that only top-level types within a hierarchical list are allowed to be recursive? Would it be possible to allow nested types to have recursive relations as well?

I’ve got two types, ideas and tasks (it’s sort of a simplified GIST approach). Ideas can have sub-ideas and sub-tasks. Tasks can also have their own sub-tasks. Currently I’ve got a list that shows nested ideas, but I can only make it show the first level of sub-tasks.

Unfortunately not (but you’re not the only one hoping that this will change :wink: )

If tasks could have either an idea as a parent or another task as a parent, then tasks can’t be shown recursively in a hierarchical list at a sub-level.

Polina said it best:

1 Like

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:

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

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:

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:

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.

2 Likes

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).

2 Likes

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).

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.

1 Like

https://help.fibery.io/en/articles/3310832-hierarchical-relations

:slightly_smiling_face:

I totally agree that this will be a useful addition.

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.

1 Like

@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):

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

The second thing I wanted to achieve was being able to have:

  1. Projects that are part of a Program or
  2. 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

Usability Testing

Could you elaborate on how the approach I’ve been suggesting would break those existing apps or constrain hierarchical views in them?

1 Like

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:

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

  1. Build each database’s nested structure :heavy_check_mark:
  2. 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:

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.

2 Likes

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?

1 Like

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:

  1. Add each Feature to every Product (assumes Product is at level 1 and Feature at level 2)
    image

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

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.

3 Likes

That is true. I think we went in this tangent after your second post and focused on self-relations. I leave it up to you if we should split the replies into a different post. As you said there are inter-related discussion along with the many-to-many conversation.

I think your original question is a very interesting situation that I can’t quite wrap my head around. Are there some examples of A → B → A relation that you can provide?

I assume this situation would arise when you have two relations from B:

  • Relation “Parent A” is defined as [A] -------* [B]
  • Relation “Child As” is defined as [B] -------* [A]

I think this will require allowing the same database to appear in the hierarchy more than once:

image

Or instead of adding databases to hierarchies, build the hierarchy based on relations:

I actually don’t have any idea how feasible this would be :man_shrugging:

3 Likes

Thanks for engaging in such a great discussion.
I think your ideas are really valuable, and will stimulate some internal discussions around the topic.

Wrt A - B - A, my go-to example is a bill of materials:

A is a database of ‘parts’, and B is a database of ‘lines in a b.o.m.’ (which consist of a quantity field and a relation to a part).
Perhaps I should have shown it as A → B ← A since the idea is that a part may be an assembly (therefore is linked to multiple b.o.m. lines) and a part may also be present as the related part in b.o.m. line(s).

In practice, there is no way that a part can be a subcomponent in an assembly, which is then somehow a subcomponent of the original part(!) so there is no chance of an endless recursive loop, but the schema would in principle allow it :-/

It just feels like it would be nice if the hierarchical list view could allow navigating down through the entities from type A to B to A to B to A …etc.

Yeah, it was my fault, but it’s been a productive tangent :wink:

3 Likes