Tree widget: Customize model tree to add child nodes of specific elements

[gedkek]

Is it possible currently to customize Models Tree hierarchy to add related nodes from different schema than the parent?

By default they go to a separate parent node even though a relationship exists between these created items and their parent.

For example: if slicing one element (of class BisCore.GeometricElement3d) into 2 parts, in the tree the sliced element should get 2 children as 2 elements get created (created elements are of class Construction.ConstructionDetailingElement).
Instead they go to separate folder at the top of the tree that contains all construction only nodes.

Would like to effectively merge the construction data into models tree using relationships.

From what i found, can group nodes in pre and post processors for specific node, but only if they represent instance of same class, but since they both are of different classes, i assume pre-processor can't find the ConstructionDetailingElement or is only handling nodes that would exist in that specific tree?

Is it possible to somehow add nodes to models tree based on relationships?

[grigasp]

Is it possible currently to customize Models Tree hierarchy to add related nodes from different schema than the parent?

You don't need to customize the component for that - all Models tree queries are polymorphic, meaning we take elements of specified class (e.g. bis.GeometricElement3d) and all its subclasses, including the ones from other schemas.

By default they go to a separate parent node even though a relationship exists between these created items and their parent.

For example: if slicing one element (of class BisCore.GeometricElement3d) into 2 parts, in the tree the sliced element should get 2 children as 2 elements get created (created elements are of class Construction.ConstructionDetailingElement). Instead they go to separate folder at the top of the tree that contains all construction only nodes.

I believe that would only be happening if the sliced element and its parts were in separate models - is that the case? On the other hand, that means the relationship between sliced elements and parts is not parent-child, because, according to BIS rules, children have to be in the same model as their parent.

[gedkek]

its not a direct parent-child relation i suppose, rather a ECRelationshipClass is used in the middle from Construction schema between ConstructionDetailingElement and bis:GeometricElement3d.
And yes they seem to be in deferent models.
So i guess, would need to pass that relationship class somewhere

[grigasp]

So basically what you're asking is to move an element from its rightful place in the Models tree to somewhere it doesn't really belong, according to Models tree hierarchy rules. I don't think that's a good idea for multiple reasons:

• The hierarchy would be lying about the data:

  - ModelX
    - CategoryX
      - SlicedElement (in ModelX)
        - PartElement (not in ModelX, but under ModelX ancestor node).
  

• Visibility states would become even more confusing than they already are - visibility of "PartElement" in the above example would NOT be affected by changes to ModelX, SlicedElement, and likely - CategoryX. Similarly, changing visibility of "PartElement" would NOT affect ancestor nodes' visibility states.

Due to above reasons, I think making the requested changes to Models tree is not a great idea. You can still make your own hierarchy using publicly available building blocks.

[gedkek]

This is not for changing models tree behaviour by default, rather to have ability to add nodes via relationship classes.
The idea would be to have separate tree - not replacing models tree - for displaying this construction data, where this kind of hierarchy is desired - as the split elements are together the one element, and going to a separate tree is rather cumbersome.

For visibility, could it not propagate using the provided relationship class for child nodes as well?

The problem with building a complete custom tree hierarchy would probably involve just copying over entire models tree with some additional logic, since for the most part would be same behaviour.

[grigasp]

This is not for changing models tree behaviour by default, rather to have ability to add nodes via relationship classes.

I understand. But there are some customizations that we don't want to allow making, because with them Models tree becomes something other than Models tree. Especially in this case, where, IMO, the resulting hierarchy would be lying about the data.

For visibility, could it not propagate using the provided relationship class for child nodes as well?

Visibility works independently from hierarchy to make sure changes in one tree are properly reflected in all others. E.g. changing Category node visibility in Categories tree affects Model nodes' visibility in Models tree. Making the hierarchy changes that you suggested would make visibility controls work unpredictably.

The problem with building a complete custom tree hierarchy would probably involve just copying over entire models tree with some additional logic, since for the most part would be same behaviour.

That's bad, because the Models tree with those changes makes little sense. I suggest thinking about how to properly represent the data to your users, and that, most likely, won't be that similar to Models tree.

[GintV]

The user requested such hierarchy in order to easily locate "sliced elements" within Models Tree hierarchy. The original issue, in which we discussed such changes, was this #711

As a workaround, we were able to modify Models Tree hierachy look by adding additional rules to process on leaf nodes (based on tree-widget react 2.3.2):

diff --git a/packages/itwin/tree-widget/src/components/trees/models-tree/ModelsTree.tsx b/packages/itwin/tree-widget/src/components/trees/models-tree/ModelsTree.tsx
index 39045ad3..f32dd370 100644
--- a/packages/itwin/tree-widget/src/components/trees/models-tree/ModelsTree.tsx
+++ b/packages/itwin/tree-widget/src/components/trees/models-tree/ModelsTree.tsx
@@ -53,6 +53,8 @@ export interface ModelsTreeHierarchyConfiguration {
  * @public
  */
 export interface ModelsTreeProps extends BaseFilterableTreeProps {
+  processRules?: (r: Ruleset) => Ruleset;
+  processSearchRules?: (r: Ruleset) => Ruleset;
   /**
    * Predicate which indicates whether node can be selected or no
    */
@@ -181,24 +183,31 @@ interface UseModelsTreeStateProps extends Omit<ModelsTreeProps, "onFeatureUsed">
   reportUsage: (props: { featureId?: UsageTrackedFeatures; reportInteraction: boolean }) => void;
 }

+const useEvent = <F extends (...a: any[]) => any>(fn: F): F => {
+  const { current } = useRef({ flex: fn, fix: fn });
+  return current.flex = fn, current.fix !== fn ? current.fix : current.fix = ((...a) => current.flex(...a)) as F;
+};
+
 function useModelsTreeState({ filterInfo, onFilterApplied, ...props }: UseModelsTreeStateProps) {
+  const processRules = useEvent(props.processRules ?? ((x: Ruleset) => x));
+  const processSearchRules = useEvent(props.processSearchRules ?? ((x: Ruleset) => x));
   const rulesets = {
     general: useMemo(
       () =>
-        createRuleset({
+        processRules(createRuleset({
           enableElementsClassGrouping: !!props.hierarchyConfig?.enableElementsClassGrouping,
           elementClassSpecification: props.hierarchyConfig?.elementClassSpecification,
           showEmptyModels: props.hierarchyConfig?.showEmptyModels,
-        }),
-      [props.hierarchyConfig?.enableElementsClassGrouping, props.hierarchyConfig?.elementClassSpecification, props.hierarchyConfig?.showEmptyModels],
+        })),
+      [props.hierarchyConfig?.enableElementsClassGrouping, props.hierarchyConfig?.elementClassSpecification, props.hierarchyConfig?.showEmptyModels, processRules],
     ),
     search: useMemo(
       () =>
-        createSearchRuleset({
+        processSearchRules(createSearchRuleset({
           elementClassSpecification: props.hierarchyConfig?.elementClassSpecification,
           showEmptyModels: props.hierarchyConfig?.showEmptyModels,
-        }),
-      [props.hierarchyConfig?.elementClassSpecification, props.hierarchyConfig?.showEmptyModels],
+        })),
+      [props.hierarchyConfig?.elementClassSpecification, props.hierarchyConfig?.showEmptyModels, processSearchRules],
     ),
   };

Having this extension, we did this

<ModelsTree key="Construction" treeType="Construction" enablePreloading
  enableElementsClassGrouping={ClassGroupingOption.Yes}
  processRules={ModelsTreeUtils.patchConstructionTree}
  processSearchRules={ModelsTreeUtils.patchConstructionTreeSearch}
/>

-------

const constructionInstanceFilter = {
  find: "json_extract(this.JsonProperties, \"$.Subject.Job.Bridge\") = NULL AND " +
    "ifnull(json_extract(this.JsonProperties, \"$.Subject.Model.Type\"), \"\") <> \"Hierarchy\"",
  append: " AND this.CodeValue <> \"Construction data\"",
};

const slicesRule = {
  ruleType: "ChildNodes" as const,
  condition: "ParentNode.IsOfClass(\"WorkAreaDetailingElement\", \"Construction\")",
  specifications: [
    {
      specType: "RelatedInstanceNodes" as const,
      relationshipPaths: [
        {
          relationship: {
            schemaName: "Construction",
            className: "ConstructionDetailingElementSplitsGeometricElement3d",
          },
          direction: "Backward" as const,
          targetClass: {
            schemaName: "Construction",
            className: "ConstructionDetailingElement",
          },
        },
      ],
      groupByClass: false,
      groupByLabel: false,
    },
  ],
  customizationRules: [
    {
      ruleType: "ExtendedData" as const,
      items: {
        modelId: "this.Model.Id",
        categoryId: "this.Category.Id",
        icon: "\"icon-item\"",
        groupIcon: "\"icon-ec-class\"",
      },
    },
  ],
};

const constructionRulesAppend: ChildNodeRule[] = [
  slicesRule,
  produce(slicesRule, s => {
    s.condition = "ParentNode.IsOfClass(\"GeometricElement3d\", \"BisCore\")" +
      " AND NOT ParentNode.IsOfClass(\"WorkAreaDetailingElement\", \"Construction\")";
    const i: RelatedInstanceNodesSpecification = s.specifications[0];
    i.instanceFilter = "NOT this.HasRelatedInstance(\"Construction:ConstructionDetailingElementSplitsGeometricElement3d\", \"Forward\"," +
      " \"Construction:ConstructionDetailingElement\")";
    return s;
  }),
];

export namespace ModelsTreeUtils {
  export const constructionRulesId = "ConstructionTree";

  export const patchConstructionTree = (ruleset: Ruleset): Ruleset => produce(ruleset, rules => {
    if (rules.id !== "tree-widget-react/ModelsTree")
      throw new ProgrammerError(`Wrong id: "${rules.id}"`);
    rules.id = constructionRulesId;
    if (!rules.rules.some(x => x.ruleType === "ChildNodes" &&
      x.specifications?.some(s => s.specType === "RelatedInstanceNodes" && s.instanceFilter === constructionInstanceFilter.find &&
        (s.instanceFilter += constructionInstanceFilter.append))))
      throw new ProgrammerError("Construction Rules - Instance Filter Not Found");
    rules.rules.push(...constructionRulesAppend);
    return rules;
  });

  export const patchConstructionTreeSearch = (ruleset: Ruleset): Ruleset => produce(ruleset, rules => {
    if (rules.id !== "tree-widget-react/ModelsTreeSearch")
      throw new ProgrammerError(`Wrong id: "${rules.id}"`);
    rules.id = `${constructionRulesId}Search`;
    if (!rules.rules.some(x => x.ruleType === "ChildNodes" &&
      x.specifications?.some(s => s.specType === "RelatedInstanceNodes" && s.instanceFilter === constructionInstanceFilter.find &&
        (s.instanceFilter += constructionInstanceFilter.append))))
      throw new ProgrammerError("Construction Search Rules - Instance Filter Not Found");
    return rules;
  });
}

We have rechecked and this is still relevant for the user, hence we ask for guidance to provide such tree to them

[aruniverse]

Hi @GintV , few comments

• Just because a single user is requesting a highly specific workflow / feature, doesnt mean we will add support/expose functionality for them. We need more details.
• You should not be presenting a misrepresentation of the data in your app via the trees, which will be very different from the trees users will see in other applications like Infrastructure Cloud.
  • Tagging @diegoalexdiaz and @ColinKerr if they have additional comments to the data being presented here
• You should not be manually patching our code and going to PROD, this is very brittle and prone to break you long term.
• What other alternatives have you explored? Sounds like a tree is not the best fit here
  • Have you spoken to your PM and UX for alternatives?