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:
co-authored by
Claude Opus 5
parent
fbe5b8ff6f
commit
f1e8253169
@@ -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 |
|
||||
|
||||
@@ -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).
|
||||
|
||||
@@ -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:
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user