permissionsOf(user) scitalo role pres vsechna clenstvi, takze kdo byl spravce v jedne firme, jednal jako spravce ve vsech, kam patril. Uzivatel ve dvou firmach je vzacny, dusledek ne. - firma je povinny argument u permissionsOf, hasPermission i hasAnyPermission. Zamerne povinny: kdyby byl nepovinny, prvni volani bez nej by tise vratilo vsechna prava. Prekladac tim rovnou nasel vsech ctrnact mist, ktera se ptaji. - kazde misto se pta za tu spravnou firmu: akce nad ticketem za firmu toho ticketu, uprava zaznamu za firmu toho zaznamu, zalozky a helpdesk za firmu, kterou ma clovek prepnutou - cizi firemni role se ignoruje, i kdyby na ni clenstvi odkazovalo. Jinak by stacilo pripsat si ji do clenstvi v jine firme a prava by se prenesla. - cache prav ma v klici firmu - readScope cte z jedne firmy, te prepnute, ne ze vsech. V nastaveni se driv michaly typy ticketu a role napric firmami bez ohledu na vyber. Opraveno u toho: systemove role se pri startu srovnaji s kodem (syncSystemRoles). Vychozi sada se pouzije jen do prazdneho uloziste, takze nove pravo v katalogu se k uz bezici instalaci nikdy nedostalo - ticket.create ani obe prava helpdesku by spravci firmy nenabehla a zalozka Helpdesk by se neobjevila. Meni se jen prava, jen u nasich roli, nazvu se to netyka. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
8.1 KiB
07 - Firmy a prava
Dve ruzne "firmy"
Snadno se pletou, proto hned na zacatku:
- Tenant je firma, ktera portal pouziva. Ma v nem svuj tym, svoje tickety a svoje automatizace. Je to hranice viditelnosti.
ticket.customerje zakaznik toho tenanta, tedy kdo pozadavek poslal. S pravy nema nic spolecneho.
Tenanti jsou v src/data/tenants.ts.
Uzivatel muze byt ve vic firmach
Proto memberships, ne jedno tenantId. Typicky externista, ktery dela
servicedesk dvema klientum a v kazdem ma jinou roli.
interface User {
id: string;
email: string;
name: string;
platformAdmin: boolean; // vidi napric vsemi firmami
memberships: Membership[]; // { tenantId, role }
}
type TenantRole = 'admin' | 'agent';
Role je vzdy az uvnitr firmy. Pristup napric firmami je zvlast jako
platformAdmin - to je nase pravo, ne zakaznicke. Kdyby byla role jen jedna
globalni, nesla by tahle situace vubec zapsat.
Tri pohledy na tickety
| Pohled | Co ukazuje | Kdo smi |
|---|---|---|
all |
napric vsemi firmami | jen platformAdmin |
tenant |
cela jedna firma | kdokoliv, kdo do ni patri |
mine |
jen tickety prihlaseneho | kdo ma navazaneho resitele |
Posilaji se jako query: ?scope=tenant&tenantId=tnt_automia.
U tenant a mine je potreba vedet kterou firmu, protoze uzivatel jich
muze mit vic. Bez tenantId se pouzije prvni.
Prepinac firmy je nad celym portalem
Vybrana firma je jedna hodnota pro cely dashboard (web/src/lib/tenant.ts),
ne stav jedne stranky. Prepinac je v hlavicce nad obsahem a apiFetch doplnuje
tenantId do kazdeho dotazu na /api/dashboard.
Doplnuje se to v API vrstve schvalne, ne na strankach. Kdyz si to mela pridavat kazda stranka sama, vetsina na to zapomnela a server sahnul po vychozi firme - uzivatel se prepnul na LogiTrans a v Lidech koukal na lidi Automie. To neni nepohodli, to jsou cizi data pod hlavickou jine firmy.
Vyjimky, kdy se nedoplnuje:
| Kdy | Proc |
|---|---|
Cesta uz tenantId nese |
proklik z widgetu na konkretni firmu ma prednost |
scope=all |
pohled pres vsechny firmy, jedna firma tam nic neznamena |
| Neni vybrano | server pouzije vychozi firmu uctu |
Cesta mimo /api/dashboard |
prihlaseni a verejny web s firmou nepracuji |
Volba prezije obnoveni stranky (localStorage). Kdyz ulozena firma uz mezi
access.tenants neni - clovek z ni odesel, prihlasil se nekdo jiny na tomtez
pocitaci - spadne se na vychozi firmu uctu, aby kazdy dotaz nekoncil na 403.
Prava plati za firmu, ne za cloveka
permissionsOf(user, tenantId) pocita prava v jedne firme. Firma je
povinny argument: kdyby byla nepovinna, prvni volani bez ni by tise vratilo
vsechna prava, a presne takova chyba se nehleda.
Driv se prava scitala pres vsechna clenstvi. Znelo to rozumne - pravo je bud, nebo neni - ale znamenalo to, ze kdo je spravce v jedne firme, jednal jako spravce ve vsech, kam patri. Uzivatel ve dvou firmach je vzacny, dusledek ne.
| Kde se pta | Ktera firma rozhoduje |
|---|---|
| Akce nad ticketem | firma toho ticketu |
| Uprava zaznamu v nastaveni | firma toho zaznamu |
| Zalozeni ticketu, helpdesk | firma, kterou ma clovek prepnutou |
| Zalozky v navigaci | firma, kterou ma clovek prepnutou |
Rozdil mezi prvnimi dvema a zbytkem je zamer: kdo edituje zaznam jine firmy, musi mit pravo tam, ne tam, kde je zrovna prepnuty.
tenantId: null znamena "mimo firmu", tedy zadna zakaznicka prava. Deje se to
u uctu bez clenstvi. Spravce platformy ma vzdycky vsechno - to je nase pravo,
ne zakaznicke.
Cizi firemni role se ignoruje, i kdyby na ni clenstvi odkazovalo: jinak by stacilo pripsat si ji do clenstvi v jine firme a prava by se prenesla.
Systemove role se srovnavaji s kodem pri startu
Vychozi sada se pouzije jen do prazdneho uloziste. Nove pravo v katalogu by
se proto k uz bezici instalaci nikdy nedostalo: role_admin by zustala s vyctem
ulozenym pri prvnim startu a nova zalozka by se spravci firmy neobjevila.
syncSystemRoles() proto pri startu srovna prava systemovych roli s tim, jak
jsou napsane v kodu. Meni jen prava, jen u roli s tenantId: null a jen
u tech, ktere jsou v systemRoles(). Nazvu se to netyka (ten uz nekdo mohl
zmenit) a vlastnich roli firmy uz vubec.
Server je autorita
Vsechno rozhoduje src/data/access.ts, jedno misto pro cely portal. Kdyby se to
rozlezlo po routach, driv nebo pozdeji vznikne endpoint, ktery filtr zapomene.
GET /api/dashboard/access vraci, co uzivatel smi:
{
"scopes": ["all", "tenant", "mine"],
"tenants": [{ "id": "tnt_automia", "name": "Automia" }],
"defaultTenantId": "tnt_automia",
"canAssignOthers": true,
"personId": "ppl_uhlir"
}
Klient podle toho kresli prepinac. Nesmi si to dovozovat sam - jinak by se prava pocitala na dvou mistech a jednou se rozejdou.
Nikdy tise nezuzujeme
Pozadavek na pohled nebo firmu, na kterou uzivatel nema pravo, vraci chybu, ne potichu zuzeny vysledek:
| Situace | Odpoved |
|---|---|
| pohled bez opravneni | 403 |
| firma, do ktere nepatri | 404 |
| ucet bez firmy | 403 |
| prirazeni ostatnim bez prava | 403 |
Duvod: kdyby se pozadavek na cizi firmu jen prepnul na vlastni, uzivatel by koukal na cizi cisla v domneni, ze jsou spravna. To je horsi nez chyba.
Filtr v ulozisti je povinny
listTickets, listPeople a listAutomations maji tenantIds jako povinny
argument, ne volitelny. Zapomenuty filtr tak neznamena "vse", ale nezkompiluje se.
Zapis (assignTicket, updateTicketStatus, addComment, updateAutomation,
deleteAutomation) bere tenantIds taky. Cizi zaznam se chova jako neexistujici,
tedy 404, ne 403 - z odpovedi nemá jit poznat, ze takove ID vubec existuje.
Vyjimka je verejny webhook. Ten se autorizuje tokenem v adrese, ne prihlasenim, takze si automatizaci najde pres vsechny firmy.
Jedina vyjimka: helpdesk
Ticket patri jedne firme a to plati dal. U pozadavku z helpdesku ale figuruji
dve: vlastnikem je ta, ktera ho resi, a v helpdeskSourceId je ta, ktera ho
poslala. Zadavatel se k nemu dostane jen pres helpdesk a jen ke svym
pozadavkum; bezny seznam ticketu zustava vlastnikovi.
Neni to obchazeni hranice, je to druha cesta dovnitr s vlastnim scopem. Popis je v 18-ticketovaci-system.md.
Prirazeni jen v ramci firmy
assignTicket odmitne resitele z jine firmy. Jinak by ticket zmizel z prehledu
sve firmy a objevil se nekomu, kdo do ni nepatri.
Prehazovat praci mezi lidmi smi jen admin. agent si smi vzit ticket na sebe,
ale nemuze ho poslat kolegovi - to hlida canAssignOthers.
Demo ucty
Heslo je u vsech demo1234.
| Kdo je | |
|---|---|
admin@automia.cz |
spravce platformy, vidi vsechny tri firmy |
karel.vomacka@automia.cz |
agent v Automii, admin u Nordisu - dve firmy |
martin.kriz@automia.cz |
bezny resitel jedne firmy |
Druhy ucet je ten zajimavy: ukazuje prepinac firem i to, ze prava se lisi podle toho, ktera firma je prave zvolena.
Co chybi
| Chybi | Poznamka |
|---|---|
| Sprava clenstvi z portalu | memberships jdou zmenit jen v kodu |
| Pozvanky uzivatelu | zadny onboarding |
| Tenant u incidentu | incidenty jsou zatim spolecne, nefiltruji se |
| Tenant u konektoru | katalog je spolecny, napojeni se zatim neeviduje |
| Audit pristupu | odepreni se jen loguje, nikde se neuklada |