Add option to test notification publisher

[2000rosser]

Description

Add a new endpoint that can be used to send out a notification test for the specified rule using its UUID.

Front end implementation: DependencyTrack/frontend#949

Addressed Issue

#2924

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.25% (target: -1.00%)	❌ 17.02% (target: 70.00%)

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (c7f3e4c)	22113	16902	76.43%
Head commit (108dc87)	22207 (+94)	16918 (+16)	76.18% (-0.25%)

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 (#3983)	94	16	17.02%

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}

[nscuro]

I'm not sure this addresses the original feature request.

Having a test button for the email publisher makes sense, because DT only ever connects to a single email server, and those connection details are a global setting.

However, for pretty much all other publishers, there is no global configuration. Instead, destination URLs are configured for each alert (see for example MS Teams, Slack, Webhook). Testing the publisher without an alert (NotificationRule) will not work for those.

We'd need a test functionality on the alert / NotificationRule level. This also means we can't use the same hardcoded Notification, since alerts are configured for specific levels and groups. Either we dynamically build a Notification object that will satisfy the alert under test, or we let users provide an entirely custom one.

[2000rosser]

The approach I went for was to test only the destination for the selected alert rule in the setup page, which worked for the publishers I tested (Slack, MS Teams). If we want to test on the NotificationRule level, which approach would be preferred, letting users provide a custom Notification or build one that satisfies the NotificationRule.

Could possibly POST the NotificationRule similar to here (or just the UUID) and then either build the Notification that satisfies it or send a user provided one.

[nscuro]

The approach I went for was to test only the destination for the selected alert rule in the setup page, which worked for the publishers I tested (Slack, MS Teams).

That approach is not necessarily wrong, either. But it limits the usefulness of the check a bit, since individual rules can be customized further (i.e. auth headers for Outbound Webhook alerts). Ideally you'd want to know whether a specific rule works.

Could possibly POST the NotificationRule similar to here (or just the UUID) and then either build the Notification that satisfies it or send a user provided one.

I think if we can assemble one or more notifications (i.e. one for each enabled NotificationGroup) automatically, based on the NotificationRule, that would be best.

[2000rosser]

@nscuro I opted for adding _TEST to the group in order to get the default pebble format for the notification group, as when using the provided one, it gives errors due to having empty values for the text fields in the json.

Any feedback/ideas on this implementation?

[nscuro]

I opted for adding _TEST to the group in order to get the default pebble format for the notification group, as when using the provided one, it gives errors due to having empty values for the text fields in the json.

Any feedback/ideas on this implementation?

We could alternatively assemble "correct" dummy subjects depending on the group, similar to how we do it in AbstractPublisherTest.

This would avoid the errors you were seeing, and also help with testing custom notification templates.

[nscuro]

Looks great @2000rosser! Do you think you can increase the test coverage a bit?

[2000rosser]

@nscuro Thanks! Yeah np

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ +0.29% (target: -1.00%)	✅ 95.74% (target: 70.00%)

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (c7f3e4c)	22113	16902	76.43%
Head commit (cda16bb)	22207 (+94)	17039 (+137)	76.73% (+0.29%)

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 (#3983)	94	90	95.74%

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}

[nscuro]

Thanks!