Notifications in the UI have a different visible name than the actual event

[grahamc]

Current Behavior

in DT4 these names like VEX_PROCESSED were the literal name that were received in the webhook. In DT5, these enums have prefixes, like INFORMATIONAL -> LEVEL_INFORMATIONAL, VEX_PROCESSED -> GROUP_VEX_PROCESSED.

Steps to Reproduce

1. Create a webhook

Expected Behavior

I expected the names to reflect the event type or have it be visible in the UI the even they correlate to.

Dependency-Track Frontend Version

5.x

Browser

Google Chrome

Browser Version

n/a

Operating System

macOS

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this defect was already reported

[Naxdy]

It appears many (all?) enums have received prefixes coinciding with what they represent. For example, a Dtrack 4 payload of

"notification": {
     "level": "INFORMATIONAL",
     "group": "VEX_PROCESSED",
     // ...
}

Would be the following in Dtrack 5:

"notification": {
     "level": "LEVEL_INFORMATIONAL",
     "group": "GROUP_VEX_PROCESSED",
     // ...
}

I do agree that the frontend naming should be adjusted to match the payload naming, but what would also be helpful is if there was a way to copy the sample payload directly from the app into the clipboard.

[nscuro]

@Naxdy Yes, and it's documented:

• https://dependencytrack.github.io/docs/next/concepts/changes-in-v5/#what-this-breaks
• https://dependencytrack.github.io/docs/next/reference/schemas/notification/

[nscuro]

I think the underlying confusion here comes from the fact that the frontend shows (technical) enum names, and the wire format now differs from them. In v4 it was fine because the wire format used the names as shown.

My pitch would be to replace the values in the frontend with human-friendly text, e.g. New vulnerability instead of NEW_VULNERABILITY. That way there would be no implication anymore of the value being the same on-the-wire.

Regarding the wire-format change, it's due to how Protobuf handles enums. A middle-ground I could offer is that we add separate name fields, e.g. "levelName": "INFORMATIONAL".

Any thoughts in either of these suggestions?