ahmido
4d3fcd28a9
What Implements tenant-scoped backup scheduling end-to-end: schedules CRUD, minute-based dispatch, queued execution, run history, manual “Run now/Retry”, retention (keep last N), and auditability. Key changes Filament UI: Backup Schedules resource with tenant scoping + SEC-002 role gating. Scheduler + queue: tenantpilot:schedules:dispatch command wired in scheduler (runs every minute), creates idempotent BackupScheduleRun records and dispatches jobs. Execution: RunBackupScheduleJob syncs policies, creates immutable backup sets, updates run status, writes audit logs, applies retry/backoff mapping, and triggers retention. Run history: Relation manager + “View” modal rendering run details. UX polish: row actions grouped; bulk actions grouped (run now / retry / delete). Bulk dispatch writes DB notifications (shows in notifications panel). Validation: policy type hard-validation on save; unknown policy types handled safely at runtime (skipped/partial). Tests: comprehensive Pest coverage for CRUD/scoping/validation, idempotency, job outcomes, error mapping, retention, view modal, run-now/retry notifications, bulk delete (incl. operator forbidden). Files / Areas Filament: BackupScheduleResource.php and app/Filament/Resources/BackupScheduleResource/* Scheduling/Jobs: app/Console/Commands/TenantpilotDispatchBackupSchedules.php, app/Jobs/RunBackupScheduleJob.php, app/Jobs/ApplyBackupScheduleRetentionJob.php, console.php Models/Migrations: app/Models/BackupSchedule.php, app/Models/BackupScheduleRun.php, database/migrations/backup_schedules, backup_schedule_runs Notifications: BackupScheduleRunDispatchedNotification.php Specs: specs/032-backup-scheduling-mvp/* (tasks/checklist/quickstart updates) How to test (Sail) Run tests: ./vendor/bin/sail artisan test tests/Feature/BackupScheduling Run formatter: ./vendor/bin/sail php ./vendor/bin/pint --dirty Apply migrations: ./vendor/bin/sail artisan migrate Manual dispatch: ./vendor/bin/sail artisan tenantpilot:schedules:dispatch Notes Uses DB notifications for queued UI actions to ensure they appear in the notifications panel even under queue fakes in tests. Checklist gate for 032 is PASS; tasks updated accordingly. Co-authored-by: Ahmed Darrazi <ahmeddarrazi@adsmac.local> Reviewed-on: #34
72 lines
1.9 KiB
Markdown
72 lines
1.9 KiB
Markdown
# Quickstart: Backup Scheduling MVP (032)
|
|
|
|
This is a developer/operator quickstart for running the scheduling MVP locally with Sail.
|
|
|
|
## Prerequisites
|
|
|
|
- Laravel Sail running
|
|
- Database migrated
|
|
- Queue worker running
|
|
- Scheduler running (or run the dispatch command manually)
|
|
|
|
## Local setup (Sail)
|
|
|
|
1) Start Sail
|
|
|
|
- `./vendor/bin/sail up -d`
|
|
|
|
2) Run migrations
|
|
|
|
- `./vendor/bin/sail php artisan migrate`
|
|
|
|
3) Start a queue worker
|
|
|
|
- `./vendor/bin/sail php artisan queue:work`
|
|
|
|
## Run the dispatcher manually (MVP)
|
|
|
|
Once a schedule exists, you can dispatch due runs:
|
|
|
|
- `./vendor/bin/sail php artisan tenantpilot:schedules:dispatch`
|
|
|
|
Optional: limit dispatching to specific tenants:
|
|
|
|
- `./vendor/bin/sail php artisan tenantpilot:schedules:dispatch --tenant=<tenant_id_or_external_id>`
|
|
|
|
## Run the Laravel scheduler
|
|
|
|
Recommended operations model:
|
|
|
|
- Dev/local: run `schedule:work` in a separate terminal
|
|
- `./vendor/bin/sail php artisan schedule:work`
|
|
|
|
- Production/staging (Dokploy): cron every minute
|
|
- `* * * * * php artisan schedule:run`
|
|
|
|
## Create a schedule (Filament)
|
|
|
|
- Log into Filament admin
|
|
- Switch into a tenant context
|
|
- Create a Backup Schedule:
|
|
- frequency: daily/weekly
|
|
- time + timezone
|
|
- policy_types: pick from supported types
|
|
- retention_keep_last
|
|
- include_foundations
|
|
|
|
## Verify outcomes
|
|
|
|
- In the schedule list: check `Last Run` and `Next Run`
|
|
- In run history: verify status, duration, error_code/message
|
|
- For successful/partial runs: verify a linked `BackupSet` exists
|
|
|
|
Retention
|
|
|
|
- After a successful/partial run creates a `BackupSet`, the retention job runs asynchronously and soft-deletes older `BackupSet`s so only the last N (per schedule) remain.
|
|
|
|
## Notes
|
|
|
|
- Unknown `policy_types` cannot be saved; legacy DB values are handled fail-safe at runtime.
|
|
- Scheduled runs do not notify a user; interactive actions (Run now / Retry) should persist a DB notification for the acting user.
|
|
- Run now / Retry actions are available for `operator`+ roles.
|