MokoConsulting/MokoJoomBackup
1
0
Fork 0
Code Issues 22 Pull Requests 1 Packages Projects Releases 1 Wiki Activity

Feature: email notifications on backup success/failure #14

New Issue
Open
opened 2026-06-02 20:29:28 +00:00 by jmiller · 1 comment
jmiller commented 2026-06-02 20:29:28 +00:00
Owner
Copy Link
Copy Source

Send email notifications when backups complete or fail.

Description

Admins need to know when scheduled backups fail, especially for unattended cron-based backups. Add configurable email notifications to the system plugin.

Requirements

  • Email on backup failure (always)
  • Email on backup success (optional)
  • Configurable recipient email(s)
  • Use Joomla's built-in mail system (Factory::getMailer())
  • Email includes: backup name, status, size, duration, log excerpt
  • Per-profile notification toggle

Implementation Notes

  • Add to plg_system_mokobackup or create an onAfterBackup event
  • Fields: notify_email, notify_on_success, notify_on_failure
Send email notifications when backups complete or fail. ## Description Admins need to know when scheduled backups fail, especially for unattended cron-based backups. Add configurable email notifications to the system plugin. ## Requirements - [ ] Email on backup failure (always) - [ ] Email on backup success (optional) - [ ] Configurable recipient email(s) - [ ] Use Joomla's built-in mail system (Factory::getMailer()) - [ ] Email includes: backup name, status, size, duration, log excerpt - [ ] Per-profile notification toggle ## Implementation Notes - Add to plg_system_mokobackup or create an onAfterBackup event - Fields: notify_email, notify_on_success, notify_on_failure
jmiller added the type: featurepriority: highcomponent: enginestatus: ready labels 2026-06-02 20:29:28 +00:00
jmiller commented 2026-06-02 20:29:28 +00:00
Author
Owner
Copy Link
Copy Source

Testing Plan

TC-F1.1: Failure notification

  1. Configure notification email in profile
  2. Trigger a backup that will fail (bad backup_dir)
  3. Verify email sent to configured address
  4. Verify email contains error details and log

TC-F1.2: Success notification

  1. Enable notify_on_success
  2. Run successful backup
  3. Verify email sent with backup details (name, size, duration)

TC-F1.3: Disabled notifications

  1. Disable notifications
  2. Run backup (success and failure)
  3. Verify NO emails sent

TC-F1.4: Multiple recipients

  1. Enter multiple emails (comma-separated)
  2. Run backup
  3. Verify all recipients receive email
## Testing Plan **TC-F1.1: Failure notification** 1. Configure notification email in profile 2. Trigger a backup that will fail (bad backup_dir) 3. Verify email sent to configured address 4. Verify email contains error details and log **TC-F1.2: Success notification** 1. Enable notify_on_success 2. Run successful backup 3. Verify email sent with backup details (name, size, duration) **TC-F1.3: Disabled notifications** 1. Disable notifications 2. Run backup (success and failure) 3. Verify NO emails sent **TC-F1.4: Multiple recipients** 1. Enter multiple emails (comma-separated) 2. Run backup 3. Verify all recipients receive email
Sign in to join this conversation.
Labels
Clear labels
component: admin
Admin UI and views
 component: api
REST API
 component: engine
Backup/restore engine
 component: remote
Remote storage (FTP/GDrive)
 component: scheduler
Scheduled tasks
 priority: critical
Must fix before release
 priority: high
Important for release
 priority: low
Nice to have
 priority: medium
Normal priority
 status: blocked
Blocked by dependency
 status: ready
Ready for development
 type: bug
Something is broken
 type: docs
Documentation
 type: feature
New feature or enhancement
 type: testing
Testing and QA
bug
Something is not working
 chore
Maintenance and housekeeping
 documentation
Documentation improvements
 enhancement
Improvement to existing functionality
 feature
New feature or request
 pending: dependency
Blocked by another issue or external dependency
 pending: deployment
Tested and approved, awaiting deployment to production
 pending: design
Needs UI/UX or architecture design before implementation
 pending: documentation
Feature works, needs documentation/wiki update
 pending: feedback
Awaiting feedback or decision from stakeholder
 pending: review
Implementation complete, awaiting code review
 pending: testing
Feature implemented but not yet tested
 priority: critical
Must fix immediately
 priority: high
Should fix soon
 priority: low
Nice to have
 priority: medium
Fix when convenient
 refactor
Code restructuring without behavior change
 roadmap
Planned feature or enhancement tracked on the roadmap
 scope: client
Client-specific work
 scope: dolibarr
Dolibarr modules and customizations
 scope: infrastructure
Server, CI, backups, monitoring
 scope: joomla
Joomla templates and extensions
 scope: waas
MokoWaaS platform
 security
Security vulnerability or hardening
 status: blocked
Waiting on external dependency
 status: duplicate
Duplicate of another issue
 status: in-progress
Being worked on
 status: needs-review
Ready for review
 status: wontfix
Will not be addressed
No labels component: engine priority: high status: ready type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
jmiller (Jonathan Miller)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: MokoConsulting/MokoJoomBackup#14
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?