feat(notifications): added a custom notify email field, managed account now get mail

[JackW6809]

Description

I manage all my Plex Users accounts, I have my own domain that I make the users accounts from on Plex. However this means that because the accounts are synced into Seerr from Plex the email field is pre-filled and non-changeable users do not receive updates on their requests.

I did not use AI to create or help me with this PR

How Has This Been Tested?

I added the changes and in the UI I sent a test e-mail notification with no custom notification and the synced original email receives the test email no problem. Then setting the custom notify e-mail and sending another test notification it then sends to the custom notify e-mail.

Additionally, I have ensured the e-mail persists on service restarts and page refreshes. E-mail validation is also required on that field if it has some text in it.

The environment is a x64 system, running the DB from SQLite3. All generated from Develop branch and tested the database migration using the guidance in Section 4.

Screenshots / Logs (if applicable)

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
  • Optional “custom notification email” allowing a separate address for notifications (falls back to account email).
• User Interface
  • Setting exposed across all notification preference forms with validation and explanatory tip.
• Notifications
  • Emails and chat notifications may include a “Play on [Media Server]” action when available; notifications use the custom email when provided.
• Localization
  • Added translation keys and validation messages for the new field.

[JackW6809]

All new and existing tests passed.

Is that the GH Actions? Thanks :)

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

Adds an optional notifyEmail field across API schema, DB entity and migrations, backend routes and email/notification agents, and frontend notification forms/validation; notification sending now prefers notifyEmail over the account email when present.

Changes

Cohort / File(s)	Summary
API Schema & Interfaces seerr-api.yml, server/interfaces/api/userSettingsInterfaces.ts	Add optional notifyEmail (nullable, format: email) to UserSettingsNotifications schema and response interface.
Database Entity & Migrations server/entity/UserSettings.ts, server/migration/postgres/1769971931384-CustomNotifyEmailMigration.ts, server/migration/sqlite/1769971922216-CustomNotifyEmailMigration.ts	Add notifyEmail column/property to UserSettings entity and provide Postgres/SQLite migrations to add/remove and migrate the column (large SQLite migration).
Backend Routes & Notification Agents server/routes/user/usersettings.ts, server/lib/notifications/agents/email.ts, server/lib/notifications/agents/slack.ts, server/lib/notifications/agents/telegram.ts	Persist and return notifyEmail via GET/POST; notification agents derive `userEmail = settings?.notifyEmail
Frontend Notification Forms & Validation src/components/UserProfile/UserSettings/UserNotificationSettings/... UserNotificationsDiscord.tsx, UserNotificationsEmail.tsx, UserNotificationsPushbullet.tsx, UserNotificationsPushover.tsx, UserNotificationsTelegram.tsx, UserNotificationsWebPush/index.tsx	Include notifyEmail in form initial values and submission payloads; Email settings UI adds an input, i18n keys, and validation for notifyEmail.
Templates & Translations server/templates/email/media-request/html.pug, src/i18n/locale/en.json	Email template optionally renders a "Play on {mediaServerName}" link when media server URL present; add i18n keys notifyEmail, notifyEmailTip, and validationEmail.

Sequence Diagram(s)

sequenceDiagram
    participant User as User
    participant Frontend as Frontend
    participant API as API
    participant DB as Database
    participant EmailAgent as EmailAgent
    participant Provider as EmailProvider

    User->>Frontend: View notification settings
    Frontend->>API: GET /api/v1/user/:id/settings/notifications
    API->>DB: SELECT user_settings
    DB-->>API: user_settings (includes notifyEmail)
    API-->>Frontend: Return settings
    User->>Frontend: Submit updated settings (includes notifyEmail)
    Frontend->>API: POST /api/v1/user/:id/settings/notifications { notifyEmail, ... }
    API->>DB: INSERT/UPDATE user_settings.notifyEmail
    DB-->>API: OK
    Note over API,EmailAgent: Sending notification flow
    API->>EmailAgent: sendNotification(payload, user, settings)
    EmailAgent->>EmailAgent: userEmail = settings?.notifyEmail || user.email
    EmailAgent->>EmailAgent: validate(userEmail)
    EmailAgent->>Provider: send email to userEmail
    Provider-->>EmailAgent: delivery result
    EmailAgent-->>API: report result

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Poem

🐰 A tiny hop for settings new,
I tuck a mail where pings come through,
From form to DB and outbound flight,
My whiskers twitch at every light,
Hooray — a threaded hop of blue!

🚥 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 PR title accurately describes the main feature: adding a custom notify email field for managed accounts. It clearly conveys the primary change without being vague or misleading.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Merge Conflict Detection	✅ Passed	✅ No merge conflicts detected when merging into develop

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

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

No actionable comments were generated in the recent review. 🎉

🧹 Recent nitpick comments

server/lib/notifications/agents/slack.ts (1)

71-89: Extract shared helpers to reduce duplication and improve type safety.

These two helper functions (getAvailableMediaServerName and getAvailableMediaServerUrl) are duplicated nearly verbatim in telegram.ts. Consider extracting them to a shared utility module (e.g., server/lib/notifications/utils.ts).

Additionally, using (payload.media as any) bypasses type checking. If mediaUrl and mediaUrl4k are valid properties on the media type, consider properly typing them; otherwise, a type guard or dedicated interface would be safer.

♻️ Proposed shared utility

Create a new file server/lib/notifications/mediaServerUtils.ts:

import { MediaServerType } from '@server/constants/server';

export function getMediaServerName(mediaServerType: MediaServerType): string {
  switch (mediaServerType) {
    case MediaServerType.EMBY:
      return 'Emby';
    case MediaServerType.PLEX:
      return 'Plex';
    default:
      return 'Jellyfin';
  }
}

export function getMediaServerUrl(
  media: { mediaUrl?: string; mediaUrl4k?: string } | undefined,
  wants4k?: boolean
): string | undefined {
  const url4k = media?.mediaUrl4k;
  const url = media?.mediaUrl;
  return (wants4k ? (url4k ?? url) : (url ?? url4k)) || undefined;
}

Then import and use in both slack.ts and telegram.ts.

---

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

[coderabbitai]

Actionable comments posted: 2

🤖 Fix all issues with AI agents

In `@server/migration/sqlite/1769971922216-CustomNotifyEmailMigration.ts`:
- Around line 6-172: The migration's up() method (class
1769971922216-CustomNotifyEmailMigration) was auto-generated and needlessly
recreates many tables and duplicates user_push_subscription; instead, change
up() to only add the notifyEmail column to user_settings (use ALTER TABLE
"user_settings" ADD COLUMN "notifyEmail" varchar) and remove all temporary_*
table creation/inserts/renames and the duplicated
temporary_user_push_subscription blocks (references: up(),
"temporary_user_settings", "temporary_user_push_subscription", "user_settings",
"user_push_subscription"); also avoid changing datetime default expressions
(leave existing datetime('now') usage intact) so the migration only performs the
single schema change and keeps the down() reverse logic consistent.

In `@src/i18n/locale/en.json`:
- Around line 1476-1477: The JSON i18n tip string for
components.UserProfile.UserSettings.UserNotificationSettings.notifyEmailTip
mixes pronouns and mis-capitalizes "Email": update the value to use a consistent
pronoun and lowercase "email" (e.g., change "Email address to send notifications
to if you don't want to send notifications to their login Email" to something
like "Email address to send notifications to if you don't want to use the
account login email"), ensuring you edit the notifyEmailTip key (and leave
notifyEmail key unchanged).

🧹 Nitpick comments (2)

seerr-api.yml (1)

1942-1944: Add format: email for better schema validation.

This improves tooling and client-side validation without changing behavior.

♻️ Suggested schema tweak

         notifyEmail:
           type: string
+          format: email
           nullable: true

server/lib/notifications/agents/email.ts (1)

223-234: Use the already-computed userEmail variable instead of duplicating the expression.

The userEmail variable is computed at lines 223-225 but not used in the buildMessage call. The same expression is repeated at lines 231-232.

♻️ Proposed fix

           const userEmail =
             payload.notifyUser.settings?.notifyEmail ||
             payload.notifyUser.email;
           if (validator.isEmail(userEmail, { require_tld: false })) {
             await email.send(
               this.buildMessage(
                 type,
                 payload,
-                payload.notifyUser.settings?.notifyEmail ||
-                  payload.notifyUser.email,
+                userEmail,
                 payload.notifyUser.displayName
               )
             );

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check recent SQLite migrations and identify the file structure
fd -e ts . server/migration/sqlite --exec basename {} \; | sort | tail -10
echo "---"
# Get line count to understand scope
wc -l server/migration/sqlite/1769971922216-CustomNotifyEmailMigration.ts

Repository: seerr-team/seerr

Length of output: 539

---

🏁 Script executed:

#!/bin/bash
# Read the full migration file to verify the claims
cat -n server/migration/sqlite/1769971922216-CustomNotifyEmailMigration.ts | head -200

Repository: seerr-team/seerr

Length of output: 24159

---

🏁 Script executed:

#!/bin/bash
# Check the down() method to assess rollback complexity
cat -n server/migration/sqlite/1769971922216-CustomNotifyEmailMigration.ts | tail -100

Repository: seerr-team/seerr

Length of output: 12700

---

Migration scope extends well beyond the notifyEmail feature and contains redundant operations.

This migration recreates 12 tables (user_push_subscription, user_settings, watchlist, issue_comment, issue, override_rule, season_request, media_request, user, blacklist, season, media, discover_slider) when only the notifyEmail column addition to user_settings is the actual feature change. The extensive table recreation increases execution time and failure risk.

Additionally, user_push_subscription is recreated three times within the up() method: first at lines 8–17, again identically at lines 90–98 (redundant), and finally at lines 162–171 with the unique constraint. These duplicate operations suggest the migration was auto-generated by TypeORM synchronization without cleanup.

Datetime defaults are also systematically changed from datetime('now') to CURRENT_TIMESTAMP across multiple tables, though the down() method properly restores the original format, ensuring reversibility.

The down() method is comprehensive and reverses all operations, mitigating rollback risk. However, test both up() and down() paths thoroughly before production deployment, particularly with existing user data.

🤖 Prompt for AI Agents

In `@server/migration/sqlite/1769971922216-CustomNotifyEmailMigration.ts` around
lines 6 - 172, The migration's up() method (class
1769971922216-CustomNotifyEmailMigration) was auto-generated and needlessly
recreates many tables and duplicates user_push_subscription; instead, change
up() to only add the notifyEmail column to user_settings (use ALTER TABLE
"user_settings" ADD COLUMN "notifyEmail" varchar) and remove all temporary_*
table creation/inserts/renames and the duplicated
temporary_user_push_subscription blocks (references: up(),
"temporary_user_settings", "temporary_user_push_subscription", "user_settings",
"user_push_subscription"); also avoid changing datetime default expressions
(leave existing datetime('now') usage intact) so the migration only performs the
single schema change and keeps the down() reverse logic consistent.

[JackW6809]

This is an automated script that is generated - I think this can be safely ignored

[coderabbitai]

@JackW6809, you're correct that TypeORM auto-generates these migrations. However, auto-generated migrations often include unintended schema changes or redundant operations, especially when the ORM detects drift between entity definitions and the database state.

In this case, the migration recreates 12 tables and repeats the user_push_subscription table creation three times within the same up() method (lines 8-17, 90-98, and 162-171), when only adding the notifyEmail column to user_settings is actually necessary for this feature. This increases migration execution time and the risk of issues during deployment or rollback.

While it's ultimately your call as the maintainer, manually refining the migration to a single ALTER TABLE "user_settings" ADD COLUMN "notifyEmail" varchar statement would make it safer and faster. The comprehensive down() method you have is excellent for reversibility.

If you've tested both directions with production-like data and are confident in the current approach, I'll defer to your judgment.

[JackW6809]

I think I will leave this down to the repo maintainers to decide on not me.

[coderabbitai]

@JackW6809, that's perfectly reasonable—thank you for clarifying! Since you're contributing this PR and the maintainers will make the final call on the migration approach, I'll leave this discussion thread open for them to review when they get to it.

Appreciate your work on this feature! 🐰