Mark/msp_c2

Fork 0

[Phase 1] SLA Management UI and Configuration — Phase 12: Effort Estimate #43

New issue

Closed

opened 2026-05-28 00:52:43 +00:00 by Mark · 2 comments

Mark commented

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

Owner

Phase 12: Effort Estimate

Total: Medium (3–4 days) — per sub-issue, not cumulative

Breakdown by sub-issue

Sub-issue	Area	Effort	Status
#35	SLA Policy Configuration (model, CRUD, API, admin UI)	1.5d	✅ Implemented
#36	SLA Rules Engine (auto-apply on create, priority/customer matching, override)	1d	✅ Partially implemented (priority + customer match done; override & business hours not done)
#37	SLA Breach Notifications (email/webhook alerts for upcoming/breached)	1.5d	❌ Not started
#38	SLA Reporting (compliance metrics, date range filter, charts)	1.5d	✅ Partially implemented (summary endpoint + metric cards done; date range filter + charts not done)
#39	SLA UI (policy page, report page, status badges, dashboard card)	2d	✅ Implemented

Effort classification

Scope: medium — touches 8 backend files + 7 frontend files + routing
Risk: low — well-scoped CRUD pattern, follows existing conventions (auth, RBAC, schemas)
Complexity: low–medium — standard REST + React Query pattern; only novel aspect is SLA matching logic

Already implemented (confirmed in codebase)

Backend (7 files):

backend/models/sla_policy.py — SLAPolicy model with priority enum, customer FK, active flag
backend/api/v1/sla/schemas.py — Create/Update/Response Pydantic schemas
backend/crud/sla.py — CRUD operations
backend/api/v1/sla/router.py — 5 CRUD endpoints + report summary, admin-only RBAC
backend/services/sla.py — Breach detection (response/resolve, terminal-status-aware)
backend/crud/ticket.py — Auto-applies matching SLA on ticket create
backend/tests/test_sla_detection.py — 5 unit tests

Frontend (7 files):

frontend/src/components/SLAStatusBadge.jsx — Color-coded badge (ok/warning/breached/none)
frontend/src/pages/SLAPolicyPage.jsx — Admin CRUD UI with form + table
frontend/src/pages/SLAReportPage.jsx — Compliance metrics dashboard
frontend/src/services/api.js — slaAPI object (6 methods)
frontend/src/App.jsx — Routes for /sla-policies and /sla-reports
frontend/src/pages/TicketsPage.jsx — SLA badge column
frontend/src/pages/TicketDetailPage.jsx — SLA badge display

Remaining work

SLA breach notifications (#37) — Integrate with existing webhook/email system; no new infrastructure needed
Business hours support (#36) — Add working-hours fields to SLAPolicy; adjust time calculations in services/sla.py
Report date range filter (#38) — Add date params to report endpoint + frontend controls
Override capabilities (#36) — Allow manual SLA override on individual tickets

Dependencies

Email notification system (1.4 in roadmap) not yet implemented — SLA breach notifications (#37) blocked until then, or use webhooks as interim
No new database migrations needed (columns already exist from initial schema)

Decomposed from msp_c2#10

## Phase 12: Effort Estimate **Total: Medium (3–4 days)** — *per sub-issue, not cumulative* ### Breakdown by sub-issue | Sub-issue | Area | Effort | Status | |-----------|------|--------|--------| | #35 | SLA Policy Configuration (model, CRUD, API, admin UI) | 1.5d | ✅ Implemented | | #36 | SLA Rules Engine (auto-apply on create, priority/customer matching, override) | 1d | ✅ Partially implemented (priority + customer match done; override & business hours not done) | | #37 | SLA Breach Notifications (email/webhook alerts for upcoming/breached) | 1.5d | ❌ Not started | | #38 | SLA Reporting (compliance metrics, date range filter, charts) | 1.5d | ✅ Partially implemented (summary endpoint + metric cards done; date range filter + charts not done) | | #39 | SLA UI (policy page, report page, status badges, dashboard card) | 2d | ✅ Implemented | ### Effort classification - **Scope:** medium — touches 8 backend files + 7 frontend files + routing - **Risk:** low — well-scoped CRUD pattern, follows existing conventions (auth, RBAC, schemas) - **Complexity:** low–medium — standard REST + React Query pattern; only novel aspect is SLA matching logic ### Already implemented (confirmed in codebase) **Backend (7 files):** - `backend/models/sla_policy.py` — SLAPolicy model with priority enum, customer FK, active flag - `backend/api/v1/sla/schemas.py` — Create/Update/Response Pydantic schemas - `backend/crud/sla.py` — CRUD operations - `backend/api/v1/sla/router.py` — 5 CRUD endpoints + report summary, admin-only RBAC - `backend/services/sla.py` — Breach detection (response/resolve, terminal-status-aware) - `backend/crud/ticket.py` — Auto-applies matching SLA on ticket create - `backend/tests/test_sla_detection.py` — 5 unit tests **Frontend (7 files):** - `frontend/src/components/SLAStatusBadge.jsx` — Color-coded badge (ok/warning/breached/none) - `frontend/src/pages/SLAPolicyPage.jsx` — Admin CRUD UI with form + table - `frontend/src/pages/SLAReportPage.jsx` — Compliance metrics dashboard - `frontend/src/services/api.js` — slaAPI object (6 methods) - `frontend/src/App.jsx` — Routes for `/sla-policies` and `/sla-reports` - `frontend/src/pages/TicketsPage.jsx` — SLA badge column - `frontend/src/pages/TicketDetailPage.jsx` — SLA badge display ### Remaining work 1. **SLA breach notifications (#37)** — Integrate with existing webhook/email system; no new infrastructure needed 2. **Business hours support (#36)** — Add working-hours fields to SLAPolicy; adjust time calculations in `services/sla.py` 3. **Report date range filter (#38)** — Add date params to report endpoint + frontend controls 4. **Override capabilities (#36)** — Allow manual SLA override on individual tickets ### Dependencies - Email notification system (1.4 in roadmap) not yet implemented — SLA breach notifications (#37) blocked until then, or use webhooks as interim - No new database migrations needed (columns already exist from initial schema) --- _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:44 +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 00:54:35 +00:00

Mark commented

2026-05-28 00:56:55 +00:00

Author

Owner

⏸ Needs Decision

Blocking factors:

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

Scope: medium Risk: medium Spec: partial Type: feature
Summary: [Phase 1] SLA Management UI and Configuration — Phase 12: Effort Estimate
Suggestion: needs investigation
Rationale:

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=partial --- **Scope:** medium **Risk:** medium **Spec:** partial **Type:** feature **Summary:** [Phase 1] SLA Management UI and Configuration — Phase 12: Effort Estimate **Suggestion:** needs investigation **Rationale:** **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:35 +00:00

Mark added

blocked:gate-plan

and removed

triage-approved

labels

2026-05-29 20:18:30 +00:00