~~SLIDESHOW~~
# Prezentace: Co to vlastně děláme a jak to má fungovat?

Interní prezentace pro vývojářský tým ProfiSpis

Prosinec 2025, michal.rada@gem.cz

-----

{{page>egdilna:slide-dva-vyznamy-.spisove-sluzby}}

-----

{{page>egdilna:slide-tri-duvody-spisove-sluzby}}
{{page>egdilna:slide-o-cem-spisova-sluzba-je}}

-----

{{page>egdilna:slide-dokument-versus-udaj}}

-----

{{page>egdilna:slide-dva-druhy-dokumentu-a-essl}}

-----

{{page>egdilna:slide-faze-zivotniho-cyklu-dokumentu-prosteednictvim-procesu}}

-----
## Spisová služba podrobněji

Kdo je masochista, může si projít celou teoretickou kapitolu [[egdilna:cast-o-spisove-sluzbe-obecne]] Je tam třeba

* Detailní popis legislativy
* Jednotlivé závazné procesy spisové služby a jejich popisy
* Podrobnosti k [[egdilna:substack|egdilna:essl]]

-----
## Jak by to mělo správně fungovat (na tohle asi radši nekoukejte)

Hele,tohle není pro prohloubení deprese, ale jen vysvětlení jak to má fungovat

* Ryze entitní model, nepracuje se s daty, ale jen s entitami, neměnné core pak řeší datovou práci
* Rozdělit do jednotlivých funkcí a eventů (event se skládá z funkcí), funkce rovnou volá další funkce a technicky zajišťuje backend
* Vše je funkcemi měnitelné a proveditelné, frontendové funkce zajistí že se udělá jen to na co má uživatel či systém práva
* I sám ESSL je uživatel, automatizované úlohy se dělají jeho jménem
* Transakčí protokol je jen částí celkového auditního logu (viz Elektronická kniha záznamů v EIDAS)
* Oddělená podatelna (distribuuje nejen do ESSL) a výpravna (odesílá nejen z ESSL)
* Hlavním životním organismem je spis nikoliv dokument

--------

## Jak to můžeme dělat teď?

Možná v budoucnu najdeme prostředky na celý architektonický refactoring, nicméně teď alespoň:

* dělejme úplný auditní log se vším rozdělený do událostí a k tomu TP
* snažme se o entitní přístup, nepracujme přímo tvrdě s daty v tabulce, ale s entitou, zkusme backendové univerzální funkce pro práci s entitami
* při jakékoliv úpravě podatelny a výpravny ji pomalu připravujme na oddělené storage a metadata a a protokoly
* UI na frontendu skládejme z mikrofunkčních UI kousků pokud to jde a určitě u nových obrazovek
* verzujme všechno, vždycky a pořád - nikdy nevíme kdy se to bude hodit
* každá nová funkce by se měla programovat jako funkce a endpoint a UI by mělo postupně volat tyto funkce a ne řešit něco natvrdo