Representing nested relations

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

1 Like

Actually, I also have some apps where type A is a parent to type A, e.g. org chart. It sort of looks OK in whiteboard view, but it’d be good to be able to visualise this in hierarchical lists as well :slight_smile:

@Chr1sG If I understood you second post correctly, I think that is already possible with the smart folders and the new hierarchical lists.

However, there are still a few issues and limitations to this. I’ve documented some of these in this clip. I was hoping the hierarchical lists would address this, but I’m thinking the problem is not as easy to solve as appears.

[UPDATE: should have watched your video before posting. I hadn’t realised that I needed to select the recursion symbol when configuring the list. It works fine, thanks]

Yeah, I had been using it in Smart Folders, but it wasn’t working in hierarchical lists. Think it might just be a bug for me:

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.

1 Like

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

: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