Add optional organization/group structure

[stevespringett]

Current Behavior:

The portfolio metrics are root level. All projects are directly in the root.

Proposed Behavior:

Add optional project organizational/group assignment where a project is a member of 0 or 1 organizations or groups. Not sure what the exact term should be.

[msymons]

Would this cover tags? A collection of (say) 10 projects with tag team-denver is a "group" (from the user's perspective) and should have metrics that are specific to the tag.

[stevespringett]

I think tags are a different use case. This ticket is to virtually separate projects into various groups and eventually have the system be able to apply different policies and access control to the various groups. Business units, partial portfolio responsibilities, etc, are the intended uses.

[stevespringett]

The use case of tags is interesting and it may be possible to do something like that in the future once DT migrates away from a relational database. Graphs are its future, and doing those types of queries would be elementary with a graph and a lot more complex with RDBMS.

[RoSk0]

Will this functionality cover a use case where, for example, web application has production environment plus number of pre-prod copies (lets say ST & UAT) used for various testing purposes? At the moment, if I'm not missing anything, the only way to represent all three in DT is to create three projects "${APP_NAME} Prod", "${APP_NAME} UAT" & "${APP_NAME} ST". Would it be possible to represent all of them as a single group or using another term but in a grouped way ?

[valentijnscholten]

For us this feature would help us organize projects per client. We have 100+ clients and 1000+ projects. Ideally we would organize the projects per client, and also assign permissions per client. i.e. a new top level of "Project Group" would solve this. Or it could be that there can be multiple portfolio's within the same DT instance and projects could be grouped into portfolio's.

[rkg-mm]

I think this can be tackled now using the new parent-child views we introduced in DependencyTrack/frontend#328.

Basically, my idea posted here #2041 could be used for this. While my idea only covers the data shown in the project list so far, it could also be extended, that those "Collection" projects (anyone got a better name maybe?) instead of giving component-lists etc, could show some view with metrics about this collections children.

@stevespringett @nscuro would this work for you?

[ryhoo2]

Hi,

I stumbled on the same problem. I think what we need here is a new type of Project Classifier, called let's say "Organization Unit". When new project is created with such classifier it will not allow to add/remove any components directly to it. It will only be used to properly organize the structure of Systems, Subsystems and Products. Such classifier would aggregate all Metrics, Audits and Policy Violations of all child elements connected to it.

[nscuro]

@ryhoo2 I think your ask is covered by @rkg-mm's PR #3258.

[nscuro]

@rkg-mm While #3258 addresses large chunks of this, I actually think this ticket is at least partially about multi-tenancy:

This ticket is to virtually separate projects into various groups and eventually have the system be able to apply different policies and access control to the various groups. Business units, partial portfolio responsibilities, etc, are the intended uses.

We're currently missing the access control part etc., so I'm being cautious and will remove it from #3258 "fixes" list.