projects: show ancestor path#5827
projects: show ancestor path#5827valentijnscholten wants to merge 4 commits intoDependencyTrack:masterfrom
Conversation
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
Coverage summary from CodacySee diff coverage on Codacy
Coverage variation details
Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: Diff coverage details
Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: See your quality gate settings Change summary preferences |
Signed-off-by: Valentijn Scholten <valentijnscholten@gmail.com>
valentijnscholten
force-pushed
the
ancestor-path
branch
from
838858e to
2495d8b
Compare
…endpoints - Nest all parents inside the parent block (parent.parent...) in API responses - Add parent to @JsonIncludeProperties for recursive serialization - Wire parent chain in populateAncestorPaths for nested structure - Populate ancestor path on single-project getProject endpoints (uuid, lookup, latest) - Add tests for nested parent chain and ancestor path across detail endpoints Signed-off-by: Valentijn Scholten <valentijnscholten@gmail.com>
- Remove ancestorPath and AncestorPathElement from Project model - Replace with nested parent (parent.parent...) for hierarchy - Add ProjectParentInfo for AffectedProject parent chain - Update AffectedProject to use parent instead of ancestorPath - Rename buildAncestorPathFromMap to buildParentChainFromMap - Update tests to assert parent chain only Signed-off-by: Valentijn Scholten <valentijnscholten@gmail.com>
|
@nscuro I have now refactored both PRs to show the ancestor path as tooltip instead of column. Not perfect, but better than nothing and maybe good to be accepted. I've also refactored the api reponse to just return the chain of parents in the parent block instead of a new ancestor path element. Global Policy Audit doesn't have the full parent chain as that endpoint returned detached JDO Object which only have the direct parent. If we all like the tooltip approach and/or the parent chain response format I could look at refactoring this endpoint to use value objects instead of detached objects. Plot twist: Should we just render the tooltip on the fly using an API call for that view (or all views)? (To avoid having to build the full parent chain in the backend for every api response containing projects) |
Signed-off-by: Valentijn Scholten <valentijnscholten@gmail.com>
valentijnscholten
force-pushed
the
ancestor-path
branch
from
9b84e76 to
eb65130
Compare
2 participants
Description
When searching for projects/components/vulnerabilities there's no visual indication of where in the Project Hierarchy a project is shown.
Addressed Issue
(partly) fixes #1353, #1362
Additional Details
In v4 we need to do perform some additional java code to get the "ancestor path" populated. But in v5 this will be easier due to the materialized view being used there. Happy to forward port the feature to v5.
I haven't created tests yet as I first would like to get confirmation this is something that can be added to v4. I know v5 is around the corner. At the same it might take some time before v5 is released as GA and everybody has moved over. This PR fixes a real need in v4.
FrontEnd companion PR: DependencyTrack/frontend#1448
Considerations
Having the full hierarchy view when displaying ony a subset/searchresult of projects is non-trivial to implement if we take features such as paging into account. Maybe for v5 someone has a better proposal, for now an additional column seems helpful in v4.
Checklist