Introduce "collection" projects for better usage of hierarchical view #2041

[rkg-mm]

Description

This change introduces UI logic for "collection projects". Those are basically projects used as parent for other projects that shall not hold any own component or vulnerability data, but instead get calculated from child projects using different configurable aggregation logics.

• Project Details/create dialog allow selection of different collection logics (all direct children, direct children with custom tag, direct children which are latest version)
• Collection projects are visually marked in project list and get shown aggregated metrics. The used calculation logic is displayed on mouseover of calc icon
• Project page hides all unrelevant tabs, instead shows a new tab with all child projects. For this the project list is made reusable
• Project metric charts display a blue vertical line when projects collection logic changes (includes entry in tooltip)
• Allow NONE as project classifier and
  ** Add Frontend support for other missing classifiers which are supported by backend already since 2023
  ** Move available classifiers into mixin to reduce code duplication & ensure classifier dropdown list is sorted identical in all views
• Additionally:
  ** Fixes some routing bugs

Required Backend PR: DependencyTrack/dependency-track#3258

Addressed Issue

DependencyTrack/dependency-track#2041
DependencyTrack/dependency-track#657
DependencyTrack/dependency-track#2410
#641 (routing Bug)
Fixes #1025

Additional Details

Hint: Screenshots show outdated "HighSemver" functionality, which was exchanged.

Checklist

• I have read and understand the contributing guidelines
• This PR introduces new or alters existing behavior, and I have updated the documentation accordingly

[123Haynes]

This is a feature I would love to see in dependencytrack. Would certainly make it easier to structure projects and see the issues at a glance.

@nscuro Is there anything left todo to be able to merge this pr and the corresponding backend pr?
It looks like this feature was finished month ago, but is just kinda floating around without getting merged.
Is there anything people can help with to get this over the finish line?

[rkg-mm]

Warning: I fixed a lot of conflicts and did not have time to test it. Will try to find time tomorrow to test it. Furthermore I threw out my bugfix for the double loading logic as @nscuro already did another fix for this

[rkg-mm]

[deleted - belonged to backend]

[rkg-mm]

Should be good to go :)
[closed by accident.. wrong button - reopened :D ]

[rkg-mm]

@nscuro do I need to do something for the failed checks? the i18n issues don't seem to be from my changes, and the other Linter I don't see where I can find the actual output of whats wrong, only the files it complains about.

[nscuro]

Just gave this a spin. I didn't test super extensively yet but wanted to note it down before I forget.

I created a collection project and uploaded about 50 or so BOMs to it. I selected collection logic Direct children with tag.

Looking at the list of projects, either in the Projects or Project -> Collection projects view, show no indication which project counts towards the metrics. I am seeing the metrics of the collection project, but I have no idea how they came to be.

Looking at projects in the list doesn't give a hint either. This might be more of a problem once you have more than 10 projects, so they don't all fit on a single page anymore.

I think some kind of visual cue is needed to make it clear which projects are counted towards the collection's metrics.

With only the Aggregate direct children option, this would not be a problem. However once we limit aggregation to a subset, we need to make it visible what subset that is, somehow.

[rajitha-vk]

@rkg-mm any plans to get this merged?

[rkg-mm]

@rkg-mm any plans to get this merged?

Yes I would prefer to have it merged asap, but since I had to wait a while I got now in a timeframe where I lack time to implement the Feedback, not sure if I can finish this soon. If anyone wants to help feel free to raise PRs to my branch and I can integrate changes. Otherwise I fear this will need to wait a bit.

[rajitha-vk]

@rkg-mm any plans to get this merged?

Yes I would prefer to have it merged asap, but since I had to wait a while I got now in a timeframe where I lack time to implement the Feedback, not sure if I can finish this soon. If anyone wants to help feel free to raise PRs to my branch and I can integrate changes. Otherwise I fear this will need to wait a bit.

I tried to look into why two checks failed, but the logs have already expired. Any idea to rerun the checks would be appreciated.

[rkg-mm]

@nscuro can you help with rerunning the checks?

[nscuro]

@rkg-mm Sadly it's not giving me the option to:

For comparison, the option is available for a workflow that ran earlier today:

I think you need to push a change (can be an empty commit) to trigger another build...

[msymons]

Re-assigning to 4.13 milestone in order to reduce the pressure on contributors to get this finished whilst allowing v4.12.0 to be released quicker.

[Najafov007]

Hello! When approximately we will be able to get this update? Thank you)

[rkg-mm]

@nscuro can you explain how to

1. fix the i18n failure
2. fix the linter? I tried running the prittier-fix script, however, that changed >200 files which I did not touch, so likely not the correct solution?

[nscuro]

can you explain how to

1. fix the i18n failure

The check is failing because translations are missing for newly added i18n keys. Here's instructions on how to auto-translate: https://github.com/DependencyTrack/frontend?tab=readme-ov-file#adding-or-improving-translations

2. fix the linter? I tried running the prittier-fix script, however, that changed >200 files which I did not touch, so likely not the correct solution?

That should be the correct solution. But yeah it shouldn't modify stuff you didn't touch. What kind of changes is it doing to those files?

[rkg-mm]

That should be the correct solution. But yeah it shouldn't modify stuff you didn't touch. What kind of changes is it doing to those files?

It tried to change Line endings in 200 untouched files between CRLF and LF. For now I think I fixed it by rolling back all files i didn't touch and only commit the others after running prittifier, but maybe you have an idea how to fix that for next changes?

[rkg-mm]

Just gave this a spin. I didn't test super extensively yet but wanted to note it down before I forget.

I created a collection project and uploaded about 50 or so BOMs to it. I selected collection logic Direct children with tag.

Looking at the list of projects, either in the Projects or Project -> Collection projects view, show no indication which project counts towards the metrics. I am seeing the metrics of the collection project, but I have no idea how they came to be.

Looking at projects in the list doesn't give a hint either. This might be more of a problem once you have more than 10 projects, so they don't all fit on a single page anymore.

I think some kind of visual cue is needed to make it clear which projects are counted towards the collection's metrics.

With only the Aggregate direct children option, this would not be a problem. However once we limit aggregation to a subset, we need to make it visible what subset that is, somehow.

@nscuro
I see the need. But I'd like to have some proposal how you would like to do it. The data is not available in client. Currently the projects are figured out during metrics update. There is no stored indicator.
I see following options:

1. We store it in the collection project in some new field. I don't like it, as during each metrics update we need to possibly update the collection project entry. Also, would have to be some array of project IDs, which have no DB foreign keys (but we have other places doing this already).
2. We store it in each child project, if it accounts for the parents calculation. I don't like this either, as we need to possibly modify even more projects in metrics updates.
3. We store it in the metrics object of collection projects. Makes logically sense. However, would have to be some array of project IDs, which have no DB foreign keys (but we have other places doing this already). Furthermore: There are possibly MANY metrics entries, and each would hold this list. Only the latest one is relevant, but there is a lot of history data in DB, of possibly no longer existing projects.
4. The API returning projects calculates this for all collection projects before returning the project. This would not be good performance wise.

I don't like any of these solutions :-( . Better ideas?

[netomi]

fyi: a package of this PR is available at https://github.com/users/netomi/packages/container/dtrack-frontend/289602681?tag=4.13.0-SNAPSHOT

ghcr.io/netomi/dtrack-frontend:4.13.0-SNAPSHOT