feat: prevent notifications for scheduled backups

[apple050620312]

Closes #2343

What does this PR do?

This PR resolves an issue where scheduled backups generate notifications via the UI and email upon completion. For servers with frequent automated backups, this causes notification spam.

This change ensures that notifications are suppressed for successful automated backups. If an automated backup fails, the administrator will still be notified to ensure visibility into backup failures. Manual backups remain unaffected and will generate notifications as usual.

Implementation Details

• Created a database migration to add an is_automated boolean column (defaulting to false) to the backups table to track the source of the backup.
• Updated the Backup model to handle the new is_automated property.
• Modified InitiateBackupService::handle() to accept and save an $isAutomated parameter.
• Updated CreateBackupSchema::runTask() (the scheduler) to pass true for $isAutomated when initiating a backup.
• Updated BackupCompletedListener::handle() to abort and skip sending Filament UI and email notifications if $event->backup->is_automated and $event->backup->is_successful are both true.

How to Test

1. Set up a backup schedule for a server and wait for it to trigger, or manually mock the schedule execution in the background.
2. Verify that the backup completes successfully without generating a UI notification or sending an email.
3. Manually trigger a backup via the UI or API and verify that you still receive the "Backup completed" notification.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: d94880ec-04d4-4473-9148-57f9f8da9256

📥 Commits

Reviewing files that changed from the base of the PR and between b8bbf29 and 655dd85.

📒 Files selected for processing (5)

• app/Extensions/Tasks/Schemas/CreateBackupSchema.php
• app/Listeners/Server/BackupCompletedListener.php
• app/Models/Backup.php
• app/Services/Backups/InitiateBackupService.php
• database/migrations/2026_07_08_122500_add_is_automated_to_backups_table.php

---

📝 Walkthrough

Walkthrough

Introduces an is_automated boolean field for backups via migration and model updates, threads a new isAutomated parameter through InitiateBackupService::handle, updates CreateBackupSchema to invoke it with the flag set, and adds an early-return guard in BackupCompletedListener to skip notifications for successful automated backups.

Changes

Automated backup flag and notification skip

Layer / File(s)	Summary
Backup model and migration for is_automated database/migrations/2026_07_08_122500_add_is_automated_to_backups_table.php, app/Models/Backup.php	Adds an is_automated boolean column (default false) to the backups table, and updates the Backup model's PHPDoc, default attributes, validation rules, and casts to include is_automated.
Persist automation flag through backup creation app/Services/Backups/InitiateBackupService.php, app/Extensions/Tasks/Schemas/CreateBackupSchema.php	InitiateBackupService::handle gains an $isAutomated parameter (default false) that is stored on the created Backup, and CreateBackupSchema::runTask now calls handle with the flag set to true.
Skip notification for automated successful backups app/Listeners/Server/BackupCompletedListener.php	handle() returns early when a backup is both automated and successful, skipping missing-data loading and notification dispatch.

Sequence Diagram(s)

sequenceDiagram
    participant CreateBackupSchema
    participant InitiateBackupService
    participant Backup
    participant BackupCompletedListener

    CreateBackupSchema->>InitiateBackupService: handle(server, name, override, true, true)
    InitiateBackupService->>Backup: create(is_automated: true)
    Backup-->>BackupCompletedListener: backup completed event
    alt automated and successful
        BackupCompletedListener->>BackupCompletedListener: return early (skip notification)
    else otherwise
        BackupCompletedListener->>BackupCompletedListener: load data and send notification
    end

Loading

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: suppressing notifications for scheduled backups.
Description check	✅ Passed	The description matches the changes and explains the notification suppression behavior.
Linked Issues check	✅ Passed	The PR addresses #2343 by suppressing notifications for automated successful backups while leaving manual backups intact.
Out of Scope Changes check	✅ Passed	All changes support automated-backup tracking and notification suppression; no unrelated edits are evident.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

---

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.}

[lancepioch]

You can already set PANEL_SEND_BACKUP_COMPLETED_NOTIFICATION to false in your config/env.

I think it's completely acceptable for somebody to want to be emailed when their backups finish successfully.

[Boy132]

You can already set PANEL_SEND_BACKUP_COMPLETED_NOTIFICATION to false in your config/env.

I think it's completely acceptable for somebody to want to be emailed when their backups finish successfully.

I highly disagree, see the attached issue of this PR.
You will get spammed with notifications if you have schedules that create backups.

[NanoTrasen-Inc]

Thank you for reopening this. I was a bit frustrated I wasn't allowed the ability to voice my concerns with this.

I have a large number of servers and they each have backups scheduled every hour, at various times within the hour. This caused me to get 2-3 emails every 5 minutes on average.

I came back to my desk after a a long break to see hundreds of success emails. And I thought to myself... "This can't possibly be the intended experience. There's no way anyone would possibly want this many emails." Nevertheless, apparently it was.

I personally feel that scheduled backups should NOT email the user if they were successful. The only time a user should receive a success message is if they initiated the action directly.