Resitel je clenstvi uctu, firma z ARES, prepinani jazyku schovane

Resitel uz neni vlastni zaznam spojeny s uctem pres e-mail: je to
clenstvi uctu ve firme a jeho ID je ID uctu. Popisek, kapacita, externi
ID a zapnuti visi na clenstvi, takze clovek ve dvou firmach je v kazde
jinak a spravce firmy ho vypne jen u sebe. Odebrani z firmy odebere jen
clenstvi. Stara data se pri startu jednou prevedou (migratePeople.ts),
vcetne odkazu v ticketech, skupinach, automatizacich, akcich a widgetech.
Sprava lidi v zalozce Lide zaklada ucty, pozvanka uz nema volbu resitele.

Zalozeni firmy z registru ARES: hledani podle IC nebo nazvu, dotazeni
IC, DIC, sidla a pravni formy, vyber soucasnych statutarnich zastupcu
a prokury, ucty spravce firmy s nahradnim e-mailem IC-poradi@placeholder.cz.
Vychozi rozlozeni dashboardu bez resitele neobsahuje list.myTickets.

Prepinani jazyku je docasne schovane (MULTILANG_ENABLED), web je cesky.
Dokumentace aktualizovana.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

documentation/06-tickety.md

@@ -99,17 +99,53 @@ neprirazeny.
 
 `src/data/people.ts`
 
-Resitel je oddeleny od uzivatele. **Uzivatel** je ten, kdo se prihlasi do portalu,
-**resitel** je ten, na koho jde ticket. Casto je to tyz clovek, ale ne vzdy -
-technik muze mit tickety a do portalu se nikdy neprihlasit.
+Resitel je **clenstvi uctu ve firme**, ne vlastni zaznam. Kazdy clen firmy
+muze mit tickety u sebe a ID resitele je ID uctu (`usr_...`). `Person`
+(`src/shared/people.ts`) je jen pohled pro API, sklada ho `personView`:
 
-Spojka mezi obojim je e-mail. Podle ni funguje filtr "moje tickety"
-(`?assignee=me`). Kdyz prihlaseny ucet zadnemu resiteli neodpovida, filtr se
-v portalu nabidne jako nedostupny misto toho, aby vracel prazdno bez vysvetleni.
+| Pole                      | Odkud                                  |
+| ------------------------- | -------------------------------------- |
+| `id`                      | ID uctu                                |
+| `tenantId`                | firma clenstvi                         |
+| `name`, `email`           | ucet                                   |
+| `role` (popisek), `capacity`, `externalIds` | clenstvi (`Membership` v `src/shared/users.ts`) |
+| `enabled`                 | stav uctu                              |
+| `roleIds`                 | role clenstvi                          |
 
-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.
+Jeden pohled na jedno clenstvi: tentyz clovek ve dvou firmach je v seznamu
+dvakrat, pokazde se stejnym `id` a jinym `tenantId`. Nic se tu neuklada,
+vsechno se odvozuje z kopie uctu v pameti (`src/data/users.ts`).
+
+Driv to byly dve veci. **Uzivatel** se prihlasoval, **resitel** mel u sebe
+tickety a spojka mezi nimi byl e-mail. To byla chyba: e-mail je prihlasovaci
+jmeno, ktere spravce muze zmenit, a tim se vazba tise rozpadla - clovek
+prestal videt "moje tickety" a nikdo nevedel proc. Prvni priznak byl, ze lide
+zalozeni z ARES nebyli v Lidech videt. Spojovat pres ID misto e-mailu by
+znamenalo dal drzet dva zaznamy o jednom cloveku, tak se slily do jednoho.
+
+**Technik bez uctu uz neexistuje.** Kdo ma mit tickety, dostane ucet. Kdyz
+spravce nezada heslo, vygeneruje se nahodne a ucet se nemusi nikdy prihlasit;
+az bude chtit, heslo si nastavi pres pozvanku nebo mu ho zmeni spravce.
+
+Filtr "moje tickety" (`?assignee=me`) tak nic nedohledava: `personIdFor` vrati
+ID uctu, kdyz ma ve firme clenstvi, jinak `null`. Spravce platformy bez
+clenstvi resitelem neni a filtr se mu v portalu nabidne jako nedostupny misto
+toho, aby vracel prazdno bez vysvetleni.
+
+Kazdy resitel ma `capacity` (vychozi 8), 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. Kapacita i popisek visi
+na clenstvi, ne na uctu: v jedne firme je clovek dispecer s kapacitou 6,
+v druhe ucetni s kapacitou 3.
+
+Sprava je v zalozce **Lide** pod pravem `people.manage`. Spravce firmy tam
+zaklada ucty (nebo prida clenstvi uctu, ktery uz s tim e-mailem existuje),
+upravuje jmeno, e-mail, popisek, kapacitu, externi ID a role clenstvi
+a odebira clenstvi. Ucet, ktery po odebrani nema zadne clenstvi a neni
+spravce platformy, se vypne. Prepinac `enabled` v Lidech je **za clenstvi**:
+vypnuty se v teto firme nenabizi k prirazeni, stare tickety mu zustanou
+a v jinych firmach pracuje dal. Cely ucet vypina jen sprava uzivatelu.
+`Person.enabled` je proto `ucet.enabled && clenstvi.enabled !== false`.
 
 ## Fronta skupiny a prevzeti
 
@@ -145,9 +181,9 @@ zalozi ucet a posle heslo. Duvody:
   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.
+U pozvanky se rovnou rekne, jake role clovek dostane. Resitelem je kazdy
+clen firmy, takze zadna dalsi volba neni potreba; stary priznak `asPerson` se
+prijme a ignoruje, aby starsi klient dal fungoval.
 
 Sprava je v zalozce **Lide**, ne v nastaveni: pozvat kolegu je bezna denni
 prace.