Log rekne co zpusobilo jakou zmenu, prevzeti ticketu a pozvanky

Nalezeno na bezicim serveru: TK-4946 mel 177 udalosti a 620 radku logu,
pritom se skoro nic nestalo. Zmereno proti fronte: ve stejnem okne vzniklo
presne tolik behu, kolik prislo udalosti (22 a 22), kazdy s jednim pokusem.
Fronta nenasobi nic, odesilatel poslal 177 POSTu. Nase vina byla, ze to
z historie neslo poznat.

- Data udalosti se ukladaji. Kdyz krok nema vlastni, ulozi se to, cim beh
  zacal - u webhooku prijate telo. Prazdna udalost je horsi nez zadna.
- Shodna udalost se pocita (repeats, lastAt), nezaklada dalsi radek. Ticket
  se pritom nemeni, takze duplikat nerozblika dashboard ani nespusti
  automatizaci na zmenu ticketu. Zahodit ji nejde, jinak by nikdo nezjistil,
  ze proti nam neco tluce.
- Zmeny se radi pod udalost, ktera je zpusobila, a u udalosti stoji jmeno
  automatizace. Log se cte jako "prislo tohle -> zmenilo to tohle".
- Poznamka o stavu jen kdyz se stav zmenil. "z in-progress na in-progress"
  u kazde zpravy byl zdroj tech 620 radku.
- runsToday konecne znamena dnes: behy po dnech, k tomu vcera a celkem.
  Dosud to byl citac od zalozeni automatizace, jen se jmenoval "dnes".

Vedle toho prace, o kterou slo predtim:
- Prevzeti ticketu ze skupiny (POST /tickets/:id/claim) a krok Predat skupine
  s prepinacem automatickeho prideleni nejvolnejsimu.
- Pozvanky do firmy: odkaz s nahodnym kodem, heslo si nastavi pozvany.
- Resitele, skupiny a pozvanky presunuty z Nastaveni do zalozky Lide, cleny
  skupiny se vybiraji klikanim.
- Ctyri AI znaky, ktere zbyvaly v kodu, pryc.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
JiriUhlir
2026-08-17 15:54:34 +02:00
co-authored by Claude Opus 5
parent fbe5b8ff6f
commit f1e8253169
30 changed files with 1839 additions and 107 deletions
+3 -1
View File
@@ -37,10 +37,12 @@ React aplikaci ze slozky `dist/public`.
| Skripty konektoru | hotovo | manifest, kontrola parametru, hot reload, iDoklad |
| Konektory za firmu | hotovo | pristupove udaje v konektoru, overeni napojeni |
| Transformace dat | hotovo | pravidla i sablona JSON, kroky si predavaji struktury |
| Sprava clenstvi z portalu | hotovo | uzivatele, firmy a role v Nastaveni |
| Sprava clenstvi z portalu | hotovo | firmy a role v Nastaveni, lide a pozvanky v Lidech |
| Role a prava jako data | hotovo | 26 prav v katalogu, vlastni role za firmu |
| Zalozky a limity za firmu | hotovo | navigace chodi ze serveru, ne z kodu klienta |
| Osoby a skupiny resitelu | hotovo | ticket lze prehodit na skupinu, ne jen na cloveka |
| Prevzeti ticketu ze skupiny | hotovo | kdo ma cas, si praci vezme sam |
| Pozvanky do firmy | hotovo | odkaz s kodem, heslo si nastavi pozvany |
| Typy ticketu a vlastni pole | hotovo | typ rozhoduje, ktere akce se na ticketu ukazou |
| Vydefinovane akce na ticketu | hotovo | vazba na typ nebo tag, telo je operace, strom, skript |
| Vlastni widgety | hotovo | vcetne zdroje z konektoru a vykonu resitelu |
+36
View File
@@ -48,8 +48,14 @@ Vyzaduji `Authorization: Bearer <token>`:
| POST | `/api/dashboard/tickets/:id/type` |
| POST | `/api/dashboard/tickets/:id/tags` |
| POST | `/api/dashboard/tickets/:id/group` |
| POST | `/api/dashboard/tickets/:id/claim` |
| GET | `/api/dashboard/tickets/:id/actions` |
| POST | `/api/dashboard/tickets/:id/actions/:actionId` |
| GET | `/api/dashboard/invites` |
| POST | `/api/dashboard/invites` |
| DELETE | `/api/dashboard/invites/:id` |
| GET | `/api/invites/:kod` |
| POST | `/api/invites/:kod/accept` |
| GET | `/api/dashboard/incidents` |
| GET | `/api/dashboard/storage` |
| GET | `/api/dashboard/services` |
@@ -196,6 +202,36 @@ 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.
`POST /api/dashboard/tickets/:id/claim` je **prevzeti prace**, ne prehozeni:
volajici si bere ticket sam a telo je prazdne. Smi to u ticketu bez resitele
a u ticketu ve skupine, ve ktere je. Kdyz uz ticket nekdo resi, vraci 409, resp.
403 u cizi skupiny - vzit nekomu rozdelanou praci je jine rozhodnuti a chce to
pravo `ticket.assign.others`. Kdo neni vedeny jako resitel, dostane 400.
## Pozvanky do firmy
`/api/invites/:kod` je **verejne**, protoze kdo prijde za odkazem, jeste ucet
mit nemusi. Autorizuje kod v adrese, proto je nahodny a dlouhy - stejne jako
u webhooku. Odpoved je zamerne uzka: nazev firmy, jestli pozvanka plati, a kdyz
uz adresu zname, tak ji, at ji clovek nemusi psat. Nic o tom, kdo ve firme je.
`POST /api/invites/:kod/accept` s telem `{"name", "email", "password"}`:
| Situace | Co se stane |
| --- | --- |
| ucet neexistuje | zalozi se a pripoji k firme |
| ucet existuje, heslo sedi | jen se pripoji k firme |
| ucet existuje, heslo nesedi | 401 |
| pozvanka je na jinou adresu | 403 |
| pozvanka uz byla pouzita nebo vyprsela | 409 s konkretnim duvodem |
Overeni hesla u existujiciho uctu neni formalita: bez nej by kdokoliv s odkazem
pripojil cizi adresu ke sve firme a videl by jeji data.
Sprava pozvanek (`/api/dashboard/invites`) chce pravo `user.manage`. Seznam
vraci u kazde pozvanky **celou adresu** vcetne prefixu proxy, aby slo rovnou
kopirovat - relativni cesta se do zpravy vlepit neda.
## Akce na ticketu
Popis modelu je v [09-navrh-rozsireni.md](09-navrh-rozsireni.md).
+77
View File
@@ -80,6 +80,47 @@ Kazdy resitel ma `capacity`, tedy pocet nevyrizenych ticketu, ktery je pro nej
jeste zdrava zatez. Neni to limit, nic se podle nej neodmita - jen se v prehledu
oznaci, kdo je nad ni.
## Fronta skupiny a prevzeti
Ticket nemusi mit resitele hned. Muze lezet **u skupiny** a cekat, az si ho
nekdo vezme - `POST /tickets/:id/claim`. Kdo je ve skupine, si ho vezme sam,
prace se nerozdava shora.
Proc obojí vedle sebe:
| Situace | Co se hodi |
| --- | --- |
| havarie, musi to nekdo hned resit | automat prideli nejvolnejsimu |
| bezny dotaz, lidi maji ruzne dny | necha se ve fronte skupiny |
Proto je prepinac **Priradit rovnou nejvolnejsimu** na kroku automatizace
(`ticket/assign-group`), ne na skupine: tataz skupina potrebuje obe chovani,
jen u jineho typu prace.
Vzit si ticket, ktery uz nekdo resi, neni prevzeti, ale prehozeni. Chce to pravo
`ticket.assign.others` a jde to jen pres prirazeni, ne pres prevzeti.
## Pozvanky do firmy
`src/data/invites.ts`
Novy clovek se do firmy dostane odkazem s nahodnym kodem, ne tim, ze mu nekdo
zalozi ucet a posle heslo. Duvody:
- **heslo nikdy nikam neposilame.** Kdo si ho nastavi sam za odkazem, ma ho jen
on,
- pozvanka **vyprsi** (tyden) a da se zrusit, ucet ne,
- kdo uz ucet ma, se jen pripoji k dalsi firme misto zakladani druheho - ale
musi zadat svoje heslo, jinak by kdokoliv s odkazem pripojil cizi adresu ke
sve firme.
U pozvanky se rovnou rekne, jake role clovek dostane a jestli z nej ma byt
i **resitel**. Uzivatel a resitel nejsou totez, viz vyse - proto se to pta
misto hadani.
Sprava je v zalozce **Lide**, ne v nastaveni: pozvat kolegu je bezna denni
prace.
## Prehled nad firmou
`GET /api/dashboard/tickets/workload` vraci pres cely tym: kolik ma kdo
@@ -123,6 +164,42 @@ do korene a zaloguje - ztratit radek logu je horsi nez ho ukazat spatne zanoreny
Komentare jsou taky zaznamy logu (`kind: 'note'`). Diky tomu je vsechno na jedne
casove ose a nemusi se nikde skladat dohromady dva ruzne seznamy.
## Opakovana udalost
Odesilatele umi poslat stejnou zpravu i osmdesatkrat za minutu. Kdyz prijde
**presne totez co posledne** (stejny typ, zdroj, popisek a stejna data), nezaklada
se dalsi radek: pricte se k pocitadlu u te predchozi.
| Co se stane | Proc |
| --- | --- |
| `repeats` +1, `lastAt` = ted | osmdesat radku znamena, ze v historii nikdo nic nenajde |
| ticket se **nemeni** | jinak by duplikat rozblikal dashboard a spustil automatizaci na zmenu ticketu |
| do logu se nezapisuje nic | log ma ukazovat zmeny, ne to, ze se nezmenilo nic |
| udalost se **nezahazuje** | bez pocitadla by nikdo nezjistil, ze proti nam neco tluce ve smycce |
Porovnava se jen s posledni udalosti. "Objednavka pripravena" muze legitimne
prijit znovu za hodinu, kdyz se mezitim stalo neco jineho - to je novy fakt.
## Co je v logu videt
Log se cte jako **prislo tohle a zpusobilo to tuhle zmenu**. Zmeny, ktere udela
beh automatizace, se radi pod jeho radek udalosti (`parentId`), takze nejde
zamenit, co zpusobilo co:
```
Prijata udalost: stav completed (automatizace TEST) 13:13:27
stav in-progress -> completed 13:13:27
stitky +hovor 13:13:27
Prijata udalost: stav completed 22x beze zmeny 13:13:34
```
U udalosti stoji, **kdo ji prinesl**. Prvni otazka nad zmenenym ticketem je
"kdo mi do toho sahl" a odpoved `webhook` na ni neodpovida.
Data udalosti se ukladaji cela. Kdyz krok nema vlastni, ulozi se to, cim beh
zacal - u webhooku prijate telo. Prazdna udalost je horsi nez zadna: tvari se,
ze se neco stalo, a nerekne co.
## Konektor Tickety
Kategorie `servicedesk`, driv byl pod Nastroji. Ma obe strany:
+95
View File
@@ -2,6 +2,101 @@
Nejnovejsi nahore.
## 2026-08-17 - log rekne, co zpusobilo jakou zmenu
Nalezeno na bezicim serveru: ticket TK-4946 mel 177 prichozich udalosti
a 620 radku v logu, pritom se nestalo skoro nic. Zmereno proti behum ve fronte:
ve stejnem okne vzniklo **presne tolik behu, kolik prislo udalosti** (22 a 22),
kazdy s jednim pokusem. Fronta ani worker nic nenasobi - odesilatel poslal
177 POSTu. Nasi vinou bylo, ze to z historie neslo poznat.
### Opraveno
- **Data udalosti se konecne ukladaji.** `payload` byl u kazde udalosti prazdny,
protoze krok `ticket/upsert` ukladal jen to, co si clovek vyplni v poli Data.
Kdyz je prazdne, ulozi se **to, cim beh zacal** - u webhooku cele prijate telo.
Prazdna udalost je horsi nez zadna: tvari se, ze se neco stalo, a nerekne co.
- **Shodna udalost se pocita, nezaklada dalsi radek.** Kdyz prijde presne totez
co posledne, pricte se k pocitadlu (`repeats`, `lastAt`) a v portalu se u radku
ukaze "22x beze zmeny, naposledy ...". Ticket se pritom **nemeni**: neprepise
se `updatedAt` ani se nerozesle zmena, takze duplikat nerozbliká dashboard
a nespusti automatizaci navazanou na zmenu ticketu.
- Zahodit duplikat nejde. Bez pocitadla by nikdo nezjistil, ze proti nam neco
tluce ve smycce.
- Porovnava se **jen s posledni** udalosti. "Objednavka pripravena" muze
legitimne prijit znovu za hodinu - to je novy fakt.
- **Zmeny se radi pod udalost, ktera je zpusobila.** Log uz mel strom
(`parentId`), ale nikdo ho nepouzival. Zapisy behu se ted radi pod jeho radek
udalosti, takze log se cte jako "prislo tohle -> zmenilo to tohle".
- **U udalosti stoji, kdo ji prinesl**: `Prijata udalost: stav completed
(automatizace TEST)`. Prvni otazka nad zmenenym ticketem je "kdo mi do toho
sahl" a `webhook` na ni neodpovida.
- **Poznamka o stavu jen kdyz se stav zmenil.** Predtim se u kazde udalosti
zapsalo `Stav zmenen z in-progress na in-progress`, tedy tri radky logu na
jednu zpravu, ktera nic nezmenila. Odtud 620 radku.
- **Popisek udalosti uz neni porad "Udalost".** Bere se popisek, predmet, stav,
externi ID - v tomhle poradi. Casova osa, kde je na kazdem radku totez, nerika
nic.
- Typograficke uvozovky z popisku v logu pryc, plus ctyri AI znaky, ktere
zbyvaly v kodu (`web/src/data/products.ts`, `References.tsx`,
`automationStore.ts`).
### `runsToday` konecne znamena dnes
Bylo to pocitadlo od zalozeni automatizace, jen se jmenovalo "dnes" - na serveru
ukazovalo 373 za automatizaci, ktera bezi tri mesice.
- Automatizace si drzi **behy po dnech** (`days`, poslednich 14 dni). Po pulnoci
je "dnes" nula, dokud opravdu neco nebezi.
- Vedle toho `runsYesterday` a `runsTotal`. Puvodni cislo se neztratilo, jen se
spravne jmenuje.
- Uspesnost se pocita z dnesnich behu. Kdyz dnes zadny nebyl, bere se posledni
den, kdy byly - nula procent u automatizace, ktera dnes nemela co delat, by
vypadala jako porucha.
- V seznamu je pod dnesnim cislem vcerejsek, na detailu dnes, vcera i celkem.
## 2026-08-17 - prevzeti ticketu ze skupiny a pozvanky do firmy
### Pridano
- **Prevzeti ticketu.** `POST /tickets/:id/claim`. Kdo je ve skupine, ktera ma
ticket u sebe, si ho vezme sam. Prace se nerozdava shora, lidi si ji beru
podle toho, kdo ma cas.
- Vzit ticket, ktery uz nekdo resi, je neco jineho: to je prehozeni a chce
to pravo `ticket.assign.others`.
- Ticket bez resitele si vezme kdokoli, kdo je vedeny jako resitel.
- **Krok `ticket/assign-group`** (Predat skupine) s prepinacem
**Priradit rovnou nejvolnejsimu**. Prazdne nebo Ne = ticket zustane ve fronte
skupiny. Prepinac je na kroku automatizace, ne na skupine: tataz skupina
potrebuje u havarie okamzite prideleni a u bezneho dotazu ne.
- **Pozvanky do firmy.** Spravce vytvori odkaz s nahodnym kodem
(`/pozvanka/:kod`), posle ho, jak chce. Kdo ho otevre, vyplni jmeno a heslo
a je uvnitr.
- **Heslo se nikdy neposila.** Nastavuje si ho sam clovek az za odkazem.
- Kdyz uz ucet ma, zada k nemu svoje heslo a jen se pripoji k dalsi firme.
Bez overeni hesla by kdokoliv s odkazem pripojil cizi adresu ke sve firme
a videl by jeji data.
- Pozvanka plati tyden, da se zrusit a po pouziti prestane platit sama.
- Volitelne z cloveka rovnou udela resitele. Ucetni muze mit pristup do
portalu, aniz by kdy resila ticket, proto se to pta.
### Zmeneno
- **Resitele, skupiny a pozvanky jsou na strance Lide**, ne v nastaveni.
Pozvat kolegu je bezna denni prace, ne nastaveni portalu - dokud to bylo
schovane v nastaveni, nikdo to nenasel.
- **Cleny skupiny se vybiraji klikanim** ze seznamu lidi. Predtim se opisovala
ID `ppl_xxx` oddelena carkou, coz je preklep cekajici na sve misto.
### Nove soubory
| Soubor | Co dela |
| --- | --- |
| `src/data/invites.ts` | Entita pozvanky, kod, platnost. |
| `src/routes/invites.ts` | Verejne cesty (prohlednuti a prijeti) a sprava. |
| `web/src/pages/Invite.tsx` | Stranka za odkazem: jmeno, e-mail, heslo. |
| `web/src/components/dashboard/InvitePanel.tsx` | Sprava pozvanek v zalozce Lide. |
## 2026-08-13 - vyrizeno je vyslovny priznak, ne hadani ze stavu
### Zmeneno