[Phase 1] SLA Management UI and Configuration — Phase 9: Acceptance Criteria #40

New issue

Closed

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

Mark commented

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

Owner

Phase 9: Acceptance Criteria

SLA policy configuration API and UI
Business hours configuration
SLA rules engine implemented
SLA breach notifications
SLA compliance dashboard
SLA reporting page
Tests for SLA calculations

Decomposed from msp_c2#10

## Phase 9: Acceptance Criteria - [ ] SLA policy configuration API and UI - [ ] Business hours configuration - [ ] SLA rules engine implemented - [ ] SLA breach notifications - [ ] SLA compliance dashboard - [ ] SLA reporting page - [ ] Tests for SLA calculations --- _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:40 +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:49:45 +00:00

Mark commented

2026-05-28 03:49:45 +00:00

Author

Owner

⏸ Needs Decision

Blocking factors:

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

Scope: medium Risk: medium Spec: aligned Type: feature
Summary: Issue #40 implements the full SLA management subsystem — policy config, business hours, rules engine, breach notifications, compliance dashboard, and reporting — building on the existing basic SLA timestamp fields and breach detection service.
Suggestion: Work incrementally: (1) new DB models for SLA policy + business_hours, (2) CRUD API router at /api/v1/sla/, (3) extend sla.py service with configurable rules engine, (4) wire breach detection into webhook system, (5) frontend pages for config, dashboard compliance widget, and reporting page, (6) tests for each layer. The existing Ticket model already has sla_response_due/sla_resolve_due columns and a basic sla.py breach detector — leverage and extend these rather than rebuilding.
Rationale: SCOPE=medium: ~10-14 files across models, API, services, frontend pages, and tests — a full new subsystem but not 15+ files. RISK=medium: additive to the existing ticket model, doesn't touch core CRUD paths, but business hours logic and notification integration have moderate edge-case complexity. SPEC=aligned: directly maps to ROADMAP.md section 1.5 (SLA Management Enhancements, Phase 1, Q2 2026) — the roadmap even notes 'Basic tracking exists, needs UI and rules' which matches exactly what the existing sla_response_due/sla_resolve_due columns provide. TYPE=feature: entirely new capability, not a bugfix or chore. Note: the existing dashboard router queries Ticket.due_date which doesn't exist in the model — that field appears to be dead code or a separate concern that should either be removed or migrated to sla_resolve_due as part of this work.

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=medium, spec=aligned --- **Scope:** medium **Risk:** medium **Spec:** aligned **Type:** feature **Summary:** Issue #40 implements the full SLA management subsystem — policy config, business hours, rules engine, breach notifications, compliance dashboard, and reporting — building on the existing basic SLA timestamp fields and breach detection service. **Suggestion:** Work incrementally: (1) new DB models for SLA policy + business_hours, (2) CRUD API router at /api/v1/sla/, (3) extend sla.py service with configurable rules engine, (4) wire breach detection into webhook system, (5) frontend pages for config, dashboard compliance widget, and reporting page, (6) tests for each layer. The existing Ticket model already has sla_response_due/sla_resolve_due columns and a basic sla.py breach detector — leverage and extend these rather than rebuilding. **Rationale:** SCOPE=medium: ~10-14 files across models, API, services, frontend pages, and tests — a full new subsystem but not 15+ files. RISK=medium: additive to the existing ticket model, doesn't touch core CRUD paths, but business hours logic and notification integration have moderate edge-case complexity. SPEC=aligned: directly maps to ROADMAP.md section 1.5 (SLA Management Enhancements, Phase 1, Q2 2026) — the roadmap even notes 'Basic tracking exists, needs UI and rules' which matches exactly what the existing sla_response_due/sla_resolve_due columns provide. TYPE=feature: entirely new capability, not a bugfix or chore. Note: the existing dashboard router queries Ticket.due_date which doesn't exist in the model — that field appears to be dead code or a separate concern that should either be removed or migrated to sla_resolve_due as part of this work. **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:36 +00:00

Mark removed the

triage-approved

label

2026-05-29 20:17:37 +00:00

Mark added the

triage-approved