feat(notifications): add notification type filtering to email notifications

[manuelgr0]

Description

This PR adds system-level notification type filtering to email notifications, bringing email into alignment with all other notification agents (Telegram, Discord, Slack, Webhook, Gotify, Ntfy, Pushbullet, Pushover).

AI was used to help generate these changes. The changes were reviewed, modified and tested by me after it.

• Fixes Add notification type filtering to email notifications #2691

How Has This Been Tested?

Locally run and tested.

Checklist:

• I have read and followed the contribution guidelines.
• Disclosed any use of AI (see our policy)
• I have updated the documentation accordingly.
• All new and existing tests passed.
• Successful build pnpm build
• Translation keys pnpm i18n:extract
• Database migration (if required)

Summary by CodeRabbit

• New Features

  • Add ability to select and manage which notification types are enabled in email settings.
  • Email processing now respects configured notification types for system-generated notifications.

• Improvements

  • Validation prevents enabling email notifications without selecting at least one notification type.
  • Save and test flows include the selected notification types.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: e847bbf7-ae08-444b-8073-25382dee02e1

📥 Commits

Reviewing files that changed from the base of the PR and between 446fbef and 8b4a385.

📒 Files selected for processing (2)

• server/lib/notifications/agents/email.ts
• src/components/Settings/Notifications/NotificationsEmail.tsx

🚧 Files skipped from review as they are similar to previous changes (2)

• server/lib/notifications/agents/email.ts
• src/components/Settings/Notifications/NotificationsEmail.tsx

---

📝 Walkthrough

Walkthrough

Email notifications now respect system-level notification type settings. The backend email agent checks configured types before sending when payload.notifySystem is true. The frontend settings UI adds a types selector, persists types with saves/tests, and validates selection when email notifications are enabled.

Changes

Cohort / File(s)	Summary
Backend Email Agent server/lib/notifications/agents/email.ts	Import hasNotificationType; call this.getSettings() and, when payload.notifySystem is true, short-circuit and return success if the notification type is not enabled in settings.types.
Frontend Email Settings src/components/Settings/Notifications/NotificationsEmail.tsx	Add NotificationTypeSelector wired to Formik (setFieldValue, setFieldTouched); include types in initialValues, save and test API payloads; add validation/error and disable submit when enabled but no types selected.

Sequence Diagram

sequenceDiagram
    actor Admin
    participant UI as "Email Settings UI"
    participant Form as "Formik Form"
    participant API as "Settings API"
    participant EmailAgent as "Email Agent"
    participant Store as "Config Store"

    Admin->>UI: Open email settings
    UI->>Form: Render values (including types)
    Admin->>Form: Select types & enable email
    Form->>Form: Validate (types required if enabled)
    Admin->>UI: Save
    Form->>API: POST `/api/v1/settings/notifications/email` with types
    API->>Store: Persist settings

    Note over EmailAgent,Store: Later, on notification trigger
    EmailAgent->>Store: getSettings()
    EmailAgent->>EmailAgent: If payload.notifySystem == true
    EmailAgent->>EmailAgent: hasNotificationType(settings.types, type)?
    alt type enabled
        EmailAgent->>EmailAgent: Proceed to send email
    else type disabled
        EmailAgent->>EmailAgent: Return early (skip sending)
    end

Loading

Estimated Code Review Effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Poem

🐰 I sniffed the settings, hopped in line,
Picked only types that felt just fine,
Now emails land with measured cheer,
No more noise — the inbox clear! ✉️🌿

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: adding notification type filtering to email notifications, which is the primary objective of the PR.
Linked Issues check	✅ Passed	The PR successfully implements all coding requirements from #2691: adds NotificationTypeSelector to email settings UI, implements system-level type filtering in the email agent, maintains backward compatibility via notifySystem gate, and makes no API/schema changes.
Out of Scope Changes check	✅ Passed	All changes are directly related to issue #2691 objectives: notification type selection UI and agent-side filtering logic. No unrelated modifications detected.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@server/lib/notifications/agents/email.ts`:
- Around line 209-213: The condition in email notification gating uses
hasNotificationType with its arguments reversed, breaking the (types, value)
contract and disabling the "types === 0" allow-all path; update the call in the
block that checks payload.notifySystem to call
hasNotificationType(settings.types ?? 0, type) instead of
hasNotificationType(type, settings.types ?? 0) so existing installs with
settings.types unset/0 will allow system notifications as intended; keep the
rest of the condition (payload.notifySystem and return true) unchanged.

In `@src/components/Settings/Notifications/NotificationsEmail.tsx`:
- Around line 131-135: The form treats a types value of 0 (legacy "send all") as
falsy and marks existing configs invalid; update the NotificationsEmail form
initialValues to preserve the legacy state by using data.types when present or 0
otherwise (set types to data.types ?? 0) and change the validation/checks that
currently use "!values.types" (in the submit/validation logic around the
handlers referenced) to only treat undefined/null as missing (e.g., use
values.types == null or values.types === undefined) so that a numeric 0 bitmask
is accepted; reference NotificationTypeSelector and its hasNotificationType
helper when making these changes.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 2cf3ac61-dd6f-4b0b-87f2-ce1b5faf6668

📥 Commits

Reviewing files that changed from the base of the PR and between f40323c and 446fbef.

📒 Files selected for processing (2)

• server/lib/notifications/agents/email.ts
• src/components/Settings/Notifications/NotificationsEmail.tsx

[Copilot]

Pull request overview

Adds system-level notification type filtering support to the Email notification agent and exposes notification type selection in the Email notification settings UI, aligning Email with other notification agents.

Changes:

• Add NotificationTypeSelector to the Email notification settings and persist types on save/test.
• Add server-side email agent filtering so system notifications only send when the notification type is enabled.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/components/Settings/Notifications/NotificationsEmail.tsx	Adds notification type selection UI for Email and includes types in save/test requests.
server/lib/notifications/agents/email.ts	Adds system-level notification type filtering to the Email agent.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

hasNotificationType is being called with arguments reversed (hasNotificationType(settings.types ?? 0, type)). This breaks the helper’s intended behavior of always allowing TEST_NOTIFICATION: once settings.types is non-zero (i.e., after the admin selects types in the UI), test emails will be filtered out because the function will end up checking (Notification.TEST_NOTIFICATION & settings.types).

Suggested fix: call it consistently with other agents (hasNotificationType(type, settings.types ?? 0)) and, to preserve backward compatibility for existing installs where email.types is unset, only apply filtering when settings.types is explicitly defined (e.g., skip the filter when settings.types == null).

Suggested change

	// Skip sending if this is a system notification and the type is not enabled
	if (
	payload.notifySystem &&
	!hasNotificationType(settings.types ?? 0, type)
	// Skip sending if this is a system notification and the type is not enabled.
	// If settings.types is unset, preserve legacy behavior and do not filter.
	if (
	payload.notifySystem &&
	settings.types != null &&
	!hasNotificationType(type, settings.types)