Files

T

JiriUhlirandClaude Opus 5 a771834e57 Realne sluzby, OpenAI, odesilani e-mailu a helpdesk

Katalog srovnany s tim, co opravdu bezi na services.csbot.cz/apps:
trinact sluzeb dostalo pristupove udaje a levne cteci overeni, opravena
appId, ktera nikam nevedla (ppl, microsoft365, transcription), a GA4,
Search Console, Google Ads i Sklik ted stoji na aplikaci analytics,
kazda s vlastnimi udaji. Nove sluzby SAP Business One, Google Workspace
a Meta Ads. K tomu 23 skriptu, ktere s nimi opravdu neco delaji.

OpenAI jako prvni sluzba, ktera nebezi u nas: Service.baseUrl s absolutni
adresou, prepis pres <SLUZBA>_BASE_URL nebo adresu u konektoru, predpona
hlavicky u pole udaju (uzivatel vlepi holy klic, Bearer dopise runtime).
Dotaz na model, nahrani souboru, otazka nad souborem, prepis zvuku.
Skript umi odeslat soubor pres ctx.http.postForm (multipart, obsah Base64).

Sluzba E-mail pres SMTP. Neni to skript, ale vnitrni krok - SMTP neni HTTP.
Konektor nese schranku firmy, krok ma HTML telo, ve kterem se dosazene
hodnoty escapuji (znacky autora sablony jsou zamer, ostre zavorky od
zakaznika ne). Overeni konektoru se prihlasi na server a nic neodesle.

Helpdesk: Ticket.helpdeskSourceId drzi firmu, ktera pozadavek poslala,
vlastnikem zustava ta, ktera ho resi - jinak by ho resitel nemel ve sve
fronte. Komu pozadavek pripadne, urcuje Tenant.helpdeskProviderId.
Zadavatel vidi jen svoje pozadavky a smi k nim pripsat komentar.

Opravy v portalu:
- hlasky o ulozisti a odchozi IP vidi jen spravce platformy
- typ ticketu se v automatizaci vybira ze seznamu firmy, nebo dosadi z dat
- stav ticketu je otevreny naseptavac, ne ciselnik
- ticket jde zalozit rucne, zakaznik u nej neni povinny
- kanal se prejmenoval a parametry u webhooku jsou oznacene jako nepovinne
- srovnane markdown tabulky v cele dokumentaci

Co z teto davky jeste neni: prepinac firmy je porad jen stav uvnitr stranky
Prehled, takze se prepnuti neprojevi v Lidech ani jinde.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-26 07:40:16 +02:00

7.0 KiB

Raw Blame History

Nastavení, práva, typy ticketů, akce a widgety

Co všechno se dá nastavit z portálu a proč je to postavené takhle. Model je z 09-navrh-rozsireni.md, tady je hotový stav. Seznam funkcí a komponent, které se u toho mají použít, je v 15-rejstrik-funkci.md.

Jedna vrstva pro všechny záznamy

Firmy, uživatelé, role, řešitelé, skupiny, typy ticketů, akce a widgety mají společné to, že se u nich dělá totéž: seznam za firmu, detail, zápis, mazání, kontrola práva, zápis do auditu. Napsat to osmkrát znamená osm skoro stejných souborů, ze kterých se jeden opraví a ostatní ne.

Proto tři vrstvy, každá napsaná jednou:

Vrstva	Kde	Co dělá
Úložiště	`src/data/store/`	`EntityStore<T>` a dvě implementace. Volající nepozná, jestli běží Postgres nebo JSON soubor.
API	`src/routes/crud.ts`	`crudRouter` vyrobí pětici endpointů včetně práva a auditu.
Klient	`components/dashboard/EntityAdmin.tsx`	Tabulka, modál, validace, mazání.

Nová entita v nastavení pak znamená: defineStore v modulu entity, jeden řádek v bootstrap.ts, jeden crudRouter v settings.ts, jeden popis v Settings.tsx. Nic víc.

Práva jsou data

Práv je 26 a jsou v katalogu (src/data/permissions.ts). Role je záznam, ne konstanta v kódu: firma si může udělat vlastní roli s vlastní kombinací práv. Systémové role (admin, agent, viewer) se měnit nedají, aby si nikdo neodebral právo, kterým je odebírá.

Členství uživatele ve firmě nese roleIds, protože jeden člověk může být v Automii řešitel a u Nordisu správce jejich servicedesku.

Neznámé právo se odmítne už při ukládání role. Kdyby se jen ignorovalo, překlep by znamenal roli, která tiše nic nesmí.

Navigace chodí ze serveru

Co uživatel vidí za záložky, je průnik dvou věcí:

co má firma zaplacené a zapnuté (tenantFeatures),
na co má člověk právo.

Počítá to server (navFor) a klient jen kreslí. Kdyby si klient záložky dovozoval sám, počítalo by se to na dvou místech a jednou by se to rozešlo - a ta chyba by znamenala odkaz do 403.

Typy ticketů a tagy

Typ ticketu nese vlastní pole (klíč, popisek, typ, povinnost, nápověda) a může mít vlastní workflow stavů. Tag je volné označení bez polí za ním.

Rozdíl není kosmetický:

Typ znamená "za tímhle stojí data". Objednávka má číslo objednávky a částku, takže se na ni dá navázat akce, která ta data potřebuje.
Tag znamená "takhle si to označuju". Hodí se na filtry a widgety.

Akce se proto váže na typ nebo tag, ale akci s daty má smysl vázat na typ.

Pole object a list se v detailu ticketu ručně nevyplňují - plní je automatizace. Textarea s JSONem by tam byla past, ne pohodlí.

Vydefinované akce

Akce a automatizační stromy jsou dvě různé věci a nemají mezi sebou žádnou společnou mezivrstvu. Automatizace běží sama, akce je tlačítko, které zmáčkne člověk.

Tělo akce je jedno z trojice:

Tělo	Kdy	Příklad
Operace konektoru	běžný případ	odeslat objednávku do iDokladu
Vlastní strom	akce má víc kroků a rozhodování	dohledat kontakt, vystavit fakturu, odeslat e-mailem
Skript	nic z toho nestačí	vlastní výpočet nebo cizí API, které v katalogu není

Server vrací k ticketu jen akce, které v té situaci opravdu jdou spustit: sedí typ nebo tag, projdou podmínky a volající na ně má právo. Klient nefiltruje nic.

Spuštění akce vrací 200 i když akce selhala - selhání akce není chyba API. V odpovědi je celé chybové hlášení a celý průběh se zapíše do logu ticketu.

Vestavěné akce (typ, tagy, skupina, přiřazení, stav, komentář) jsou zvlášť: mění ticket sám, ne cizí službu, a každá má vlastní právo.

Vlastní widgety

Widget je definice zdroje dat plus způsob zobrazení. Zdroj je ticket nebo automatizace, k tomu filtr a případné seskupení (podle stavu, kanálu, řešitele, typu, tagu).

Data pro celý přehled chodí jedním requestem. Deset dlaždic nesmí znamenat deset dotazů.

Viditelnost je stejná jako u služeb: všichni, konkrétní firmy, konkrétní lidé, nebo jen správce.

Přepnutí na jiný účet

Správce platformy se může podívat na portál očima konkrétního uživatele. Dvě věci, na kterých to stojí:

Výchozí je jen pro čtení. Podívat se, co klient vidí, je mnohem častější než za něj něco měnit, a nechtěný zápis pod cizím jménem je to nejhorší, co se tady může stát. Zápis se musí zapnout vědomě a middleware ho jinak odmítne u všeho kromě GET.
Všechno je v auditu včetně toho, kdo to doopravdy byl. Bez auditu nemá přepínání účtů co dělat v produktu.

Svůj původní token si klient odkládá do sessionStorage. Server o něm nic neví, takže ho nemůže ani omylem prodloužit.

Co se ukládá a co se drží v paměti

Data	Jak	Proč
Firmy, uživatelé, role, řešitelé, skupiny, typy, akce, widgety, záložky	`withCache`	Čtou se při každém requestu, mění se zřídka. Kopie v paměti, obnova po zápisu.
Tickety včetně logu, automatizace, incidenty, rozložení dashboardu	`withMirror`	Mění se v paměti za provozu, po každé změně se celý záznam zapíše.
Audit	přímo do úložiště	Jen se připisuje, nikdy nečte při každém requestu.
Konektory	vlastní úložiště	Nesou šifrovaná tajemství a potřebují částečný unikátní index. Viz 14-databaze.md.

Čítače ID se při startu dopočítají z uložených záznamů, takže nový ticket nikdy nepřepíše starý.

7.0 KiB Raw Blame History