Mark/msp_c2
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

[Phase 1] SLA Management UI and Configuration — Phase 7: 4. SLA Reporting #38

New issue
Closed
opened 2026-05-28 00:52:38 +00:00 by Mark · 2 comments
Mark commented 2026-05-28 00:52:38 +00:00
Owner
Copy link

Phase 7: 4. SLA Reporting

  • SLA compliance rate metrics
  • Average response time
  • Average resolution time
  • Breach reasons analysis

Decomposed from msp_c2#10

## Phase 7: 4. SLA Reporting - SLA compliance rate metrics - Average response time - Average resolution time - Breach reasons analysis --- _Decomposed from [msp_c2#10](https://forgejo.tail018ac4.ts.net/Mark/msp_c2/issues/10)_
Mark commented 2026-05-28 03:53:35 +00:00
Author
Owner
Copy link

⏸ Needs Decision

Blocking factors:

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

Scope: medium Risk: medium Spec: partial Type: enhancement
Summary: Add SLA compliance rate, average response time, average resolution time, and breach reasons analysis as a new reporting capability.
Suggestion: New ~8 files: backend service (compute metrics from ticket SLA dates + status transitions), API router at /api/v1/sla/reporting with date/customer/tech filters, schemas for response, and a frontend SLA Reporting page. Needs a first_response_at and/or resolved_at field on Ticket model for accurate response/resolution time calculation (currently only SLA deadlines exist, not actual timestamps). Breach reasons tracked post-hoc by comparing sla_response_due/sla_resolve_due against actual resolution timestamps.
Rationale: Medium scope because it's a new subsystem (SLA reporting) requiring a new API endpoint, service logic, frontend page, and tests (~5-10 files). Risk is medium because the queries aggregate across all tickets — performance depends on indexing sla fields, but additive to existing endpoints so no breaking changes. Spec is partial: the issue labels it 'Phase 1' but the ROADMAP splits SLA reporting across Phase 1 (basic) and Phase 2 (advanced analytics); existing code lacks the first_response_at/resolved_at timestamps needed for accurate response/resolution time calculation, so either a schema migration or a computation-from-comments approach is needed.

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:** enhancement **Summary:** Add SLA compliance rate, average response time, average resolution time, and breach reasons analysis as a new reporting capability. **Suggestion:** New ~8 files: backend service (compute metrics from ticket SLA dates + status transitions), API router at /api/v1/sla/reporting with date/customer/tech filters, schemas for response, and a frontend SLA Reporting page. Needs a `first_response_at` and/or `resolved_at` field on Ticket model for accurate response/resolution time calculation (currently only SLA deadlines exist, not actual timestamps). Breach reasons tracked post-hoc by comparing sla_response_due/sla_resolve_due against actual resolution timestamps. **Rationale:** Medium scope because it's a new subsystem (SLA reporting) requiring a new API endpoint, service logic, frontend page, and tests (~5-10 files). Risk is medium because the queries aggregate across all tickets — performance depends on indexing sla fields, but additive to existing endpoints so no breaking changes. Spec is partial: the issue labels it 'Phase 1' but the ROADMAP splits SLA reporting across Phase 1 (basic) and Phase 2 (advanced analytics); existing code lacks the `first_response_at`/`resolved_at` timestamps needed for accurate response/resolution time calculation, so either a schema migration or a computation-from-comments approach is needed. **Action:** Review each blocking factor above. Remove `blocked:needs-decision` label to route back to triage.
Mark commented 2026-05-29 19:27:56 +00:00
Author
Owner
Copy link

GSD pipeline blocked at IMPLEMENT: API call failed after 3 retries.
]11;?\Error: Error code: 401 - {'type': 'error', 'error': {'type': 'ModelError', 'message': 'Model deepseek/deepseek-v4-flash is not supported'}}

GSD pipeline blocked at IMPLEMENT: API call failed after 3 retries. ]11;?\Error: Error code: 401 - {'type': 'error', 'error': {'type': 'ModelError', 'message': 'Model deepseek/deepseek-v4-flash is not supported'}}
Mark closed this issue 2026-06-06 18:00:15 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels   
blocked:gate-fetch

   
blocked:gate-fetch

   
blocked:gate-implement

   
blocked:gate-plan

   
blocked:needs-attention

   
blocked:needs-decision

   
blocked:needs-human

   
blocked:no-procedure

   
blocked:preflight

   
bug

Something is not working correctly

  
feature-request

   
in-progress

   
lint-cleanup

   
needs-decompose

Ready to be decomposed into sub-issues

  
needs-triage

   
ops-task

   
quickfix

   
security/medium

Medium severity security issue

  
triage-approved
No labels
blocked:gate-fetch
blocked:gate-fetch
blocked:gate-implement
blocked:gate-plan
blocked:needs-attention
blocked:needs-decision
blocked:needs-human
blocked:no-procedure
blocked:preflight
bug
feature-request
in-progress
lint-cleanup
needs-decompose
needs-triage
ops-task
quickfix
security/medium
triage-approved
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Mark/msp_c2#38
No description provided.