Triage-Command für Bulk-Triage eingehender Tickets implementieren #55

New issue

Open

opened 2026-03-30 19:59:08 +00:00 by David · 0 comments

David commented

2026-03-30 19:59:08 +00:00

Collaborator

Beschreibung

Einen Triage-Command implementieren, der es Operatoren ermöglicht, alle neu
eingegangenen Tickets aus den Ticketsystemen (Odoo, AppSignal) gebündelt zu
sichten, zu priorisieren und zu routen — anstatt jedes Ticket einzeln über
die Detail-Ansicht bearbeiten zu müssen.

Hintergrund

Aktuell durchlaufen Tickets automatisch das Scoring (Regel + LLM) und werden
als autopilot/klärfall/abgelehnt klassifiziert. Bei Klärfällen muss ein
Operator jedes Ticket einzeln öffnen und enrichen. Bei vielen eingehenden
Tickets (z.B. nach einem Odoo-Import oder AppSignal-Incident-Welle) fehlt
eine Übersicht, die schnelle Bulk-Entscheidungen ermöglicht:

Welche Tickets sind wirklich relevant?
Welche können direkt abgelehnt oder zusammengefasst werden?
Welche brauchen sofortige Aufmerksamkeit vs. können warten?

Ein Triage-Command schließt diese Lücke.

Akzeptanzkriterien

API-Endpoint POST /api/tickets/triage akzeptiert eine Liste von
Ticket-IDs mit je einer Triage-Aktion (approve → autopilot,
enrich → klärfall mit Notizen, reject → abgelehnt, defer → zurückstellen)
API-Endpoint GET /api/tickets/triage liefert alle Tickets im Status
"new" oder "klärfall" mit Score-Details, sortiert nach Priorität
Triage-Aktionen werden validiert (z.B. kein approve für Tickets
ohne zugewiesenes Repo)
Frontend: Neue Triage-Seite mit Tabelle aller triagefähigen Tickets,
Checkbox-Selektion, und Bulk-Aktionen (Approve All, Reject Selected, etc.)
Frontend: Inline-Anzeige von Score, Classification, Titel, Quelle und
fehlenden Infos pro Ticket für schnelle Entscheidungen
Approved Tickets starten automatisch die Pipeline
WebSocket-Broadcast bei Triage-Änderungen für Live-Updates im Dashboard
Tests: Mindestens 5 pytest-Tests für den Triage-Endpoint (Bulk-Approve,
Bulk-Reject, Mixed Actions, Validierung, leere Liste)

Technische Hinweise

Betroffene Dateien:
- Neu: backend/api/triage.py (API-Endpoints)
- Neu: backend/services/triage_service.py (Triage-Logik)
- Neu: frontend/src/pages/Triage.tsx (Triage-Seite)
- Neu: frontend/src/components/TriageTable.tsx (Triage-Tabelle)
- Ändern: backend/main.py (Router registrieren)
- Ändern: backend/models/ticket.py (ggf. Status "deferred" hinzufügen)
- Ändern: frontend/src/App.tsx (Route hinzufügen)
- Ändern: frontend/src/api/client.ts (Triage API-Calls)
Ansatz: Triage-Service orchestriert bestehende Pipeline-Methoden
(pipeline.process_ticket() für approves, Status-Updates für rejects).
Kein neues Scoring — nutzt vorhandene Score-Daten zur Anzeige.
Migration nötig: Ja, falls neuer Status "deferred" eingeführt wird

Aufwand: L

## Beschreibung Einen Triage-Command implementieren, der es Operatoren ermöglicht, alle neu eingegangenen Tickets aus den Ticketsystemen (Odoo, AppSignal) gebündelt zu sichten, zu priorisieren und zu routen — anstatt jedes Ticket einzeln über die Detail-Ansicht bearbeiten zu müssen. ## Hintergrund Aktuell durchlaufen Tickets automatisch das Scoring (Regel + LLM) und werden als autopilot/klärfall/abgelehnt klassifiziert. Bei Klärfällen muss ein Operator jedes Ticket einzeln öffnen und enrichen. Bei vielen eingehenden Tickets (z.B. nach einem Odoo-Import oder AppSignal-Incident-Welle) fehlt eine Übersicht, die schnelle Bulk-Entscheidungen ermöglicht: - Welche Tickets sind wirklich relevant? - Welche können direkt abgelehnt oder zusammengefasst werden? - Welche brauchen sofortige Aufmerksamkeit vs. können warten? Ein Triage-Command schließt diese Lücke. ## Akzeptanzkriterien - [ ] API-Endpoint `POST /api/tickets/triage` akzeptiert eine Liste von Ticket-IDs mit je einer Triage-Aktion (approve → autopilot, enrich → klärfall mit Notizen, reject → abgelehnt, defer → zurückstellen) - [ ] API-Endpoint `GET /api/tickets/triage` liefert alle Tickets im Status "new" oder "klärfall" mit Score-Details, sortiert nach Priorität - [ ] Triage-Aktionen werden validiert (z.B. kein approve für Tickets ohne zugewiesenes Repo) - [ ] Frontend: Neue Triage-Seite mit Tabelle aller triagefähigen Tickets, Checkbox-Selektion, und Bulk-Aktionen (Approve All, Reject Selected, etc.) - [ ] Frontend: Inline-Anzeige von Score, Classification, Titel, Quelle und fehlenden Infos pro Ticket für schnelle Entscheidungen - [ ] Approved Tickets starten automatisch die Pipeline - [ ] WebSocket-Broadcast bei Triage-Änderungen für Live-Updates im Dashboard - [ ] Tests: Mindestens 5 pytest-Tests für den Triage-Endpoint (Bulk-Approve, Bulk-Reject, Mixed Actions, Validierung, leere Liste) ## Technische Hinweise - Betroffene Dateien: - Neu: `backend/api/triage.py` (API-Endpoints) - Neu: `backend/services/triage_service.py` (Triage-Logik) - Neu: `frontend/src/pages/Triage.tsx` (Triage-Seite) - Neu: `frontend/src/components/TriageTable.tsx` (Triage-Tabelle) - Ändern: `backend/main.py` (Router registrieren) - Ändern: `backend/models/ticket.py` (ggf. Status "deferred" hinzufügen) - Ändern: `frontend/src/App.tsx` (Route hinzufügen) - Ändern: `frontend/src/api/client.ts` (Triage API-Calls) - Ansatz: Triage-Service orchestriert bestehende Pipeline-Methoden (`pipeline.process_ticket()` für approves, Status-Updates für rejects). Kein neues Scoring — nutzt vorhandene Score-Daten zur Anzeige. - Migration nötig: Ja, falls neuer Status "deferred" eingeführt wird ## Aufwand: L