Forum Discussion

AngelaIp's avatar
AngelaIp
Ideator I
5 months ago

Tree Grid Views but with additional filters to hide data we don´t need - what options do we have?

Hi community,

let´s assume we have a multilevel BOM with many Parts. Some of them have Documents attached. There are Documents on level 0, 3 and 7 of the BOM. I want to have an tree-like overview of the Parts and the Documents, but I don´t want to display the Parts with no documents. 

We can use AML or SQL to get the data. E.g. I currently use following custom AML solution to get all documents and their levels in a simple grid rendering, SQL would work similiar:

In the past I already used some 3rd part libs to render lightweight trees. But these custom trees often don´t blend in well if we don´t spend a lot of time with styling. 

So my idea is right now to use TGV for the tree rendering. I made a very test with QD and TGV. Data is missing intentionally as it´s just a functional sample. TGVs work well for trees, but they will show the complete BOM structure. Is there any way to hide the data we don´t need?

We can use parameters to filter the data. But this filter option currently only hides the text of the elements and not the complete grid row itself. 

This behavior probably has a reason. In a multilevel BOM scenario Innovator cannot tell on which BOM level we have documents. TGVs need the complete data for the rendering. But I would be awesome if we would have some additional filter options to play around with appearance of the data AFTER query execution.

Does anyone has an idea to do these kind of tree renderings? Thanks for any input!!!

Angela

Tree Grid Views

4 Replies

  • jeff_stroh's avatar
    jeff_stroh
    Ideator I
    3 months ago

    Angela, in your query definition try using an 'Exists'

    You may have to do this at a level or two below.  This will remove the nodes that don't have anything below.

    • AngelaIp's avatar
      AngelaIp
      Ideator I
      3 months ago

      There is an "Exists"?!?!? I am shocked! [emoticon:f395e0ed7f2b4f71a3a75ca0fa47590c]

      Thanks a lot for the hint – I’ll give it a try soon!

  • Kevin_Feller's avatar
    Kevin_Feller
    Ideator I
    2 months ago

    The Exists works when it is the next level but I haven't had luck when it is further down the relationship tree.   Since you are just looking for a flat report (so not expanding nodes) and you stated you could do it in SQL you could create a SQL view and and pair that to a new federated item type.  Once you have that the TGV is just adding the new item type.   

    • AngelaIp's avatar
      AngelaIp
      Ideator I
      2 months ago

      I made some tests back then. I just noticed that I never provided some feedback.

      The original idea was using a self-repeating multilevel query like this:

      But using "exists" in this context doesn´t work properly. Deeper levels are cut when upper levels don´t contain a document.

      What DOES work is something ingenious like this: 

      The highlighted green stuff are the "exists" filters. [emoticon:0e469978eb8947d18b9c41123db3725a]

      This one gives this result:

      Pro:

      - It´s a proper tree, even with the intermediate levels!

      Con:
      - I have up to 10 levels...my sample just used 4.
      - Server crashed at a certain complexity of the query. So much for five year record without a developer-induced server crash.

      So far I already used an SQL based solution for these kind of renderings. 
      That is my current flat view.
      Con: It doesn´t list the intermediate levels. Users don´t see, how the data is connected.

      In my use case, I would prefer to not have a flat-view, but a tree like rendering. I already used some external JS libs for tree rendering in the past, but it´s always a lot of work and the UI/UX often doesn´t blend-in. 

      Any idea of how to make the SQL result more "tree-ish"?