updated tickets

documentation/04-api.md

@@ -23,7 +23,13 @@ Vyzaduji `Authorization: Bearer <token>`:
 | GET    | `/api/auth/me`                                      |
 | POST   | `/api/auth/logout`                                  |
 | GET    | `/api/dashboard/summary`                            |
+| GET    | `/api/dashboard/people`                             |
 | GET    | `/api/dashboard/tickets`                            |
+| GET    | `/api/dashboard/tickets/workload`                   |
+| GET    | `/api/dashboard/tickets/:id`                        |
+| POST   | `/api/dashboard/tickets/:id/assign`                 |
+| POST   | `/api/dashboard/tickets/:id/status`                 |
+| POST   | `/api/dashboard/tickets/:id/comment`                |
 | GET    | `/api/dashboard/incidents`                          |
 | GET    | `/api/dashboard/connectors`                         |
 | GET    | `/api/dashboard/stream`                             |
@@ -72,8 +78,8 @@ cookie se `Secure` a `SameSite` plus CSRF token.
 a poslednich par udalosti, pak uz jen nove. Kazdych 25 sekund jde komentarovy
 radek, aby spojeni neuspalo proxy.
 
-Typy udalosti: `ticket.created`, `ticket.updated`, `ticket.resolved`,
-`incident.started`, `incident.updated`, `incident.resolved`,
+Typy udalosti: `ticket.created`, `ticket.updated`, `ticket.assigned`,
+`ticket.resolved`, `incident.started`, `incident.updated`, `incident.resolved`,
 `automation.created`, `automation.updated`, `automation.deleted`,
 `automation.run`, `webhook.received`.
 
@@ -107,6 +113,29 @@ curl -X POST https://services.csbot.cz/apps/<app-id>/webhook/<token> \
 Prototyp pozadavek prijme, zvaliduje a zapocita do metrik, ale strom akci
 nevykona - runtime neexistuje.
 
+## Tickety
+
+Popis modelu je v [06-tickety.md](06-tickety.md), tady jen to, co se tyka API.
+
+`GET /api/dashboard/tickets` bere filtry v query: `assignee`, `status`, `channel`.
+U `assignee` jsou dve zvlastni hodnoty: `me` znamena resitele odpovidajiciho
+prihlasenemu uzivateli, `unassigned` frontu bez resitele. Neznama hodnota filtru
+se zaloguje a ignoruje - je lepsi ukazat vic ticketu nez prazdny seznam
+bez vysvetleni.
+
+Odpoved nese vedle `items` jeste `meId`. Klient podle nej pozna, ktere tickety
+jsou jeho, a jestli ma vubec smysl nabizet filtr "moje".
+
+Filtrovani dela **server**, ne klient. Seznam a prehled vytizeni tak nikdy
+neukazuji jina cisla. Vyhledavaci pole v portalu je jina vec - to jen dohledava
+v uz nactenem seznamu.
+
+`GET /api/dashboard/tickets/:id` vraci navic `trace`, tedy log prubehu vcetne
+toho, co ktera volana sluzba vratila.
+
+`POST /api/dashboard/tickets/:id/assign` s telem `{"assigneeId": null}` vrati
+ticket do fronty. Neznamy resitel vraci 404, ne tiche odpojeni.
+
 ## Simulace
 
 `POST /api/simulate` vyvola provozni udalost pro nahled ziveho dashboardu.
@@ -115,6 +144,10 @@ Zamerne meni skutecna data, ne jen posila falesnou notifikaci.
 Akce: `ticket.created`, `ticket.resolved`, `incident.started`,
 `incident.resolved`, `automation.run`.
 
+U `ticket.created` urcuje `channel`, odkud pozadavek prisel, a podle toho se
+poskladá i log ticketu. `knownCustomer: false` znamena, ze CRM firmu nedohleda -
+ticket zustane bez zakaznika i bez resitele a v logu je videt proc.
+
 Nevyplnena pole server doplni ukazkovou hodnotou. U akci s "resolved" se bez
 zadaneho id pouzije prvni nevyrizeny zaznam.