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

3.7 KiB

Raw Blame History

08 - Widgety na prehledu

Kde se to nastavuje

/dashboard, tlacitko Upravit dashboard vpravo nahore. V rezimu uprav dostane kazdy widget listu s ovladanim:

vyber sirky (tretina, polovina, cela sirka),
sipky vlevo a vpravo pro poradi,
kos pro odebrani.

K tomu Pridat widget s nabidkou toho, co jeste na dashboardu neni, Vychozi pro vraceni do puvodniho stavu a Ulozit nebo Zrusit.

Dokud se neklikne na Ulozit, nic se neuklada. Zrusit vrati puvodni rozlozeni.

Ulozeni je za dvojici uzivatel a firma

Ne za uzivatele. Clovek ve dvou firmach chce v kazde videt neco jineho a smichat mu to dohromady by bylo horsi nez zadne nastaveni.

Klic je ${userId}:${tenantId}, uloziste je src/data/dashboardLayouts.ts. Kdo si dashboard jeste neupravil, dostane vychozi rozlozeni a custom: false.

Katalog widgetu

src/data/widgets.ts, stejny princip jako katalog konektoru: server je zdroj pravdy o tom, co jde na dashboard polozit.

interface WidgetDefinition {
  id: string;
  name: string;
  description: string;
  kind: 'stat' | 'chart' | 'ticketList' | 'incidentList' | 'workload';
  sizes: WidgetSize[];      // ktere sirky ma smysl nabizet
  defaultSize: WidgetSize;
  metric?: ...;             // jen u `stat`: ktere cislo ze souhrnu
}

sizes neni kosmetika. Graf v tretine sloupce se necte, proto tam tretinu nenabizime vubec, misto abychom cekali, ze si to uzivatel rozmysli.

kind rika klientovi, kterou komponentu vykreslit. Novy druh znamena i novou komponentu na webu, proto jich je zamerne malo a jsou obecne. Novy statisticky widget je naopak jen zaznam v katalogu, zadny kod navic.

Data si nacita prehled, ne widgety

Widget dostane data v propsu. Kdyby si je nacital sam, deset dlazdic by znamenalo deset stejnych dotazu na server.

Prehled drzi ctyri dotazy (souhrn, tickety, incidenty, vytizeni) a rozdava je vsem widgetum. Dlazdice, ktera zadna data nepotrebuje, o nich proste nevi.

Mrizka

Sest sloupcu, sirky mapuji na col-span: tretina 2, polovina 3, cela 6. Na uzkem displeji zabira vsechno celou sirku.

Pouzivaji se container queries (@container a @2xl:), ne sm: a lg:. Duvod je stejny jako u stromu automatizaci, viz 05-dashboard-a-builder.md, sekce o sirce karet.

Validace

Server overuje ulozene rozlozeni proti katalogu:

Situace	Vysledek
neznamy widget	400
sirka, kterou widget nepodporuje	400
duplicitni ID instance	400
vic nez 12 widgetu	400

Neulozit je tady spravne. Klient by dostal zpatky neco, co neumi vykreslit.

Widget, ktery mezitim z katalogu zmizel, se v prehledu ukaze jako cervena karta s jeho ID. Nesmi tise vypadnout z rozlozeni.

Zaznam do widgets v src/data/widgets.ts.
Kdyz je to stat, pridat i metriku do metricMeta v WidgetCard.tsx a pole do souhrnu, pokud tam jeste neni.
Kdyz je to novy kind, dopsat vetev do WidgetCard.tsx.

Nabidka i rozlozeni ho vezmou automaticky.

Co chybi

Chybi	Poznamka
Drag and drop	poradi se meni sipkami, stejne jako ve strome
Nastaveni jednotlivych widgetu	napr. kolik radku ukazat, za jake obdobi
Vlastni metriky	katalog je pevny, nejde si nadefinovat vlastni
Sdilene rozlozeni pro firmu	kazdy si upravuje jen to svoje
Databaze	rozlozeni je v pameti, restart je vrati na vychozi

3.7 KiB Raw Blame History