Representing nested relations

@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?