[Phase 1] SLA Management UI and Configuration — Phase 1: Overview #32

New issue

Closed

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

Mark commented

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

Owner

Phase 1: Overview

Basic SLA tracking exists in the backend, but there's no UI for configuring SLA policies or viewing SLA compliance. This is needed for proper SLA management.

Decomposed from msp_c2#10

## Phase 1: Overview Basic SLA tracking exists in the backend, but there's no UI for configuring SLA policies or viewing SLA compliance. This is needed for proper SLA management. --- _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:30 +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 04:07:00 +00:00

Mark commented

2026-05-28 04:07:00 +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 policy configuration UI and compliance viewing to the existing per-ticket sla_response_due/sla_resolve_due backend columns and breach detection service.
Suggestion: Create an SlaPolicy model (priority→response/resolve targets + business hours) with CRUD API under /api/v1/sla-policies, an Alembic migration, and a new frontend route/page for policy configuration. Extend the ticket detail/list views to display SLA status badges (on-track/breached) using the existing sla_breach_state service. Follow the same FastAPI CRUD + React table/form pattern used elsewhere (e.g. CatalogPage).
Rationale: Medium scope because it requires a new backend model/CRUD/API/migration (~5-6 files) plus a new frontend page (~3-4 files) but no changes to the existing ticket creation flow or core processing paths. Low risk because it's purely additive — the existing sla_response_due/sla_resolve_due columns on the Ticket model and the sla.py breach detection service are untouched. Fully aligned with the ROADMAP.md section 1.5 (SLA Management Enhancements, Phase 1, medium priority) and the project's already-planned SLA features.

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 policy configuration UI and compliance viewing to the existing per-ticket sla_response_due/sla_resolve_due backend columns and breach detection service. **Suggestion:** Create an SlaPolicy model (priority→response/resolve targets + business hours) with CRUD API under /api/v1/sla-policies, an Alembic migration, and a new frontend route/page for policy configuration. Extend the ticket detail/list views to display SLA status badges (on-track/breached) using the existing sla_breach_state service. Follow the same FastAPI CRUD + React table/form pattern used elsewhere (e.g. CatalogPage). **Rationale:** Medium scope because it requires a new backend model/CRUD/API/migration (~5-6 files) plus a new frontend page (~3-4 files) but no changes to the existing ticket creation flow or core processing paths. Low risk because it's purely additive — the existing sla_response_due/sla_resolve_due columns on the Ticket model and the sla.py breach detection service are untouched. Fully aligned with the ROADMAP.md section 1.5 (SLA Management Enhancements, Phase 1, medium priority) and the project's already-planned SLA features. **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:38 +00:00

Mark added the

in-progress

label

2026-06-08 03:10:12 +00:00

Mark referenced this issue from a commit

2026-06-08 05:47:42 +00:00