Project uniqueness should not include the version

[tofuatjava]

The enhancement may already be reported! Please search for the enhancement before creating one.

Current Behavior:

Currently a project is identified by the project name and the version. You have the possibility to add teams, notifications, tags and much more to the project. However, whenever e new version is released a completely new project was generated. This includes that the team assignment or the tags are lost.
For now I see only one option to do not use the version for the sbom upload, or use always the same.

Proposed Behavior:

I would expect, that the project would be identified by the name and all relevant settings like tags, team assignment, notifications, ... will be reused also in newer project versions, otherwise the Portfolio Access Control on Teams and many other information are lost and useless.

[valentijnscholten]

The fact that every version is a new project brings indeed a lot of extra work around ACLs, Audits, connectivity to external tools like Defect Dojo. It would be good to have a full explanation in the docs on why this approach was chosen as probably there are reasons for this decision.

[mulder999]

I believe keeping track of different versions is also interesting. To solve your issue, there are already 2 possibilities:

1. Send SBOM using an existing UUID
2. Update version prior to send SBOM and make sure you set autoCreate to false

[tofuatjava]

Maybe I need to clarify and explain in more detail what I want to achief.

@mulder999 Yes indeed it could be a nice feature to use versions and I want to use it.

PROBLEM:
I have many projects causing artifacts during CI. I'm not the owner/buildmaster of all this artifacts so I cannot control if versions are used or not. Whenever a new CI-pipeline produces new artifacts it will be uploaded via SBOM to dependency-track. Now I was able to put on some meta data to the project by labels/tags and so on. I need this meta information to classifiy and categorize the artifacts to company-projects and customers and want to assign a responsible and many more information.

My first problem is now that when ever the CI pipeline is creating a new artifact with an new version I get a completly new project in dependency-track and all additional information are lost. Uploading to a UUID will solve this, but is more or less a workaround and I need to force my customer to reconfigure his pipeline. In large companies this will not work...

My second problem is, that I want to report the finding to our internal vulnerability database where our security responsibles are watching and reports to the management. Having many artifacts in different versions for the same project makes it a way more complicated to report issues. I only need to monitor active resources (resources which are deployed and used). Every historical artifact is not interressting for monitoring anymore. Nowadays I do this by manually deactive the artifacts. This take me hours every week.

SOLUTION IDEA:
Having a container object representing an artifact identified by the name or gov in case of maven where the meta information and all version of these artifact are linked to will reduce the complexity and improves the userbility.
Having an option on this container object to activate that only the last uploaded version is active and will be monitored and showed in the statistics whould safe me a lot of time.

[mulder999]

Sorry but no matter how big your customer is, they used the wrong endpoint in the first place. They should report using the UUID you give them. It is a 5 min effort to switch. This is all what you need to cover all your use cases and certainly not a workaround if you want to keep things organized.

Would also remove the create project rights of your customer api token in order to regain control over the projects. The last thing you want is mess in this tool.

[mulder999]

Beside release 4.7 introduced the concept of parent child relationships between projects. At least you could leverage this to regroup all the "versions". It won't solve your actual issue which come solely from the fact you are not interested by tracking any specific versions but only the latest.

[roadSurfer]

Maybe I have misunderstood, but is this not bascially issue 2041?

@mulder999 - could you please point me the direction of the docs/ticket for project parent/child relationships? Thanks.

[mulder999]

@mulder999 - could you please point me the direction of the docs/ticket for project parent/child relationships? Thanks.
Was indeed thinking to #84.