Zalozit nebo doplnit ticket: doplneni konecne doplnuje

Krok mel v poli Obsah nastaveno {{rating}}. Data v behu prokazatelne byla, v udalostech ticketu je hodnoceni videt cele, ale ticket zustal s prazdnym obsahem. intakeEvent deli praci na zalozeni a navazani na existujici ticket a vsechno z `create` platilo jen pro tu prvni vetev. U existujiciho ticketu se doplnovaly pouze vlastni pole a stitky, zbytek se tise zahodil. U hovoru to znamena, ze obsah nedorazi nikdy: prvni zprava jen oznami, ze hovor zacal (in-progress, data null), a prave ta ticket zaklada. Hodnoceni prijde az posledni zpravou, kdy uz ticket existuje. Stav byl jedina vyjimka, protoze ho krok nastavuje zvlast pres updateTicketStatus - proto fungoval a zbytek ne. Jedno pravidlo misto dvou seznamu poli: - neprazdna hodnota prepise, prazdna nemaze. IntakeInput ma na to `apply`, v `create` zustala jen zaloha predmetu a vychozi stav - prazdna hodnota nemaze schvalne. Prave to byla puvodni obava, kvuli ktere se zapisovalo jen pri zalozeni: pozdejsi zprava bez jmena zakaznika je bezna a smazat kvuli ni jmeno by bylo horsi nez ho nedoplnit - vyjimky zustavaji dve: zaloha predmetu z externiho ID plati jen pri vzniku a stav chodi pres updateTicketStatus, ktere resi i priznak vyrizeni, cas vyreseni a pocet znovuotevreni Data smi chodit po castech: - vlastni pole typu se scitaji podle klicu. Prvni zprava posle `data`, druha `data2` a ticket ma obe - prazdny retezec pole nemaze. Sablona, ktera na nic neukazuje, se dosadi prazdnem, takze {"vysledek":"{{result}}"} u zpravy bez vysledku posilalo prazdno a prepsalo tim hodnotu z minule zpravy. Vymazat pole jde poslanim null, coz uz je zamer Dalsi dve veci, ktere u toho vyplavaly: - create.status se do createTicket vubec nepredaval, takze ticket vznikl s vychozim "Nový" a hned se prepsal. V logu pak stalo "stav Nový -> completed" u ticketu, ktery v nem nikdy nebyl - faze byla zrusena uz driv, ale v katalogu po ni zbyval krok "Posunout do dalsi faze" a pole Faze u zalozeni ticketu. Ticket ani typ ticketu fazi nemaji, takze krok by selhal na chybejicim skriptu a pole se zahazovalo. Oboji je pryc Krok navic v logu rekne, co doplnil: "doplnen TK-123, stav completed, obsah". Driv radek jen oznamil, ze se ticket doplnil, a nebylo poznat cim. Overeno na bezici instanci s vlastnim DATA_DIR, tremi zpravami o jednom hovoru: prvni zaklada ticket s prazdnym obsahem, druha doplni obsah i zakaznika, treti bez dat je nechava byt a meni jen stav. Scenar s `data` a pak `data2` ma na konci obe hodnoty. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-02 08:09:05 +02:00
parent 35d1e43307
commit 1134852bff
8 changed files with 324 additions and 85 deletions
@@ -60,6 +60,10 @@ patri telo e-mailu, zprava z WhatsApp nebo prepis hovoru. Kdyz je prazdne,
 znamena to, ze krok "Zalozit ticket" nemel nastavene pole Obsah - detail ticketu
 to napise nahlas misto toho, aby ukazal prazdne misto.

+`body` se zapisuje **pri kazde udalosti**, ne jen pri zalozeni, stejne jako
+skoro vsechno ostatni - podrobnosti nize v "Zalozeni a doplneni delaji totez".
+Cela historie zustava v udalostech ticketu, at uz je v `body` cokoliv.
+
 Uvnitr ulozista se drzi jen `assigneeId`, jmeno se dopocitava pri cteni. Kdyz
 resitel ze seznamu zmizi, ticket nespadne - jen se zaloguje a tvari se jako
 neprirazeny.
@@ -249,6 +253,39 @@ spoustece.
 Nabidka parametru je pod poli. Kliknuti vlozi `{{nazev}}` na pozici kurzoru,
 takze se nemusi psat rucne a neudela se preklep.

+### Zalozeni a doplneni delaji totez
+
+Kdyz uz ticket se stejnym externim ID existuje, **zapise se do nej totez co pri
+zalozeni**. Plati jedno pravidlo:
+
+> Neprazdna hodnota prepise, prazdna nemaze.
+
+Diky tomu nemusi data prijit najednou. U hovoru prvni zprava jen ohlasi, ze
+zacal, a hodnoceni dorazi az posledni - ta uz na ticket dopadne, i kdyz ticket
+zalozila ta prvni.
+
+| Pole                     | Chovani u druhe a dalsi zpravy               |
+| ------------------------ | -------------------------------------------- |
+| Predmet, Obsah           | neprazdna hodnota prepise                    |
+| Typ, Priorita, Kanal     | neprazdna hodnota prepise                    |
+| Zakaznik, Resitel, Skupina | neprazdna hodnota prepise, po polozkach    |
+| Stav, Vyrizeny           | prepise se, pres `updateTicketStatus`        |
+| Stitky                   | pridaji se, existujici zustanou              |
+| Vlastni pole typu        | klice se scitaji, prazdna hodnota nemaze     |
+
+Dve vyjimky, obe zamerne:
+
+- **Zaloha predmetu** (externi ID, kdyz zadny predmet nezadate) se dosadi jen
+  pri vzniku. Jinak by se predmet prepisoval externim ID i tam, kde ho nikdo
+  nechtel.
+- **Stav** nechodi tudy, ale pres `updateTicketStatus`. To resi i priznak
+  vyrizeni, cas vyreseni a pocet znovuotevreni - obejit ho by ta cisla rozbilo.
+
+Vlastni pole typu se **scitaji podle klicu**: kdyz prvni zprava prinese `data`
+a druha `data2`, ma ticket obe. Prazdny retezec nemaze, protoze sablona, ktera
+na nic neukazuje, se dosadi prazdnem. Vymazat pole jde poslanim `null` - to uz
+je zamer, ne vedlejsi ucinek nevyplnene sablony.
+
 Vyber resitele se plni ze seznamu v `people.ts`, ne z rucne psaneho ID. Novy
 clovek v tymu se v nabidce objevi sam.

@@ -46,7 +46,7 @@ Volající nikdy nezjišťuje, jestli běží Postgres, soubor, nebo pamět.
 | `notify(input)`                    | `src/data/notifications.ts`   | Upozorní člověka. Nečeká se a nevyhazuje chyby, stejně jako audit.                                                                                    |
 | `runFlow(steps, context, options)` | `src/runtime/executor.ts`     | Vykoná strom kroků. Nikdy nevyhodí výjimku, chyba je výsledek. Používá to akce na ticketu i webhook, aby se strom choval všude stejně.                |
 | `widgetCatalog(tenantIds, userId)` | `src/data/widgets.ts`         | Jediná definice toho, co jde položit na dashboard. Používá ji nabídka i kontrola ukládaného rozložení.                                                |
-| `intakeEvent(input)`               | `src/data/ticketStore.ts`     | Přijme událost zvenku: podle externího ID buď založí ticket, nebo ji navěsí na existující. Jediná cesta, kterou se událost stává ticketem.            |
+| `intakeEvent(input)`               | `src/data/ticketStore.ts`     | Přijme událost zvenku: podle externího ID buď založí ticket, nebo ji navěsí na existující. Jediná cesta, kterou se událost stává ticketem. Hodnoty z `input.apply` zapíše v obou případech, prázdné nemaže. |
 | `getAgentStats(...)`               | `src/data/ticketStore.ts`     | Výkon řešitelů: odbavené, mediány časů, vrácené, fronta. Používá to widget i detail osoby, aby čísla seděla.                                          |
 | `findByExternalId(...)`            | `src/data/ticketStore.ts`     | Ticket firmy podle externího ID. Klíč je dvojice firma a ID.                                                                                          |
 | `findByIntakeToken(token)`         | `src/data/tenants.ts`         | Firma podle tokenu příjmu. Určuje i to, v jakém rozsahu je externí ID unikátní.                                                                       |
@@ -149,7 +149,6 @@ operace jako každá jiná.
 | `ticket/upsert`            | podle externího ID založí ticket, nebo na existující navěsí událost   |
 | `ticket/assign-least-busy` | předá nejvolnějšímu ze skupiny, při shodě rozhoduje podíl ke kapacitě |
 | `ticket/set-type`          | nastaví typ, za kterým stojí vlastní pole                             |
-| `ticket/set-stage`         | posune do další fáze workflow daného typu                             |
 | `ticket/add-tags`          | přidá štítky, existující nechá                                        |
 | `ticket/set-status`        | změní stav v životním cyklu                                           |
 | `incident/create`          | založí incident                                                       |
@@ -157,18 +156,20 @@ operace jako každá jiná.

 ## Tři osy na ticketu

-| Osa      | Kdo ji určuje                                   | K čemu                                                 |
-| -------- | ----------------------------------------------- | ------------------------------------------------------ |
-| `status` | pevná čtveřice (nový, v řešení, čeká, vyřešeno) | životní cyklus, počítají se z něj statistiky a fronta  |
-| `stage`  | firma u typu ticketu (`TicketType.statuses`)    | postup uvnitř typu: čeká na zabalení, předáno dopravci |
-| `tags`   | kdokoliv, volně                                 | označení, která spolu nemusí souviset                  |
+| Osa      | Kdo ji určuje                                  | K čemu                                                   |
+| -------- | ---------------------------------------------- | -------------------------------------------------------- |
+| `status` | odesílatel, nabídku dává `TicketType.statuses` | kde ticket je: čeká na zabalení, předáno dopravci        |
+| `closed` | výslovně, krok nebo člověk                     | co už nikdo neřeší, z toho se počítá fronta a statistiky |
+| `tags`   | kdokoliv, volně                                | označení, která spolu nemusí souviset                    |

-Fáze může být **jen jedna**, proto se na ni dá spolehnout v podmínce. Přes
+Stav může být **jen jeden**, proto se na něj dá spolehnout v podmínce. Přes
 štítky by to fungovalo taky, ale ticket by mohl mít "čeká na zabalení"
 i "expedováno" naráz a nikdo by nepoznal, co platí.

-Fáze mimo workflow typu se odmítne. Překlep by jinak tiše vyřadil podmínku,
-která na fázi stojí.
+Fáze jako třetí osa tady byla a **je zrušená**. Když je stav volný řetězec,
+je druhé pole na tutéž věc jen zmatení. V katalogu po ní zbýval krok
+"Posunout do další fáze" a pole Fáze u založení ticketu, jenže model fázi
+neměl - krok neměl co vykonat a pole se tiše zahazovalo.

 ## Živý dashboard

@@ -2,6 +2,79 @@

 Nejnovejsi nahore.

+## 2026-09-02 - Zalozit NEBO DOPLNIT ticket: doplneni konecne doplnuje
+
+Automatizace mela v kroku "Zalozit nebo doplnit ticket" pole Obsah nastavene na
+`{{rating}}`. Data v behu prokazatelne byla - v udalostech ticketu je hodnoceni
+videt cele - ale ticket zustal s prazdnym obsahem.
+
+### Cim to bylo
+
+`intakeEvent` deli praci na **zalozeni** a **navazani na existujici ticket**.
+Vsechno z `create` platilo jen pro tu prvni vetev. U existujiciho ticketu se
+doplnovaly pouze vlastni pole a stitky. Predmet, obsah, typ, priorita, kanal,
+zakaznik, resitel ani skupina ne - tise se zahodily.
+
+U hovoru to znamena, ze obsah nedorazi nikdy. Prvni zprava jen oznami, ze hovor
+zacal (`status: in-progress`, `data: null`), a **prave ta ticket zaklada**, tedy
+s prazdnym obsahem. Hodnoceni prijde az posledni zpravou, kdy uz ticket existuje.
+
+Stav byl jedina vyjimka, protoze ho krok nastavuje zvlast pres
+`updateTicketStatus`. Proto fungoval a zbytek ne, a proto to vypadalo jako chyba
+jednoho pole.
+
+### Jedno pravidlo misto dvou seznamu
+
+Zalozeni a doplneni ted delaji totez:
+
+> Neprazdna hodnota prepise, prazdna nemaze.
+
+`IntakeInput` ma na to `apply`, v `create` zustal jen zaloha predmetu a vychozi
+stav. Dva ruzne seznamy poli by se stejne zase rozesly a nekde by zas neco
+chybelo.
+
+Prazdna hodnota nemaze schvalne. Prave to byla puvodni obava, kvuli ktere se
+zapisovalo jen pri zalozeni: pozdejsi zprava bez jmena zakaznika je bezna
+a smazat kvuli ni jmeno by bylo horsi nez ho nedoplnit. Nove se prepise jen to,
+co odesilatel opravdu poslal, takze pojistka plati a data se neztraci.
+
+Dve vyjimky zustavaji: zaloha predmetu z externiho ID plati jen pri vzniku
+a stav chodi pres `updateTicketStatus`, ktere resi i priznak vyrizeni, cas
+vyreseni a pocet znovuotevreni.
+
+### Data smi chodit po castech
+
+Vlastni pole typu se **scitaji podle klicu**. Prvni zprava posle `data`, druha
+`data2` a ticket ma obe. Odesilatel se nemusi predem dohodnout, co vsechno
+posle, a nemusi posilat vsechno pokazde.
+
+Prazdny retezec pritom pole nemaze. Sablona, ktera na nic neukazuje, se dosadi
+prazdnem, takze `{"vysledek":"{{result}}"}` u zpravy bez vysledku posilalo
+prazdno a **prepsalo tim hodnotu z minule zpravy**. Vymazat pole jde poslanim
+`null`: to uz je zamer, ne vedlejsi ucinek nevyplnene sablony.
+
+### Stav se ted ulozi uz pri vzniku
+
+`create.status` se do `createTicket` vubec nepredaval, takze ticket vznikl
+s vychozim "Nový" a hned se prepsal. V logu pak stalo "stav Nový -> completed"
+u ticketu, ktery v "Nový" nikdy nebyl. Komentar u volajiciho tvrdil, ze uz je to
+opravene - opravena byla jen jedna strana.
+
+### Faze dorazena do konce
+
+Faze byla zrusena uz driv, hodnoty z ni patri do stavu. V katalogu po ni ale
+zbyval krok "Posunout do dalsi faze" a pole Faze u zalozeni ticketu. Ani jedno
+nemelo co delat: ticket ani typ ticketu fazi nemaji. Krok by pri behu selhal na
+chybejicim skriptu a pole se tise zahazovalo, takze `{{status}}` napsany do Faze
+nedelal nic. Oboji je pryc.
+
+### Aby bylo videt, ze se to ulozilo
+
+Krok v logu rekne, co doplnil: `doplnen TK-123, stav completed, obsah`. Driv
+radek jen oznamil, ze se ticket doplnil, a nebylo poznat cim - u dat, ktera
+dorazi az druhou zpravou, je to zrovna ta informace, kterou clovek hleda.
+
+
 ## 2026-08-28 - pad portalu uz nesmi shodit stranku a zaklada incident

 Ukazka tela webhooku shazovala cely builder pri psani cesty parametru. Chyba