From 7b3bd9566520ff5ebe0f0d48146b44e207455824 Mon Sep 17 00:00:00 2001 From: blakeaowens Date: Fri, 30 Oct 2026 18:18:00 -0500 Subject: [PATCH 1/6] docs(tables): describe Watch This View and the Watched Views card Co-Authored-By: Claude Opus 5.5 --- .../configure_personal_notifs.md | 4 +++ .../triage_engine/building_rules.md | 2 ++ .../navigation/PRO__table_customization.md | 26 ++++++++++++++++++- 3 files changed, 31 insertions(+), 1 deletion(-) diff --git a/docs/content/admin/notifications/configure_personal_notifs.md b/docs/content/admin/notifications/configure_personal_notifs.md index 225cf5d9e90..f5967ae94d5 100644 --- a/docs/content/admin/notifications/configure_personal_notifs.md +++ b/docs/content/admin/notifications/configure_personal_notifs.md @@ -21,6 +21,10 @@ System notifications are set by a DefectDojo Superuser and cannot be opted out o Personal Notifications cannot be sent via Microsoft Teams, as Teams only allows for posting Global notifications in a single channel. +### Receive new Findings that match a view (Pro) + +To be told about new Findings that match a filtered Findings list rather than every event of a kind, watch the list instead: the eye button in the list's toolbar sends each scan import's matching new Findings by email or as an in-app alert. See [Watching a view](/navigation/pro__table_customization/#watching-a-view). + ### Receive Personal notifications for a specific Asset In addition to standard personal notifications, DefectDojo Users can also receive notifications for activity on a specific Asset. This is helpful when there are certain Assets which a user needs to monitor more closely. diff --git a/docs/content/automation/triage_engine/building_rules.md b/docs/content/automation/triage_engine/building_rules.md index 762811846ea..39a72d3745a 100644 --- a/docs/content/automation/triage_engine/building_rules.md +++ b/docs/content/automation/triage_engine/building_rules.md @@ -123,6 +123,8 @@ Two things about scope are worth understanding, and both hold for either kind of For an event trigger, scope acts as a second gate: the Findings or Assets named in the event are matched against it, and only those that pass enter the graph. +A rule does not have to start in the editor. The eye button on a Findings list (**Watch This View**, see [Customizing Tables](/navigation/pro__table_customization/#watching-a-view)) creates an **On Finding Event** rule whose scope is the list's filters and whose only action sends new matches to the person who watched it. It is an ordinary rule owned by that person: it appears in the Triage Engine list, and it can be opened, edited or deleted there. Pausing or removing the watch from the User Profile page switches the same rule off or deletes it. + ### Scheduling A rule whose trigger is **On a Schedule** is scheduled from the rule itself. Setting the schedule needs Rule Edit, the same permission as editing the rule, because a schedule-triggered rule does nothing at all until it has one. diff --git a/docs/content/navigation/PRO__table_customization.md b/docs/content/navigation/PRO__table_customization.md index 5e6df7b646d..686d7ec5e39 100644 --- a/docs/content/navigation/PRO__table_customization.md +++ b/docs/content/navigation/PRO__table_customization.md @@ -1,6 +1,6 @@ --- title: "Customizing Tables" -description: "Filter, sort, choose, reorder, resize, and save the columns on DefectDojo Pro data tables, and switch between the table and the grid" +description: "Filter, sort, choose, reorder, resize, and save the columns on DefectDojo Pro data tables, switch between the table and the grid, and watch a findings view for new findings" weight: 8 --- @@ -110,6 +110,30 @@ To switch between preferences, pick one from the list in the preferences menu. S Shared preferences created by other users appear under the **Shared Preferences** tab of the menu. You can load or set a shared preference as your default, but only its creator can change or delete it. +## Watching a view + +On the Findings lists, the eye button in the toolbar (beside the preferences menu) watches the list as it is filtered now: when a scan import adds a finding that matches those filters, DefectDojo sends it to you. A saved preference is a good thing to watch, but any filter works, and a list with no filter watches every new finding you can see. + +Clicking the eye opens **Watch This View**: + +- **Name**: what the watch is called on your User Profile page and in the Triage Engine. It starts as the preference's name. +- **Channel**: **Email** sends to the address on your user profile, over the instance's Email connection (Connect, then Downstream). It is offered only when your user has an email address and an Email connection exists. **In-App Alert** puts an alert in your notification inbox. +- **Cadence**: **Instant** sends after each scan import that adds a matching finding. One import sends one message, listing every matching finding it added. +- **Filters**: the filters the watch carries, read from the list. + +Submitting creates a Triage Engine rule that you own. It runs with your access, so it never reports a finding you could not open yourself, and it sends only to you. Its sends are listed on the Triage Engine's Deliveries page like any rule's. + +The eye is filled when the selected preference already has a watch. A view set to match any filter (see [Matching all filters or any filter](#matching-all-filters-or-any-filter)) cannot be watched; switch it to match all filters first. + +### Managing watches + +Every watch is listed in the **Watched Views** card on the User Profile page, with its preference, channel, cadence and status. Each row's menu offers: + +- **Pause** and **Resume**: turn the watch's rule off or back on. +- **Remove**: delete the watch and its rule. A rule that has already sent something keeps its run history, so instead of being deleted it is switched off and left in the Triage Engine, where it can be deleted. + +Deleting the saved preference a watch was made from does not stop the watch: it keeps the filters it was created with. + ## Global defaults and restricted customization An administrator can pin everyone to a shared table view instead of letting each person keep their own. From f1ac5002f7934c5ae654e4ec3ebf0a3a0d05f090 Mon Sep 17 00:00:00 2001 From: blakeaowens Date: Fri, 30 Oct 2026 23:52:49 -0500 Subject: [PATCH 2/6] docs(tables): correct how a watch is removed and when it sends A watch fires on any new finding, not only a scan import; a removed watch's rule is deleted unless it has sent matches; status follows the rule. Co-Authored-By: Claude Opus 5.5 --- .../notifications/configure_personal_notifs.md | 2 +- .../automation/triage_engine/building_rules.md | 2 +- .../content/navigation/PRO__table_customization.md | 14 +++++++------- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/content/admin/notifications/configure_personal_notifs.md b/docs/content/admin/notifications/configure_personal_notifs.md index f5967ae94d5..d2bdd0470dd 100644 --- a/docs/content/admin/notifications/configure_personal_notifs.md +++ b/docs/content/admin/notifications/configure_personal_notifs.md @@ -23,7 +23,7 @@ Personal Notifications cannot be sent via Microsoft Teams, as Teams only allows ### Receive new Findings that match a view (Pro) -To be told about new Findings that match a filtered Findings list rather than every event of a kind, watch the list instead: the eye button in the list's toolbar sends each scan import's matching new Findings by email or as an in-app alert. See [Watching a view](/navigation/pro__table_customization/#watching-a-view). +To be told about new Findings that match a filtered Findings list rather than every event of a kind, watch the list instead: the eye button in the list's toolbar sends matching new Findings by email or as an in-app alert, however they were added. See [Watching a view](/navigation/pro__table_customization/#watching-a-view). ### Receive Personal notifications for a specific Asset diff --git a/docs/content/automation/triage_engine/building_rules.md b/docs/content/automation/triage_engine/building_rules.md index 39a72d3745a..034f5ecf103 100644 --- a/docs/content/automation/triage_engine/building_rules.md +++ b/docs/content/automation/triage_engine/building_rules.md @@ -123,7 +123,7 @@ Two things about scope are worth understanding, and both hold for either kind of For an event trigger, scope acts as a second gate: the Findings or Assets named in the event are matched against it, and only those that pass enter the graph. -A rule does not have to start in the editor. The eye button on a Findings list (**Watch This View**, see [Customizing Tables](/navigation/pro__table_customization/#watching-a-view)) creates an **On Finding Event** rule whose scope is the list's filters and whose only action sends new matches to the person who watched it. It is an ordinary rule owned by that person: it appears in the Triage Engine list, and it can be opened, edited or deleted there. Pausing or removing the watch from the User Profile page switches the same rule off or deletes it. +A rule does not have to start in the editor. The eye button on a Findings list (**Watch This View**, see [Customizing Tables](/navigation/pro__table_customization/#watching-a-view)) creates an **On Finding Event** rule whose scope is the list's filters and whose only action sends new matches to the person who watched it. It is an ordinary rule owned by that person: it appears in the Triage Engine list and can be opened and edited there, and switching it off there pauses the watch. It runs only when a new Finding matches its scope. Pausing the watch from the User Profile page switches the same rule off, and removing it deletes the rule, or, once the rule has sent matches, switches it off and keeps it with its run history. ### Scheduling diff --git a/docs/content/navigation/PRO__table_customization.md b/docs/content/navigation/PRO__table_customization.md index 686d7ec5e39..5273c2288bd 100644 --- a/docs/content/navigation/PRO__table_customization.md +++ b/docs/content/navigation/PRO__table_customization.md @@ -112,27 +112,27 @@ Shared preferences created by other users appear under the **Shared Preferences* ## Watching a view -On the Findings lists, the eye button in the toolbar (beside the preferences menu) watches the list as it is filtered now: when a scan import adds a finding that matches those filters, DefectDojo sends it to you. A saved preference is a good thing to watch, but any filter works, and a list with no filter watches every new finding you can see. +On the Findings list pages, the eye button in the toolbar (beside the preferences menu) watches the list as it is filtered now: when a new finding matches those filters, however it was added (an import, the API or by hand), DefectDojo sends it to you. A saved preference is a good thing to watch, but any filter works, and a list with no filter watches every new finding you can see. Findings lists shown inside another page, such as a Finding's Similar Findings, have no eye. Clicking the eye opens **Watch This View**: - **Name**: what the watch is called on your User Profile page and in the Triage Engine. It starts as the preference's name. - **Channel**: **Email** sends to the address on your user profile, over the instance's Email connection (Connect, then Downstream). It is offered only when your user has an email address and an Email connection exists. **In-App Alert** puts an alert in your notification inbox. -- **Cadence**: **Instant** sends after each scan import that adds a matching finding. One import sends one message, listing every matching finding it added. -- **Filters**: the filters the watch carries, read from the list. +- **Cadence**: **Instant** sends as soon as new findings match. Findings added together, such as one import's, arrive as one message listing every match. +- **Filters**: the filters the watch carries, named as the list's filter bar names them. Submitting creates a Triage Engine rule that you own. It runs with your access, so it never reports a finding you could not open yourself, and it sends only to you. Its sends are listed on the Triage Engine's Deliveries page like any rule's. -The eye is filled when the selected preference already has a watch. A view set to match any filter (see [Matching all filters or any filter](#matching-all-filters-or-any-filter)) cannot be watched; switch it to match all filters first. +The eye is filled when the selected preference already has a watch. A view set to match any filter (see [Matching all filters or any filter](#matching-all-filters-or-any-filter)) cannot be watched, and the dialog says so as it opens; switch the view to match all filters first. The same filters cannot be watched twice over the same channel. ### Managing watches -Every watch is listed in the **Watched Views** card on the User Profile page, with its preference, channel, cadence and status. Each row's menu offers: +Every watch is listed in the **Watched Views** card on the User Profile page, with its preference, channel, cadence and status. The status reads **Paused** whenever the watch's rule is switched off, whether from this card or in the Triage Engine. Each row's menu offers: - **Pause** and **Resume**: turn the watch's rule off or back on. -- **Remove**: delete the watch and its rule. A rule that has already sent something keeps its run history, so instead of being deleted it is switched off and left in the Triage Engine, where it can be deleted. +- **Remove**: delete the watch and its rule. A watch's rule runs only when a new finding matches it, so a watch that never sent anything goes together with its rule. A rule that has sent matches keeps that run history, as every Triage Engine rule with history does: it is switched off and stays in the Triage Engine list instead of being deleted. -Deleting the saved preference a watch was made from does not stop the watch: it keeps the filters it was created with. +Deleting the saved preference a watch was made from does not stop the watch: it keeps the filters it was created with. Deleting a user removes their watches, and their watch rules the same way **Remove** does. ## Global defaults and restricted customization From a3ef71df0756a31ae1ffec0aa70c37b822f22448 Mon Sep 17 00:00:00 2001 From: blakeaowens Date: Sat, 31 Oct 2026 22:06:11 -0500 Subject: [PATCH 3/6] docs(triage-engine): describe the new-findings notification templates Replaces the Watch This View pages: the feature is now two Triage Engine templates that send new findings matching a set of filters. Co-Authored-By: Claude Opus 5.5 --- .../configure_personal_notifs.md | 4 +-- .../triage_engine/building_rules.md | 12 +++++++-- .../navigation/PRO__table_customization.md | 26 +------------------ 3 files changed, 13 insertions(+), 29 deletions(-) diff --git a/docs/content/admin/notifications/configure_personal_notifs.md b/docs/content/admin/notifications/configure_personal_notifs.md index d2bdd0470dd..98efb351e1a 100644 --- a/docs/content/admin/notifications/configure_personal_notifs.md +++ b/docs/content/admin/notifications/configure_personal_notifs.md @@ -21,9 +21,9 @@ System notifications are set by a DefectDojo Superuser and cannot be opted out o Personal Notifications cannot be sent via Microsoft Teams, as Teams only allows for posting Global notifications in a single channel. -### Receive new Findings that match a view (Pro) +### Receive new Findings that match a set of filters (Pro) -To be told about new Findings that match a filtered Findings list rather than every event of a kind, watch the list instead: the eye button in the list's toolbar sends matching new Findings by email or as an in-app alert, however they were added. See [Watching a view](/navigation/pro__table_customization/#watching-a-view). +To be told about new Findings that match particular filters rather than every event of a kind, adopt one of the **Notifications** templates in the Triage Engine: it sends matching new Findings by email or as an in-app alert. See [Starting a rule](/automation/triage_engine/building_rules/#starting-a-rule). ### Receive Personal notifications for a specific Asset diff --git a/docs/content/automation/triage_engine/building_rules.md b/docs/content/automation/triage_engine/building_rules.md index 034f5ecf103..a36300d1357 100644 --- a/docs/content/automation/triage_engine/building_rules.md +++ b/docs/content/automation/triage_engine/building_rules.md @@ -33,6 +33,16 @@ Templates are starting points, not links. Editing an adopted rule does not affec adopting the same one twice is fine — you get two independent rules, which is how the same watchdog gets pointed at two different sets of Assets. The second one is named with a suffix. +The **Notifications** pack holds two templates for being told about new Findings: **Email new +Findings that match a set of filters** and **Alert on new Findings that match a set of filters**. +Each is an **On Finding Event** trigger on **Created** wired to one notify node. Pick the filters in +the trigger's scope, the same ones the Findings list offers, and the rule sends one message for each +batch of new Findings that match all of them, however the Findings were added. The email version +needs an Email connection with the receiving addresses in its recipients; the alert version takes +usernames, or alerts the administrators when left empty. The subject, body and alert text arrive +pre-filled with the rule's name and the matching Findings, and are edited on the notify node like +any other rule's. + **New Rule** starts from an empty canvas instead. Both need the same permission as authoring any rule, because both create one. @@ -123,8 +133,6 @@ Two things about scope are worth understanding, and both hold for either kind of For an event trigger, scope acts as a second gate: the Findings or Assets named in the event are matched against it, and only those that pass enter the graph. -A rule does not have to start in the editor. The eye button on a Findings list (**Watch This View**, see [Customizing Tables](/navigation/pro__table_customization/#watching-a-view)) creates an **On Finding Event** rule whose scope is the list's filters and whose only action sends new matches to the person who watched it. It is an ordinary rule owned by that person: it appears in the Triage Engine list and can be opened and edited there, and switching it off there pauses the watch. It runs only when a new Finding matches its scope. Pausing the watch from the User Profile page switches the same rule off, and removing it deletes the rule, or, once the rule has sent matches, switches it off and keeps it with its run history. - ### Scheduling A rule whose trigger is **On a Schedule** is scheduled from the rule itself. Setting the schedule needs Rule Edit, the same permission as editing the rule, because a schedule-triggered rule does nothing at all until it has one. diff --git a/docs/content/navigation/PRO__table_customization.md b/docs/content/navigation/PRO__table_customization.md index 5273c2288bd..5e6df7b646d 100644 --- a/docs/content/navigation/PRO__table_customization.md +++ b/docs/content/navigation/PRO__table_customization.md @@ -1,6 +1,6 @@ --- title: "Customizing Tables" -description: "Filter, sort, choose, reorder, resize, and save the columns on DefectDojo Pro data tables, switch between the table and the grid, and watch a findings view for new findings" +description: "Filter, sort, choose, reorder, resize, and save the columns on DefectDojo Pro data tables, and switch between the table and the grid" weight: 8 --- @@ -110,30 +110,6 @@ To switch between preferences, pick one from the list in the preferences menu. S Shared preferences created by other users appear under the **Shared Preferences** tab of the menu. You can load or set a shared preference as your default, but only its creator can change or delete it. -## Watching a view - -On the Findings list pages, the eye button in the toolbar (beside the preferences menu) watches the list as it is filtered now: when a new finding matches those filters, however it was added (an import, the API or by hand), DefectDojo sends it to you. A saved preference is a good thing to watch, but any filter works, and a list with no filter watches every new finding you can see. Findings lists shown inside another page, such as a Finding's Similar Findings, have no eye. - -Clicking the eye opens **Watch This View**: - -- **Name**: what the watch is called on your User Profile page and in the Triage Engine. It starts as the preference's name. -- **Channel**: **Email** sends to the address on your user profile, over the instance's Email connection (Connect, then Downstream). It is offered only when your user has an email address and an Email connection exists. **In-App Alert** puts an alert in your notification inbox. -- **Cadence**: **Instant** sends as soon as new findings match. Findings added together, such as one import's, arrive as one message listing every match. -- **Filters**: the filters the watch carries, named as the list's filter bar names them. - -Submitting creates a Triage Engine rule that you own. It runs with your access, so it never reports a finding you could not open yourself, and it sends only to you. Its sends are listed on the Triage Engine's Deliveries page like any rule's. - -The eye is filled when the selected preference already has a watch. A view set to match any filter (see [Matching all filters or any filter](#matching-all-filters-or-any-filter)) cannot be watched, and the dialog says so as it opens; switch the view to match all filters first. The same filters cannot be watched twice over the same channel. - -### Managing watches - -Every watch is listed in the **Watched Views** card on the User Profile page, with its preference, channel, cadence and status. The status reads **Paused** whenever the watch's rule is switched off, whether from this card or in the Triage Engine. Each row's menu offers: - -- **Pause** and **Resume**: turn the watch's rule off or back on. -- **Remove**: delete the watch and its rule. A watch's rule runs only when a new finding matches it, so a watch that never sent anything goes together with its rule. A rule that has sent matches keeps that run history, as every Triage Engine rule with history does: it is switched off and stays in the Triage Engine list instead of being deleted. - -Deleting the saved preference a watch was made from does not stop the watch: it keeps the filters it was created with. Deleting a user removes their watches, and their watch rules the same way **Remove** does. - ## Global defaults and restricted customization An administrator can pin everyone to a shared table view instead of letting each person keep their own. From bcaf85c4d056c57c277697667f283aafc9769d52 Mon Sep 17 00:00:00 2001 From: blakeaowens Date: Sat, 31 Oct 2026 22:54:15 -0500 Subject: [PATCH 4/6] docs(triage-engine): match the template names, recipients field and batching Co-Authored-By: Claude Opus 5.5 --- .../automation/triage_engine/building_rules.md | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/docs/content/automation/triage_engine/building_rules.md b/docs/content/automation/triage_engine/building_rules.md index a36300d1357..1410c2b6023 100644 --- a/docs/content/automation/triage_engine/building_rules.md +++ b/docs/content/automation/triage_engine/building_rules.md @@ -34,14 +34,19 @@ adopting the same one twice is fine — you get two independent rules, which is gets pointed at two different sets of Assets. The second one is named with a suffix. The **Notifications** pack holds two templates for being told about new Findings: **Email new -Findings that match a set of filters** and **Alert on new Findings that match a set of filters**. +findings that match a set of filters** and **Alert on new findings that match a set of filters**. Each is an **On Finding Event** trigger on **Created** wired to one notify node. Pick the filters in the trigger's scope, the same ones the Findings list offers, and the rule sends one message for each -batch of new Findings that match all of them, however the Findings were added. The email version -needs an Email connection with the receiving addresses in its recipients; the alert version takes -usernames, or alerts the administrators when left empty. The subject, body and alert text arrive -pre-filled with the rule's name and the matching Findings, and are edited on the notify node like -any other rule's. +batch of new Findings that match all of them, however the Findings were added. An import usually +sends one message; a very large one sends one per batch of 500 Findings by default. Every Finding an import +creates counts as new, including one that duplicates a Finding already reported, so importing a +report that was imported before sends its Findings again. + +The messages name the rule, so rename the adopted rule after what it watches. The email version +needs an Email connection on its email node, with the receiving addresses in the **Recipients** +field under the node's **Destination**; the alert version takes usernames, or alerts the +administrators when left empty. The subject, body and alert text arrive pre-filled with the rule's +name and the matching Findings, and are edited on the notify node like any other rule's. **New Rule** starts from an empty canvas instead. Both need the same permission as authoring any rule, because both create one. From 92fde26c6f1d5a2626ca954808a7d4a254b6ddea Mon Sep 17 00:00:00 2001 From: blakeaowens Date: Mon, 2 Nov 2026 04:07:01 -0600 Subject: [PATCH 5/6] docs(triage-engine): describe only the new-findings alert template The email template is dropped from the Pro PR: an email node mails any address its owner types, with no check that the recipient may see the findings. The docs now describe the one in-app alert template. Co-Authored-By: Claude Opus 5.5 --- .../configure_personal_notifs.md | 2 +- .../triage_engine/building_rules.md | 27 +++++++++---------- 2 files changed, 14 insertions(+), 15 deletions(-) diff --git a/docs/content/admin/notifications/configure_personal_notifs.md b/docs/content/admin/notifications/configure_personal_notifs.md index 98efb351e1a..12f00e36d46 100644 --- a/docs/content/admin/notifications/configure_personal_notifs.md +++ b/docs/content/admin/notifications/configure_personal_notifs.md @@ -23,7 +23,7 @@ Personal Notifications cannot be sent via Microsoft Teams, as Teams only allows ### Receive new Findings that match a set of filters (Pro) -To be told about new Findings that match particular filters rather than every event of a kind, adopt one of the **Notifications** templates in the Triage Engine: it sends matching new Findings by email or as an in-app alert. See [Starting a rule](/automation/triage_engine/building_rules/#starting-a-rule). +To be told about new Findings that match particular filters rather than every event of a kind, adopt the **Alert on new findings that match a set of filters** template in the Triage Engine: it sends an in-app alert about the matching new Findings. See [Starting a rule](/automation/triage_engine/building_rules/#starting-a-rule). ### Receive Personal notifications for a specific Asset diff --git a/docs/content/automation/triage_engine/building_rules.md b/docs/content/automation/triage_engine/building_rules.md index 1410c2b6023..3768d4dc6b2 100644 --- a/docs/content/automation/triage_engine/building_rules.md +++ b/docs/content/automation/triage_engine/building_rules.md @@ -33,20 +33,19 @@ Templates are starting points, not links. Editing an adopted rule does not affec adopting the same one twice is fine — you get two independent rules, which is how the same watchdog gets pointed at two different sets of Assets. The second one is named with a suffix. -The **Notifications** pack holds two templates for being told about new Findings: **Email new -findings that match a set of filters** and **Alert on new findings that match a set of filters**. -Each is an **On Finding Event** trigger on **Created** wired to one notify node. Pick the filters in -the trigger's scope, the same ones the Findings list offers, and the rule sends one message for each -batch of new Findings that match all of them, however the Findings were added. An import usually -sends one message; a very large one sends one per batch of 500 Findings by default. Every Finding an import -creates counts as new, including one that duplicates a Finding already reported, so importing a -report that was imported before sends its Findings again. - -The messages name the rule, so rename the adopted rule after what it watches. The email version -needs an Email connection on its email node, with the receiving addresses in the **Recipients** -field under the node's **Destination**; the alert version takes usernames, or alerts the -administrators when left empty. The subject, body and alert text arrive pre-filled with the rule's -name and the matching Findings, and are edited on the notify node like any other rule's. +The **Notifications** pack holds one template for being told about new Findings: **Alert on new +findings that match a set of filters**. It is an **On Finding Event** trigger on **Created** wired to +one in-app alert node. Pick the filters in the trigger's scope, the same ones the Findings list +offers, and the rule sends one alert for each batch of new Findings that match all of them, however +the Findings were added. An import usually sends one alert; a very large one sends one per batch of +500 Findings by default. Every Finding an import creates counts as new, including one that +duplicates a Finding already reported, so importing a report that was imported before sends its +Findings again. + +The alert names the rule, so rename the adopted rule after what it watches. The alert node takes +usernames, or alerts the administrators when left empty. The title and description arrive +pre-filled with the rule's name and the number of matching Findings, and are edited on the node like +any other rule's. The alert goes only to DefectDojo users. **New Rule** starts from an empty canvas instead. Both need the same permission as authoring any rule, because both create one. From afe1cb5f1c3cc183db32a55b4bb1d546b2b1fb08 Mon Sep 17 00:00:00 2001 From: blakeaowens Date: Mon, 2 Nov 2026 06:11:50 -0600 Subject: [PATCH 6/6] docs(triage-engine): name the Duplicate filter and the recipient's alert setting Review findings R1, R2 and R4 on the paired Pro PR: the paragraph says how to leave duplicates out (the Duplicate filter set to No), that the count in each alert is its batch's, and that each recipient's Rules Engine Match notification setting decides whether the alert reaches them. Co-Authored-By: Claude Opus 5.5 --- .../content/automation/triage_engine/building_rules.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/docs/content/automation/triage_engine/building_rules.md b/docs/content/automation/triage_engine/building_rules.md index 3768d4dc6b2..62eb39f4a78 100644 --- a/docs/content/automation/triage_engine/building_rules.md +++ b/docs/content/automation/triage_engine/building_rules.md @@ -38,14 +38,16 @@ findings that match a set of filters**. It is an **On Finding Event** trigger on one in-app alert node. Pick the filters in the trigger's scope, the same ones the Findings list offers, and the rule sends one alert for each batch of new Findings that match all of them, however the Findings were added. An import usually sends one alert; a very large one sends one per batch of -500 Findings by default. Every Finding an import creates counts as new, including one that -duplicates a Finding already reported, so importing a report that was imported before sends its -Findings again. +500 Findings by default, and the count in each alert is that batch's. Every Finding an import +creates counts as new, including one that duplicates a Finding already reported. To leave those out, +add the **Duplicate** filter to the scope, set to **No**. The alert names the rule, so rename the adopted rule after what it watches. The alert node takes usernames, or alerts the administrators when left empty. The title and description arrive pre-filled with the rule's name and the number of matching Findings, and are edited on the node like -any other rule's. The alert goes only to DefectDojo users. +any other rule's. The alert goes only to DefectDojo users, and each recipient's own **Rules Engine +Match** notification setting decides whether it reaches them: a recipient who has turned off alerts +for it gets nothing, though the delivery still reads Sent. **New Rule** starts from an empty canvas instead. Both need the same permission as authoring any rule, because both create one.