Evidence času pro auditorskou firmu: 4 tiché chyby

Jsem Denys, full-stack a AI inženýr. Od května do října 2026 přešla jedna auditorská firma z nástroje, ve kterém mohl každý otevřít každého klienta, na evidenci času, kterou jsem pro ni postavil, v 388 commitech. Firmu tu nejmenuji. Tento text je pro lidi, kteří firmu vedou a vybírají jí nástroje: co auditorská firma od evidence času potřebuje, čtyři chyby, které jsem našel, a jak v kterémkoli nástroji ověřit, zda je nemá.

Co auditorská firma od evidence času potřebuje?

Auditorská firma prodává hodiny, takže evidence času je záznam, na kterém stojí celé podnikání. Firma, pro kterou jsem stavěl, potřebovala:

• Hodiny na klienta, projekt a úkol. Každý záznam patří k jedné zakázce, takže hodiny lze číst podle klienta, projektu i osoby.
• Týdenní výkazy práce se schvalováním. Zaměstnanci odevzdají týden, projektový administrátor každý záznam schválí nebo zamítne a započítají se jen schválené hodiny.
• Upomínky. Kdo má před termínem výkaz pořád prázdný, dostane e-mail. Od září 2026 upomíná jen chybějící hodiny a přeskakuje lidi s nulovou kapacitou.
• Plánování kapacit. Kdo bude v následujících týdnech pracovat na které zakázce, vzhledem ke kapacitě každého člověka.
• Důvěrní klienti. Vlastník může klienta, jeho projekty, úkoly i čas omezit na vybrané členy.
• Archivovat, nikdy nemazat. Člen, který odejde, se deaktivuje a anonymizuje, dokončený projekt se archivuje, takže historie výkazů zůstane celá.

Faktury nevystavuje. Typ fakturace a hodinové rozpočty projektů jsou za samostatným oprávněním a fakturace zůstává v účetním systému firmy.

Kdo má v auditorské firmě vidět čí hodiny?

Před tímto projektem mohl každý ve firmě otevřít každého klienta a hodiny všech ostatních. Pro auditorskou firmu je to nejdřív problém důvěrnosti a až potom softwarový problém: ne každý člen musí vidět každého klienta a nikdo nepotřebuje vidět týden kolegy, pokud ho neschvaluje.

Model přístupu, který firma potvrdila, vypadá takto:

Role	Vidí	Může schvalovat
Člen týmu	Jen vlastní hodiny	Nic
Projektový admin	Hodiny týmu na vlastních projektech	Týdny svého týmu na těchto projektech
Vlastník	Každého klienta, projekt i osobu	Vše
Důvěrný klient	Viditelný jen členům, které vybral vlastník	—

Vlastník upravuje každou roli v matici políček, oblast proti akci, a každé pravidlo žije v databázi, ne na obrazovkách, takže stránka nemůže ukázat, co databáze odmítá. Každé políčko se před vydáním testovalo na kopii produkce; jak a co ten test našel, je v článku jak testovat Supabase RLS.

Jednu otázku, na kterou matice neuměla odpovědět, přinesla sama firma. V červnu 2026 viděl člen s nejomezenější rolí na obrazovce plánování kapacit další členy a jejich projekty, ačkoli čekal, že uvidí jen sebe a jednoho kolegu. Má omezený člen vidět lidi na svých projektech? Pravidlo, na kterém jsme se shodli: ano, jen na sdílených projektech, s kapacitou a volnem ostatních skrytými.

Jak se dobrat modelu přístupu, se kterým firma skutečně souhlasí? Nepožádal jsem klienta, aby ho popsal z paměti. Poslal jsem dotazník o 72 otázkách v 9 sekcích, s mřížkami oprávnění už vyplněnými tak, jak živý systém fungoval 7. srpna 2026. Klient opravil, co bylo špatně, a každá změněná buňka byla označena. Lidé umějí lépe opravovat skutečnost než ji popisovat.

Chyba 1: součty ve výkazech by vycházely příliš nízké

Stránka Výkazy práce má pro celou firmu pohledy „Toto čtvrtletí“ a „Od začátku roku“. Načítaly všechny časové záznamy v rozsahu jedním požadavkem. API databáze za aplikací vrací nejvýše 1 000 řádků na požadavek a když se na 1 000 zastaví, nevyhodí chybu. Prostě vrátí prvních 1 000.

Supabase tuto výchozí hodnotu dokumentuje: projekty vracejí nejvýše 1 000 řádků, dokud se limit nezmění v nastavení API.

Jakmile by tedy firma v rozsahu překročila 1 000 záznamů, členové a týdny by z pohledu vypadávaly a součty by vycházely příliš nízké, aniž by na obrazovce cokoli upozornilo. Při asi 70 záznamech týdně měl pohled od začátku roku překročit 1 000 záznamů zhruba v polovině listopadu 2026. Audit kódu 24. září 2026 to našel dřív, než k tomu došlo. Oprava čte každý rozsah po stránkách a každý export výkazů se stránkuje stejně.

Jak ověřit svůj nástroj: vyberte dlouhé období, exportujte surové záznamy, sečtěte je sami a porovnejte se součtem ve výkazu. Pokud se liší, výkaz ořezává řádky.

Chyba 2: „Uloženo“, ačkoli se nic neuložilo

Když databáze změnu odmítne kvůli oprávnění nebo proto, že pravidlo vyžaduje dvoufázové přihlášení, může odpovědět „změněno 0 řádků“ bez jakékoli chyby. Asi 30 míst v aplikaci, která záznamy upravují nebo mažou, tuto odpověď četlo jako úspěch a zobrazilo „uloženo“. Člověk jde dál. Změna se nikdy nestala.

Oprava je selhat bezpečně: zápis, který nezasáhne žádný řádek, je chyba a jako chyba se zobrazí, a test teď ověřuje, že s ním tak zachází každá cesta zápisu.

Jak ověřit svůj nástroj: přihlaste se jako člen bez práva něco upravit, zkuste to upravit a pak stránku obnovte. Pokud jste viděli „uloženo“ a vrátila se stará hodnota, nástroj o ukládání lže.

Chyba 3: důvěrný klient unikal přes výkazy

Některé zakázky znají jen lidé, kteří na nich pracují. Od 24. srpna 2026 může vlastník omezit klienta na jmenované členy. Všichni ostatní o tomto klientovi, jeho projektech, úkolech ani čase nedostanou nic. Vlastník má přístup vždy a ten se počítá z toho, kdo dnes roli vlastníka drží, neukládá se, takže se přesune s rolí.

Skrýt klienta v seznamu klientů bylo snadné. Úniky byly v postranních dveřích. Revize 8. září 2026 zjistila, že:

• tři funkce pro výkazy omezení ignorovaly, protože běží s právy, která obcházejí běžná pravidla přístupu, takže se hodiny důvěrného klienta mohly objevit ve výkazech;
• počty použití štítků v administraci štítků počítaly projekty a úkoly důvěrného klienta, čímž prozradily, že zakázka existuje, a přibližně jak je velká;
• chybové hlášky rozlišovaly: pokus změnit skutečný, ale skrytý záznam vrátil „forbidden“, pokus o vymyšlený vrátil „not found“, takže kdokoli mohl zkoušet, zda důvěrný klient existuje.

Všechny tři teď používají stejnou kontrolu jako hlavní tabulky a skrytý záznam vypadá přesně jako neexistující. Přesun projektu nebo záznamu pryč od důvěrného klienta také vyžaduje vlastníka nebo samostatné oprávnění a každý takový přesun se zapisuje do protokolu.

Jak ověřit svůj nástroj: omezte jednoho klienta na jedinou osobu. Pak jako někdo jiný spusťte každý výkaz, projděte každý počet a filtr, vyhledejte jméno klienta a otevřete přímý odkaz na jeden z jeho projektů. Nenajdete po něm žádnou stopu, ani v chybové hlášce.

Chyba 4: zamítnutí mohlo skrýt pozdější schválení

Týden může mít záznamy na více projektech, takže ho schvaluje více lidí. Pokud jeden projektový admin zamítl záznam a jiný později schválil svou část, pozdější schválení mohlo uzavřít celý týden a zamítnutí zakrýt. Stejně ho mohlo skrýt přesouvání záznamů mezi úkoly nebo znovuotevření týdne.

24. září 2026 se logika schvalování změnila tak, že týden zůstává zamítnutý, dokud existuje jakýkoli živý zamítnutý záznam, a projektový admin smí zamítnutý záznam archivovat jen tehdy, když ho zamítl sám. Databázová sonda teď spouští každý z těchto případů a každý musí vyjít PASS.

Jak ověřit svůj nástroj: použijte dva schvalovatele jednoho týdne. Jako první zamítněte jeden záznam, jako druhý schvalte všechno ostatní a podívejte se, v jakém stavu týden skončí.

Koupit, nebo postavit evidenci času pro auditorskou firmu?

Nejdřív kupte. Toggl, BigTime, ZenWorkflow a podobné nástroje už pokrývají časovače, týdenní schvalování i fakturaci klientům a začít s nimi můžete ještě tento týden. Vlastní nástroj dává smysl, když firma má pravidla, která produkty neumějí vyjádřit, například důvěrné klienty viditelné jen jmenovaným členům, schvalování týdne více projektovými adminy nebo role, které si vlastník chce tvarovat políčko po políčku.

Ať půjdete jakoukoli cestou, čtyři kontroly výše zaberou odpoledne a řeknou vám víc než seznam funkcí. Každá stránka produktu slibuje „granulární oprávnění“. Málokterá ukáže, co se stane, když políčko odškrtnete.

Meze této zprávy

• Jedna firma. Model přístupu, objem asi 70 záznamů týdně a dotazník pocházejí z jediné firmy.
• Chyba 1 byla zachycena dřív, než nastala. Datum poloviny listopadu je projekce z tempa záznamů firmy, ne naměřený incident.
• Žádná fakturace. Nástroj drží hodiny, typ fakturace a hodinové rozpočty, ale klienty nefakturuje, takže se nemohu vyjadřovat k procesům od času po fakturu.

Přístupová pravidla jsou tu Postgres row-level security. Dvě díry, které matice rolí nezachytí, jsou popsané zvlášť: uživatel, který patří do dvou organizací a IF, který při NULL selže otevřeně. Samotná stavba je v případové studii evidence času pro auditorskou firmu a tento druh práce spadá pod interní nástroje a dashboardy.