Správní informační systém: Technická specifikace

Systém v řadě případů zobrazuje různě dlouhé seznamy položek. Pokud si má uživatel ze seznamu některé položky vybrat, nebo může na některé položce vyvolat akci (například upravit, smazat), pak pro tyto seznamy platí následující pravidla.

Veškerá nastavení zobrazení seznamů jsou trvalá a společná pro daný druh zobrazení. Vždy je možné se u daného zobrazení vrátit k výchozímu nastavení. Změny v nastavení se ukládají odděleně alespoň pro přehledy uvedené níže a aplikují se vždy pouze pro konkrétního uživatele.

U dokumentů a případů se uchovávají předcházející verze jejich stavu. Uživatel si může zobrazit výpis jejich stručných shrnutí, ze kterých jsou patrné alespoň autor, míra a povaha změny. Dále si může libovolnou předešlou verzi zobrazit, případně ji porovnat s jinou.

Pro rychlou orientaci je také vždy možné zobrazit porovnání aktuální verze dokumentu s verzí předchozí, případně aktuální revize s předchozí. V případě otevření dokumentu skrze odkaz získaný automatickým upozorněním na změnu je uživateli zobrazen popis změny mezi revizemi.

Každá stránka zobrazující uživatelská data (například dokumenty, případy či přehledy) podporuje stažení PDF verze pro tisk. Ta vzniká na serveru pomocí zvláštní HTML šablony a CSS stylů. Jak šablonu, tak styly je možné přizpůsobit a tím dosáhnout souladu vzhledu tištěných výstupů s vizuálním stylem organizace.

Kromě centrálních předloh je možné nastavit oddělené předlohy i pro jednotlivé typy dokumentů a případů. Předlohy pro tisk komponent jsou vždy vlastní danému typu komponenty.

V případě potřeby je možné pro konkrétní typ dokumentu stanovit další šablony pro tisk. Tyto šablony z dokumentu čerpají po datové stránce, ale formu určují zcela samostatně. Typickým příkladem využití je například příprava posudku k odeslání poštou.

Uživatel může získat některá data, ke kterým má přístup, i ve strojově čitelné formě. Data dokumentů je možné stáhnout ve formátech JSON, YAML a XML. Data pohledů je možné získat ve formátech JSON, YAML a pokud to umožňuje druh datového zdroje (data představují soubor tabulek), tak i ve formátech CSV (jednotlivé tabulky) nebo XLSX (tabulky jako jednotlivé listy).

Pracovní přehled je výchozí stránka uživatele po jeho přihlášení, nesměřuje-li do jiné části systému. Hlavním prvkem stránky je seznam případů, do kterých má uživatel přístup, seřazený dle jeho schopnosti přispět a dále dle jejich naléhavosti.

V prvních dvou bodech jsou případy řazeny podle nejčasnějšího termínu dokončení dokumentů, díky kterým je případ na dané pozici. Dokumenty z třetího bodu neexistují a není tedy možné u nich sledovat termíny a zbylé případy může uživatel pouze komentovat.

Na zvláštní stránce přehledu událostí jsou každému uživateli předloženy ty události, na které byl, nebo mohl být upozorněn. Jednotlivé řádky umožňují uživateli přihlásit se k nebo odhlásit se z odběru daných událostí.

Přehled by měl sloužit pro rychlou orientaci v běžících případech a získání přehledu o situaci.

Na zvláštní stránce oblíbených položek bude zobrazen seznam případů a sestav, které si daný uživatel dříve oblíbil. Oblibovací tlačítko je zobrazeno na stránce případu i sestavy. Skrze odkazy na této stránce se může uživatel snadno přesunou na daný případ či přehled bez nutnosti jej hledat.

Za účelem snazší orientace uživatelů jsou veškeré objekty v systému roztříděny do témat a tematických sekcí. Toto členění nemá žádné důsledky pro funkci, ani pro řízení přístupu. Také nijak nesouvisí s organizačním členěním.

Sekce slouží k seskupení několika témat. Není běžné, aby se věci opakovaly v různých sekcích, ale není to vyloučeno. Příkladem sekcí mohou být například Finance, Legislativa a Vnější ukazatele. V sekci Finance se setkáme s vícero tématy, v sekci Legislativa najdeme jen hlavní téma s případy pro práci s Vnitřními předpisy a konečně v sekci Vnější ukazatele nenajdeme sice žádné případy, ale zato se zde v hlavním tématu setkáme s řadou pohledů na data získaná při provozu instituce, například Návštěvnost, nebo Skladbu uživatelů.

Téma seskupuje pohledy a sestavy, které mají za úkol poskytnout informace o stavu určité oblasti (Rozpočet, Smlouvy) a dále zprostředkovává správu případů a dokumentů, které umožňují tento stav ovlivňovat (Změna rozpočtu, Zanesení nové smlouvy).

Pokud to dává smysl, mohou se věci v tématech opakovat. Například určité pohledy mohou být přínosné pro více témat, některé případy mohou souviset s vícero tématy a podobně. Názorným příkladem budiž Nákup, který zasahuje jak do Rozpočtu, tak do Smluv.

Pohledům je v rámci daného tématu věnován hlavní prostor. Některé pohledy jsou interaktivní, takže je možné s nimi manipulovat a dovídat se tak nové souvislosti. Například pokud pohled zobrazuje mapu, je možné s ní pohybovat, přibližovat ji nebo ji oddalovat. Pokud jsou na mapě interaktivní objekty, je možné je aktivovat a zkoumat jejich detaily.

Některé pohledy mohou umožňovat přímo spustit nový případ, nebo se odkazovat na existující případy a dokumenty. Tyto vazby bývají obvykle realizovány odkazy, které může uživatel otevřít v nové záložce prohlížeče.

Na stránce každého tématu je vyhrazen prostor, ve kterém se nacházejí odkazy jednak na systémové a dále také na daným uživatelem vytvořené sestavy pohledů.

Ze stránky tématu je možné aktivovat editor sestav, který umožňuje na stránku uspořádat výběr z pohledů, ke kterým má uživatel přístup. Těmto pohledům je následně možné interaktivně nastavit potřebné zobrazení. Takto připravenou sestavu je následně možné uložit, nebo případně jen vytisknout.

Pokud téma obsahuje alespoň jeden typ případu, je na jeho stránce k dispozici přehled případů, ke kterým má aktuální uživatel přístup. Je-li k tomu uživatel oprávněn, tak se zde také nachází prvek, který umožňuje zahájit nový případ.

Z přehledu jsou patrné základní údaje o případech a zdali do nich může uživatel zasáhnout, případně je-li to po něm požadováno. Typy případů se rozumí zpracování obchodního případu, jako jsou nákupy a veřejné zakázky, žádost o vyjádření k území nebo společná příprava složitých stanovisek.

Pokud téma obsahuje prostřednictvím přiřazených typů případů alespoň jeden typ dokumentu, je na jeho stránce k dispozici přehled dokumentů, ke kterým má aktuální uživatel přístup. Pokud je k tomu uživatel oprávněn, může z tohoto přehledu zahájit změnu dokumentu či vytvořit nový.

Z přehledu jsou patrné základní údaje o dokumentech. Dá se z něj také zjistit, do kterých případů vstupují, má-li k nim aktuální uživatel přístup.

Část systému umožňující uživateli přizpůsobit si systém dle svých potřeb. Uživatel si zde může zvolit jazyk uživatelského rozhraní a způsob upozorňování na události v systému. Upozornění týkající se dokumentů a případů je možné omezit na jejich konkrétní typy.

Více o upozorněních naleznete v kapitole Upozornění na událost.

Část systému umožňující správci nastavit jednak výchozí uživatelské předvolby, ale také případná obecná nastavení.

Mapové komponenty jsou tvořeny mapovým oknem, sloužím k zobrazování podkladových map a tematických vrstev, navigaci v mapě a zákresu nové datové vrstvy. Jejich funkce se liší dle konkrétního účelu a použití. Některé mapové komponenty mohou sloužit například pro účely zákresu zájmového území, jiné pak pouze k zobrazení vybraných dat v mapě, další pak k práci s body zájmu.

Z důvodu zachování otevřenosti systému je doporučeno mapové komponenty implementovat pomocí nástrojů OpenLayers.

Dalším typem komponent jsou tak zvané číselníky. V jiných systémech se využívá zvláštních tabulek, které spravuje správce systému, které se využívají jako zdroj voleb pro určité vlastnosti dokumentů.

SpIS počítá s potřebou spravovat životní cyklus položek číselníku a proto tento mechanismus odděleně nezavádí. Pokud určitý dokument obsahuje vlastnost, která nabývá hodnoty z určité množiny, využije se prostý odkaz na jiný dokument patřičného typu.

Řada pohledů využije interaktivní grafické komponenty jakými jsou běžné typy grafů, ale i kartogramy, kartodiagramy a časové osy. Pro všechny tyto druhy komponent platí, že je možné přepínat zahrnutí hodnot dle předem nastavených dimenzí.

V tabulkových zobrazeních je možné omezit zobrazované řádky na takové, které hodnotami v určitých sloupcích vyhovují nastavenému filtru. Je možné použít jak výčet hodnot, tak i vzory včetně těch regulárních. Je možné hledat i fulltextově. Řádky je také možné řadit dle libovolného počtu sloupců.

Pro určené sloupce je v patičce tabulky přítomný součet všech hodnot v daném sloupci a dále také součet hodnot, které jsou aktuálně viditelné.

Pro přípravu rozpočtových dokumentů existuje několik zvláštních komponent, které umožňují sestavovat rozpočet na základě podkladů (závislostí) a ručních oprav. Součástí těchto specializovaných komponent může být souhrnná tabulka nebo jeden či více diagramů, které poskytnou rychlou orientaci ve výsledné finanční situaci.

V rámci implementační analýzy budou upřesněny požadavky na vývoj speciálních komponent.

Dokumenty mohou záviset pouze na jiných dokumentech, a to vždy v určitých rolích.

V příkladu je předávací protokol použit nejprve pro dokumentaci zahájení zápůjčky věci a následně bude použit pro dokumentaci jejího navrácení. Pro správné vyložení závislého dokumentu zápůjčka je podstatné tyto dva protokoly od sebe odlišit.

Oproti instancím (dokumentům) mohou typy záviset pouze na dalších typech (nebo typových třídách, které jsou vysvětleny níže). Pro některé situace může být užitečné, aby dokument závisel na určitém počtu zcela libovolných dokumentů, bez ohledu na jejich typ.

Za povšimnutí stojí uvedení dokumentů, které by měly být přítomny, ale v příkladu výše zatím schází. Také jsou zde u rolí uvedeny kvantifikátory.

Závislosti je nutné kvantifikovat. V určité roli může vystupovat konkrétní počet dokumentů.

Jak budou vypadat typy pro tuto strukturu?

Kvantifikátor {1,} zde značí přítomnost alespoň jednoho dokumentu daného typu v dané roli. Je však možné specifikovat libovolný rozsah, tedy například {,} nebo {0,} pro libovolný počet dokumentů, {1,3} pro jeden až tři dokumenty a {,5} nebo {0,5} pro až pět dokumentů.

Typové třídy popisují dílčí strukturu dokumentů tak, aby mohlo dojít k použití více typů dokumentů ve stejné roli. Popisují virtuální strukturu dokumentů a upravují jejich závislosti.

Virtuální strukturou se zde rozumí to, že definují mapování mezi sadou virtuálních vlastností připadajících dané typové třídě a vlastnostmi dokumentu typu, který danou typovou třídu implementuje. Závislé dokumenty se pak mohou odkazovat na tyto virtuální vlastnosti bez ohledu na to, kde se nachází.

Můžeme si například zavést typové třídy Mající výši plnění (x) a Mající termín realizace (x), které popisují části schématu dokumentu, ve kterém předepisují přítomnost finanční částky s určitým významem a dále termínu, kdy dojde k nějaké realizaci. S pomocí těchto typových tříd pak můžeme popsat některé závislosti obecněji.

Pokud typy dokumentů Plánovaná investice a Plánovaný provozní výdaj implementují obě tyto typové třídy, pak je možné typy z předešlého případu splnit například následující strukturou.

Termín typová třída se vyskytuje hojně v kontextu funkcionálního programování. Typové třídy tam ale obvykle neposkytují stejný druh polymorfismu jako typové třídy popsané výše. Dle tamější praxe by musely být oba výdaje v příkladu zcela stejného typu.

Dokument je ve své podstatě stromovou strukturou kompatibilní s formáty JSON, CBOR a YAML.

Jazyk schématu vychází z připravované normy JSON Schema, kterou však rozšiřuje o další prvky. Jedná se například o popis uživatelského rozhraní pro editaci stromu, spustitelný kód v řadě významů a také o schopnost přejímat hodnoty ze závislostí.

V příkladu výše vidíme závislosti (lender a borrower), které dokument vyžaduje. Protože u nich není uvedena žádná kvantifikace, předpokládá se výchozí, tedy {1,1}. Typ obou závislostí je Party (smluvní strana), což bude pravděpodobně typová třída.

Dále můžeme vidět jediný typ přílohy, dokument nebo obrázek v roli subject (předmět). Vzhledem k neomezenému počtu se bude patrně jednat o sbírku dokladů popisujících zapůjčovanou věc a snad i další podmínky zápůjčky.

Hned v první části příkladu vidíme import funkcí (today a timedelta z modulu spis.datetime). V politice je možné využívat vypočítaných hodnot a tímto způsobem je možné získat knihovní funkce. Modul spis a jeho součásti obsahují zabudované funkce systému.

V popisu samotného těla dokumentu vidíme, že se v tomto případě nejedná o žádnou složitou strukturu, ale pouze o doplnění příloh a závislostí o termín platnosti výpůjčky představovaný sekcí period. Její hrubý popis je čerpán z knihovny schémat a úpravy probíhají pomocí komponenty editoru dokumentů DateRangePicker se zobrazením svátků.

V závěru sekce pak nalezneme určení výchozích hodnot pro nový dokument, které využívá právě knihovních funkcí importovaných výše k nastavení výpůjčky ode dnes na 14 dní a nakonec i seznam kontrol, kterým je daná komponenta podrobena a bez jejichž úspěšného absolvování není možné dokument dokončit.

Kromě kontrol připojených k jednotlivým komponentám je možné nastavit také kontroly, které platí pro dokument jako celek.

Elektronické podpisy jsou realizovány dle normy XAdES. Dokument je pro účely podpisu převeden do své kanonické XML podoby obsahující také otisky příloh a celkový otisk je následně uživatelem podepsán. Výsledný XML fragment s podpisem je uložen v databázi.

Ověření platnosti podpisu je realizováno dle shodné normy.

Vlastnoruční podpisy jsou realizovány pomocí tvrzení o podpisu, které do systému vloží podepisující nebo jiná pověřená osoba, u které je k dispozici k nahlédnutí podepsaný originál. Ten vznikne vytištěním dokumentu a jeho podpisem.

Pro vyšší míru jistoty spoléhajících se uživatelů může být tvrzení doplněno skenem podepsaného dokumentu, který si mohou uživatelé zobrazit. Tento "důkaz" však platnost dokumentu nijak nezaručuje a spoléháním se na něj se uživatel může vystavovat určitému riziku.

Pokud by byla příloha z listinné podoby autorizovaně konvertována, bylo by možné se na ni spolehnout, ale přesto (dle našeho názoru) neexistuje žádný způsob, jak bezpečně spojit podepsanou listinu s nepodepsaným elektronickým originálem za účelem automatického ověřování platnosti a návaznosti úkonů ze strany systému.

Úlohu hlavního databázového systému plní otevřené řešení PostgreSQL. Tím se zajistí dobrá integrace do stávajícího prostředí objednatelů, dlouhodobá udržitelnost a nedojde k omezení možnosti řešení dále šířit, protože licenční podmínky PostgreSQL v něm nebrání.

Ústřední skupinou objektů v databázi jsou dokumenty. Tyto dokumenty, vyjádřené hodnotou typu jsonb (binární JSON) jsou doplněny o řadu metadat v rozsahu vyplývajícím z ostatních požadavků. Dokumenty všech typů budou uloženy v jediné tabulce a při jejich ukládání bude docházet k alespoň základní kontrole dle schématu odpovídající jejich typu.

Obsah dokumentů by nemělo být vůbec možné měnit, pouze vytvářet nové revize a upravovat jejich stav směrem k dokončení a podepsání.

Relační datové struktury, ze kterých uložené procedury čerpají data pro pohledy, se mohou do systému dostat dvěma způsoby. Může jít o data z jiných systémů nebo rozbory dokumentů.