dependency-track

dependency-track copied to clipboard

Current Behavior:

Currently, the admin can create notifications in the backend for all projects for single mail addresses or other channels. With a bigger amount of projects this is problematic, since one person can't handle all projects. Creating different notifications for individual projects is possible but takes effort and for each version must be remembered to add the new version to specific notification(s) again.

Proposed Behavior:

It would be very helpful, if people could subscribe (or be subscribed) to individual projects, or even better: to projects matching specific criteria. Use Cases:

1. Project Manager/Architect can subscribe to a project. Important: It must be matched by name since he usually would want notifications on every single version, not only one specific version.
2. Business Unit leader / BU security responsible can subscribe to a tag representing his business unit (alternatively: namespace/group)
3. Lead architect/legal department can subscribe to all projects for policy violations but only for license violations

Important: Especially when doing matching by tags etc. the project permissions need to be respected, to ensure you won't be notified for projects you are not allowed to see.

Additionally: I think it would make sense to be able to define one user as main project responsible in project settings. (E.g. dealing with 25+ projects of different departments I always need to look up who is responsible if I need to contact someone). This responsible person should have by default a notification configured automatically for this project. New project versions should take over the same responsible automatically.

@stevespringett Since for us this would be a very helpful feature I can assign a coworker to take care of this improvement in some weeks. Would you help me define the requirement in a way, that you would accept a PR for it?

After thinking about it again and also taking #1601 into consideration, my use case would be following: I am using the ACL feature, so each project team is mapped to an AD group and each team assigned to a specific project. I want the whole responsible team to get an email notification when new vulnerabilities (or potentially also policy violations come up). I would also think for some people defining not a full team but only one or multiple specific persons (which in my opinion should be one of the users of the system) could be helpful.

To reduce the effort/amount of necessary changes I would be fine with adjusting the current Alert System, so that an Admin can configure this instead of people subscribe themselves manually. Would avoid introducing completely new UIs etc.

Looking at the current Alert (mail) Feature, it has following problems here:

1. I can only enter an email as destination, not select a user or better: a full group: This could be done probably relatively easy, by adding 2 more options for the destination: Either specify an e-mail in the textfield, or add one or multiple users from a selection, or add one or more groups from a selection. Didn't look at technical details or data structures yet, but would guess this can be done easily?

2. I need to select every version of a project. With some projects pushing out new versions every 2-4 weeks, it is not possible to maintain this list by hand every time a new version is created, especially since the creation happens automatically via build pipelines. Giving the build pipelines admin permissions to modify the notifications via API is also not a good idea I think. I am unsure how to tackle this problem. I see this as a problem in multiple places of the system. Do you have an idea here already how to improve this or handle it generally? I need all versions of a project to be covered when selecting it, so basically should be able to select a project without a specific version. It could be done with a simple Project name match, but then updating a project name would break it, so not a good idea either. Any hints welcome.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.