Dependency Graph does not follow transitive dependencies

[exief]

Current Behavior:

UI does not go through each transitive dependency in the dependency data to build out a complete dependency graph, resulting in a limited depth of dependencies shown in the UI.

Proposed Behavior:

UI should follow each transitive dependency in the data, check if it has further dependencies, and render a complete dependency graph in the UI.

[coderpatros]

@stevespringett any chance you can point me to where the relevant code is for this?

[stevespringett]

@coderpatros its in src/views/portfolio/projects/ProjectDependencyGraph

[claudioandreantonio]

Hi @stevespringett . Do you have an estimation when this might get fixed?
Thank you.

[stevespringett]

@claudioandreantonio I'm not actively working on it and without a community PR, it will likely get pushed back to v4.6.

[claudioandreantonio]

Thanks @stevespringett . Let me see if I can help. What part of the code is responsible for generating this map? https://github.com/DependencyTrack/frontend/blob/master/src/views/portfolio/projects/ProjectDependencyGraph.vue ?

[stevespringett]

Correct. I think the only thing necessary is to make calls to the server for all child dependencies whenever a parent dependency is expanded. That way, the plus arrow and all dependencies will be in place should the user request that information.

[rkg-mm]

Unfortunately, the graph is a little useless anyway in this way in my opinion.
The regular use case of the graph is: "Component X is vulnerable, I want to see where this dependency is coming from".
Even if the full graph would be printed, it will be hard to find the dependency (we regularly have 200-800 indirect dependencies!).

What would really be required is:

1. Printing the full graph (at least on expansion)
2. Having a button in the component list and component view like "Show in dependency-graph"
3. Focus the dependency-graph on that component, means: open the graph down to the correct component and highlight it
4. Ideally additionally: grey out all components, which are not part of the parent-graph of this single component, so you got a highlighted component, a bright list of the upper tree leading there, and greyed out everything else.
5. Maybe also a search field above the graph, to search for component names, highlighting all matches that way

Maybe that would require to change how the graph is displayed, make the elements much smaller and allow zooming, and moving left/right.

[msymons]

Printing the full graph (at least on expansion)

This is actually really important. I just had a look in DT at one of my large projects with many modules, I took me over 1 minute of clicking to expand the tree as each time a branch expanded I then needed to scroll down before I could see the next "+" to click on. And this would take even longer if the graph were fixed in v4.6 to be able to display more depth.

And once this was done, I was left with a tree that requires 0ver 20 page-down to navigate from top to bottom.

I think this last bit emphasizes the utility of filtering (see #87)

[lsauer]

Some of my suggestions from #212

Current Behavior:

• the tree has a cutoff at 3rd depth level. Or there is a bug or something I did not understand.
• double click on a node only expands
• the package name is not hyperlinked

Proposed Behavior:

• don't cutoff at any level and preload the entire tree
• double click on a node expands all subnodes
• the package name is hyperlinked and references the package entry page

For discussion:
Color the node-circle depending on the sum or avg of its child severities

[rkg-mm]

We will try to take care of this issue and implement a more useful Dependency-Graph in next weeks, picking up some of the discussed issues here and some other ideas we had.