From 5bb49495e4f44de1dbeb15b0ce4f3335ff7809f4 Mon Sep 17 00:00:00 2001 From: mika kuns Date: Thu, 1 Oct 2026 08:12:17 +0200 Subject: [PATCH] docs(tickets): switch import source to project-board sweep after live probe --- .../2026-10-01-ticket-import-all-design.md | 39 +++++++++++++------ 1 file changed, 27 insertions(+), 12 deletions(-) diff --git a/docs/superpowers/specs/2026-10-01-ticket-import-all-design.md b/docs/superpowers/specs/2026-10-01-ticket-import-all-design.md index 07604ee2..909f0654 100644 --- a/docs/superpowers/specs/2026-10-01-ticket-import-all-design.md +++ b/docs/superpowers/specs/2026-10-01-ticket-import-all-design.md @@ -35,20 +35,35 @@ und plant danach den Tag (bestehender FillMyDay-Lauf). Auslösbar per Button und ### 1. Datenquelle (`Worker/Tickets/`) -`BandelTicketClient.GetAssignedItemsAsync(ct)`: -`GET /api/ticketsystem/pat/me` (userName) → `GET /api/ticketsystem/users/username/{u}` (userId) → -`GET /api/board/global/{userId}`. Filter wie bisher: `ticketAssignees[].assigneeName == userName` -und `statusId ∈ {1, 2}`. +**Sweep über alle Projekt-Boards** — nur Routen, die `BandelTicketClient` schon hat und die seit +2026-09-01 live verifiziert sind: `GET /api/Navigation/sidebar` (alle sichtbaren Projekte) → +pro Projekt `GET /api/Board/project/{id}`. Filter, `statusId ∈ {1, 2}`: -> ⚠️ **Erster Implementierungsschritt: live verifizieren**, bevor ein DTO geschrieben wird — -> liefert das globale Board Tasks/Subtasks (itemType 2/3) samt `parentId`/Parent-Titel und -> Projekt? Feldweise über alle Datensätze prüfen, nicht an einem Sample (siehe Memory -> `ticketsystem-integration`: `assigneeName` war im DTO vorhanden und live immer null). -> Fallback, falls nicht: das Ticket-MCP `list_assigned_items` zeigt, dass die Daten existieren — -> dessen Route in `Bandel.APIs`/TicketSystem-MCP nachschlagen. +- Ticket (Board-Item): `ticketAssignees[].assigneeName == userName` +- Task (`tasks[]` am Board-Item): **`ticketTaskAssignees[].assigneeName`** == userName — + unabhängig davon, wem das Parent-Ticket gehört (730/732 hängen an 728 von marcel.sievers). -Ebenfalls live prüfen: `PATCH /api/ticket/{id}/status` für ein Item vom Typ Task (Write-back muss -für Tasks/Subtasks funktionieren; laut Bandel.APIs-Breadcrumb dieselbe Tabelle). +Projekt-Titel kommt aus der Sidebar, Parent aus dem umschließenden Board-Item. +`TicketBoardItem` bekommt `Tasks` (`id`, `title`, `statusId`, `hasChildren`, +`ticketTaskAssignees`). + +**Live-Befund 2026-10-01** (7 Projekte, ~1,2 s): exakt die 10 offenen Items, die das Ticket-MCP +`list_assigned_items` liefert — 665, 593 (+595/596/598/668), 1014, 1016, 1017, 730, 732. +Verworfen wurde `GET /api/board/global/{userId}`: liefert kein Projekt, braucht eine userId, die +`/pat/me` nicht hergibt (`/users/username/{u}` = 401 mit PAT), und ist **nicht** auf den +Token-Inhaber beschränkt (`global/22` lieferte 147 fremde Items). + +Subtasks (Ebene 3): live existiert keiner (`hasChildren` überall false). Board-Tasks mit +`hasChildren = true` werden übersprungen. + + +**Offen, manuell zu prüfen:** `PATCH /api/Ticket/{id}/status` auf einem **Task** (nicht Ticket) — +nicht live getestet, weil es ein Schreibzugriff aufs Firmensystem ist. Laut Bandel.APIs-Breadcrumb +gleiche Tabelle, Statusrecht u.a. für Assignees. Scheitert es, loggt `TicketStatusSync` nur eine +Warnung (wirft nie) → beim ersten echten Lauf im Worker-Log prüfen. + +Details pro Item für die Beschreibung: `GET /api/ticket/{id}` (live: liefert `description`, +`parentTicketID`). ### 2. `TicketImportService`