Accept all notification rule fields on creation by volodymyr-jdev · Pull Request #7627 · DependencyTrack/dependency-track

volodymyr-jdev · 2026-10-08T12:59:39Z

Description

Allow PUT /api/v1/notification/rule and PUT /api/v1/notification/rule/scheduled to accept all rule fields, so a usable notification rule can be created in a single request.

Previously, both endpoints only accepted name, scope, notificationLevel and publisher. All other fields, such as notifyOn and publisherConfig, were silently dropped, so clients had to follow up with a POST. Both endpoints now also accept enabled, notifyChildren, logSuccessfulPublish, notifyOn, publisherConfig, filterExpression and tags. The scheduled endpoint additionally accepts scheduleCron and scheduleSkipUnchanged. All fields are validated the same way as on update and applied in the same transaction. Omitted fields keep their previous defaults, so existing clients are unaffected.

Addressed Issue

Closes #2940

Additional Details

Implementation

CreateNotificationRuleRequest and CreateScheduledNotificationRuleRequest gain the optional fields above. Boolean fields use wrapper types, so an omitted field can be told apart from false.
NotificationQueryManager#createNotificationRule(NotificationRule) creates a rule from a transient NotificationRule and handles both trigger types: the trigger type decides which notification groups are allowed and whether the schedule fields are applied. The existing four-argument create methods delegate to it.
Since NotificationRule uses primitive booleans, defaults for omitted fields are applied in the resource, separately for event and scheduled rules.
Validation of notifyOn against the trigger type (validateNotifyOn) and of the publisher config (validatePublisherConfig) is shared between create and update. validateNotifyOn treats a missing notifyOn as an empty set.
If publisherConfig is omitted on creation, the publisher's default config is used, as before. Providing one for a publisher that does not support it is rejected.

Behavior change

Clients that previously sent invalid filterExpression, publisherConfig, notifyOn or scheduleCron values to either create endpoint received 201 with those values discarded. They now receive 400 and no rule is created.
Updating a rule via POST /api/v1/notification/rule without notifyOn previously failed with 500 due to a NullPointerException. An omitted notifyOn is now treated as an empty set, consistent with rule creation, so the rule's subscriptions are cleared.

Out of scope

Projects and teams are still not accepted on creation and must be added via the existing endpoints.

Testing

Added tests to NotificationRuleResourceTest. Existing tests pass unchanged.
Ran the full apiserver test suite locally.
Verified manually in dev mode (make apiserver-dev):
- Event and scheduled rule creation with all optional fields in a single request
- Event and scheduled rule creation with only the four previously supported fields
- Completing a rule via a follow-up POST
- Rejection of invalid input for both rule types with no rule being created
- Updating event and scheduled rules without notifyOn
- Viewing and editing created rules in the frontend

The documentation checklist item is left unchecked, as it is unclear whether this change requires an update to the documentation repository. I can provide one if needed.

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 updated the migration changelog accordingly~~
This PR introduces new or alters existing behavior, and I have updated the documentation accordingly
~~This PR is a substantial change (per the ADR criteria), and I have added an ADR under docs/adr/~~

codacy-production · 2026-10-08T13:00:38Z

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics -9 complexity

Metric Results

Complexity -9

View in Codacy

🟢 Coverage 98.40% diff coverage · +0.11% coverage variation

Metric Results

Coverage variation ✅ +0.11% coverage variation (-1.00%)

Diff coverage ✅ 98.40% diff coverage (70.00%)

View coverage diff in Codacy

Coverage variation details

Coverable lines Covered lines Coverage

Common ancestor commit (e1e3c8f) 45958 40366 87.83%

Head commit (a23856d) 46019 (+61) 40468 (+102) 87.94% (+0.11%)

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 (#7627) 125 123 98.40%

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%

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer}
_{TIP This summary will be updated as you push new changes.}

nscuro

PUT /api/v1/notification/rule/scheduled has the same issue: it only accepts name, scope, notificationLevel and publisher, so notifyOn, publisherConfig and scheduleCron still require a subsequent POST. It is intentionally left unchanged to keep this PR focused. If the same change is desired there, it can be tracked in a separate issue.

Please do it in this PR, so the API surface remains consistent.

nscuro · 2026-10-15T19:03:45Z

+     * @param command the rule to create
+     * @return the created {@link NotificationRule}
+     * @throws IllegalArgumentException when {@code notifyOn} contains groups not supported for event-triggered rules
+     * @since 5.2.0


Suggested change

* @since 5.2.0

* @since 5.3.0

nscuro · 2026-10-15T19:07:02Z

+ * @param tags                 Tags to limit the rule to, or {@code null} for none
+ * @since 5.2.0
+ */
+public record CreateNotificationRuleCommand(


This is probably overkill here, since there are no fields that NotificationRule doesn't have. You could simply construct a transient NotificationRule object instead.

Done, createNotificationRule now takes a transient NotificationRule. Since it uses primitive booleans, defaults for omitted fields are applied in the resource.

Creating a notification rule via PUT /api/v1/notification/rule or PUT /api/v1/notification/rule/scheduled only accepted name, scope, level and publisher. All other fields, such as notifyOn and publisherConfig, were silently dropped, so clients had to issue a follow-up POST to get a usable rule. Both endpoints now accept the optional fields enabled, notifyChildren, logSuccessfulPublish, notifyOn, publisherConfig, filterExpression and tags, and the scheduled endpoint also accepts scheduleCron and scheduleSkipUnchanged. They are validated the same way as on update and applied in a single transaction. Invalid input yields 400 and no rule is persisted. Omitted fields keep their previous defaults, so existing clients are unaffected. Updating a rule without notifyOn previously failed with a NullPointerException. An omitted notifyOn is now treated as an empty set, consistent with rule creation. Projects and teams are still not accepted on creation and must be added via the existing endpoints. Fixes DependencyTrack#2940 Signed-off-by: Volodymyr Kucheriaviy <248452481+volodymyr-jdev@users.noreply.github.com>

volodymyr-jdev · 2026-10-27T18:20:46Z

Thanks for the review. Scheduled rules are now handled in this PR as well: PUT /api/v1/notification/rule/scheduled accepts the same optional fields, plus scheduleCron and scheduleSkipUnchanged.

While working on this, I found that updating a rule without notifyOn failed with 500 (NullPointerException in NotificationQueryManager#updateNotificationRule). A missing notifyOn is now treated as an empty set, consistent with creation, and covered by tests. I can move this into a separate PR if you prefer.

Description updated.

volodymyr-jdev mentioned this pull request Oct 8, 2026

Allow PUT /v1/notification/rule to supply notifyOn and publisherConfig parameters #2940

Open

2 tasks done

nscuro requested changes Oct 15, 2026

View reviewed changes

volodymyr-jdev force-pushed the issue-2940-create-notification-rule branch from 7bc3b9a to a23856d Compare October 27, 2026 17:38

volodymyr-jdev requested a review from nscuro October 27, 2026 18:22

Navigation Menu

Repository navigation

Accept all notification rule fields on creation - #7627

Accept all notification rule fields on creation#7627
volodymyr-jdev wants to merge 1 commit into
DependencyTrack:mainfrom
volodymyr-jdev:issue-2940-create-notification-rule

volodymyr-jdev commented Oct 8, 2026 •

edited

Loading

Uh oh!

codacy-production Bot commented Oct 8, 2026 •

edited

Loading

Uh oh!

nscuro left a comment

Uh oh!

nscuro Oct 15, 2026

Uh oh!

volodymyr-jdev Oct 27, 2026

Uh oh!

nscuro Oct 15, 2026

Uh oh!

volodymyr-jdev Oct 27, 2026

Uh oh!

volodymyr-jdev commented Oct 27, 2026

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

volodymyr-jdev commented Oct 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Addressed Issue

Additional Details

Checklist

Uh oh!

codacy-production Bot commented Oct 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Up to standards ✅

Uh oh!

nscuro left a comment

Choose a reason for hiding this comment

Uh oh!

nscuro Oct 15, 2026

Choose a reason for hiding this comment

Uh oh!

volodymyr-jdev Oct 27, 2026

Choose a reason for hiding this comment

Uh oh!

nscuro Oct 15, 2026

Choose a reason for hiding this comment

Uh oh!

volodymyr-jdev Oct 27, 2026

Choose a reason for hiding this comment

Uh oh!

volodymyr-jdev commented Oct 27, 2026

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

volodymyr-jdev commented Oct 8, 2026 •

edited

Loading

codacy-production Bot commented Oct 8, 2026 •

edited

Loading