search

jenkinsci / dependency-track-plugin

Main repository for the official Dependency-Track Jenkins plugin
https://dependencytrack.org/
Apache License 2.0
44 stars 27 forks source link

Add the possibility to assign (newly created) projects to a team #162

Closed malice00 closed 1 year ago

malice00 commented 1 year ago

In my company there is a strict separation between projects, so we are using the portfolio access control in Dependency-Track quite heavily. We do have administrators that could assign projects to teams, but our teams would like feedback asap. Therefore it would be nice to have the option in this plugin to assign a project to a team automatically.

The solution would be to add a textbox in the UI where users can add the name of their team, which will then be located in the list of teams and a mapping with the project (either new or existing) is created.

sephiroth-j commented 1 year ago

Projects created when the BOM is uploaded are automatically assigned to the team whose API key was used. This is therefore a one-off action. For existing projects, this is also a one-time action. For this reason alone, I don't think this is a valuable feature. Also, the team needs the "ACCESS_MANAGEMENT" permission to do this. This permission allows the management of users, teams and API keys, which is far too permissive and would undermine the purpose of controlling access to the portfolio.

malice00 commented 1 year ago

You are correct in that the team whose API key is used will be assigned the project, however in our setup there is only one such user/team -- it is the one configured globally in our jenkins. The other teams do not have API keys and their privileges inside of DT are only viewing their portfolio, viewing and analyzing vulnerabilities and policies. And because the teams don't want to sent an e-mail to the DT-admins every time they create a new project or version, we were looking for a way to automatically (or at least in the teams' control) assign the projects to their portfolios.

For us this makes sense in this way, because everything is built around these teams -- all teams know their 'names' and roles and these are used all throughout our tooling (GIT, Jenkins; JIRA, etc).

I hope you reconsider and will accept this request and my PR for it...