Add option to deactivate old project versions on BOM upload

[crumohr]

Description

Fixes #4532

Addressed Issue

Current Behavior

In a continuous delivery scenario every commit to a software project creates a new version (and therefore project) in Dependency-Track. Over time there will be hundreds of "active" versions, even though they are actually not "active".

New Behavior

The POST /v1/bom resource has another flag in addition to the already existing isLatest parameter: isActiveExclusively.

When both arguments are true all "old" versions are deactivated and do not clutter the UI anymore.

Checklist

• I have read and understand the contributing guidelines
• This PR fixes a defect, and I have provided tests to verify that the fix is effective
• This PR implements an enhancement, and I have provided tests to verify that it works as intended
• This PR introduces changes to the database model, and I have added corresponding update logic
• This PR introduces new or alters existing behavior, and I have updated the documentation accordingly

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ +0.02% (target: -1.00%)	✅ 95.83% (target: 70.00%)

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (bcd2651)	23013	18284	79.45%
Head commit (dfa6e6f)	23036 (+23)	18308 (+24)	79.48% (+0.02%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#4533)	24	23	95.83%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

[crumohr]

While not pretty this MR makes this work without any refactoring of the existing code. I can provide a refactored version of @POST uploadBom() when needed.

[nscuro]

Please also extend the other uploadBom accordingly, so they're consistent functionality-wise.

[crumohr]

Please also extend the other uploadBom accordingly, so they're consistent functionality-wise.

Done.

[crumohr]

@nscuro, I hope you’re doing well. I’m checking in to see if there’s anything else you need from me regarding this PR. I’m happy to make any further changes if needed. Thank you for your time!

[alexsuter]

I'm looking for something like this. I have multiple release trains e.g.

Release Trains:

• 10.0.x
• 11.0.x
• 12.0.x

At the moment the current versions are:

• 10.0.2
• 11.0.4
• 12.0.1

If I upload 10.0.3, then I would like to deactivate 10.0.2. If I upload 11.0.5 then I would like to deactivate 11.0.4. Something like minor version based.

Is this a plausible requirement? At the moment I think, I will change all the pipelines that the version is only the minor part. e.g. 10.0, 11.0, 12.0 and so on.

[crumohr]

@alexsuter for sure that is possible. I would like to see the current feature set being merged before extending the scope.

@nscuro for sure you have been busy with preparing yesterdays release, great work!

[gueyemoo]

Any news about this PR ? @crumohr It would be a very interesting feature to have

[lveitch]

Has there been any movement on this feature; I also would love to have this option as we are in a similar situation where the BOM is last in our CI pipeline and would love to have this option.

[nclsptrk]

I would also appreciate having this feature since we also upload our BOM files as the last step of our CI pipeline.

@nscuro Are there any further inputs/changes required before this can be merged?