[Phase 1] SLA Management UI and Configuration — Phase 6: 3. SLA Breach Notifications #37

New issue

Closed

opened 2026-05-28 00:52:36 +00:00 by Mark · 1 comment

Mark commented

2026-05-28 00:52:36 +00:00

Owner

Phase 6: 3. SLA Breach Notifications

Email alerts for upcoming SLA breaches
Email alerts for breached SLAs
Dashboard indicators for at-risk tickets

Decomposed from msp_c2#10

## Phase 6: 3. SLA Breach Notifications - Email alerts for upcoming SLA breaches - Email alerts for breached SLAs - Dashboard indicators for at-risk tickets --- _Decomposed from [msp_c2#10](https://forgejo.tail018ac4.ts.net/Mark/msp_c2/issues/10)_

Mark added the

needs-triage

label

2026-05-28 00:52:36 +00:00

Mark referenced this issue

2026-05-28 00:52:45 +00:00

[Phase 1] SLA Management UI and Configuration #10

Mark added

blocked:needs-decision

and removed

needs-triage

labels

2026-05-28 03:55:46 +00:00

Mark commented

2026-05-28 03:55:46 +00:00

Author

Owner

⏸ Needs Decision

Blocking factors:

Didn't meet auto-approve criteria — scope=medium, risk=low, spec=aligned

Scope: medium Risk: low Spec: aligned Type: feature
Summary: Add SLA breach notification system with email alerts for upcoming/breached SLAs and dashboard indicators for at-risk tickets.
Suggestion: Reuse existing services/sla.py for breach detection; create a services/notification.py using the 'emails' library (already in requirements.txt); add an SLANotification model to track sent alerts and prevent duplicates; use Celery beat (celery already in requirements) for periodic breach scanning; add an at-risk tickets endpoint to the dashboard router; surface at-risk indicators on the frontend DashboardPage as colored badges or a new card.
Rationale: Medium scope because it spans backend (new notification service, scheduler task, tracking model), frontend (dashboard at-risk indicators), and potentially a new migration. Low risk because SLA detection logic already exists and is tested, email infrastructure is additive with no breaking changes to existing endpoints, and the dashboard already has an Overdue SLA card to extend. Fully aligned with the spec which lists SLA timestamps as a core ticketing feature and overdue SLA as a dashboard metric.

Action: Review each blocking factor above. Remove blocked:needs-decision label to route back to triage.

## ⏸ Needs Decision **Blocking factors:** - **Didn't meet auto-approve criteria** — scope=medium, risk=low, spec=aligned --- **Scope:** medium **Risk:** low **Spec:** aligned **Type:** feature **Summary:** Add SLA breach notification system with email alerts for upcoming/breached SLAs and dashboard indicators for at-risk tickets. **Suggestion:** Reuse existing services/sla.py for breach detection; create a services/notification.py using the 'emails' library (already in requirements.txt); add an SLANotification model to track sent alerts and prevent duplicates; use Celery beat (celery already in requirements) for periodic breach scanning; add an at-risk tickets endpoint to the dashboard router; surface at-risk indicators on the frontend DashboardPage as colored badges or a new card. **Rationale:** Medium scope because it spans backend (new notification service, scheduler task, tracking model), frontend (dashboard at-risk indicators), and potentially a new migration. Low risk because SLA detection logic already exists and is tested, email infrastructure is additive with no breaking changes to existing endpoints, and the dashboard already has an Overdue SLA card to extend. Fully aligned with the spec which lists SLA timestamps as a core ticketing feature and overdue SLA as a dashboard metric. **Action:** Review each blocking factor above. Remove `blocked:needs-decision` label to route back to triage.

Mark added

triage-approved

and removed

blocked:needs-decision

labels

2026-05-28 07:18:37 +00:00

Mark removed the

triage-approved

label

2026-05-29 18:53:15 +00:00

Mark referenced this issue

2026-06-06 17:43:38 +00:00