Configuration Manager

Slouží k nastavení Infoportálu. Po prvním spuštění EaInfoportT3.exe, nám konsole zahlásí, že poslouchá na localhostu s určitým portem. "Now listening on: http://localhost:64297" Po zadání URL do webového prohlížeče, se nám načte „Configuration Manager“. První vyvolání manageru slouží k vytvoření souboru appsettings.json, který ukládá určité parametry pro chod Infoportu.

Configuration Manager
Show Password
Licence
Infoport Database Connection
URL
Serilog
Active Directory - LDAP Section
OpenID
Environment
Infoport na pozadí
SynchronizeADUserJob
SynchronizeSparxUserJob
Startup Jobs
Scheduler Jobs
Regenerate Repository Tree Job
Regenerate Image
Regenerate Existing Image Job
Regenerate Missing Image Job
Clean Dcom Job
Cleaning Disk Cache Job
Nastavení serveru pro e-mailová oznámení
Notification Hour Job
Notification Day Job
Notification Week Job
Údržba Databáze
X Frame

Configuration Manager

Po vyplnění formuláře stiskneme tlačítko a pokud máme vše dobře vyplněno, objeví se v každé části .

Poté stiskneme tlačítko , počkáme až se celý Configuration Manager nastaví a uloží.

Vyskočí nám tato stránka, kde stačí v Url adrese odmazat /Setup/Save a dát Enter.

Show Password

Po zakliknutí checkboxu se zobrazí všechna hesla v konfiguračním manageru.

Licence

Licenční klíč Vám zašle firma Dataprojekt s.r.o.

V první sekci vkládáme licenční klíč a nastavujeme dobu expirace přihlášení uživatele.

Automatic Logout Time je bezpečnostní prvek, který slouží k automatickému odhlášení při jeho delší nečinnosti.

Multi Company Mode
Pokud bude Multi Company aktivován (zaškrtnutý checkbox) tak bude vidět jen Login Email, jak při zakládání nového uživatele, tak i při editaci stávajícího uživatele.
Taktéž bude vidět Login Email na přihlašovací obrazovce.

Statistic Key For Monitoring je klíč pro sdílení statistiky jiným uživatelům.
Po kliknutí na tlačítko Generate Statistics Access Key se vygeneruje klíč.

Infoport Database Connection

První sekce v konfiguraci obsahuje nastavení Infoport databáze. (Databázové schéma, v kterém má program uložené veškeré nastavení).

V první položce si zvolíme typ databáze. Máme na výběr ze tří typů.

MySQL s defaultním portem 3306
Microsoft SQL Server s defaultním portem 1433
Oracle s defaultním portem 1521
PostgreSQL s defaultním portem 5432

Po zvolení typu se nám automaticky vyplní hodnota položky Port.

Druhá položka je nastavení IP adresy serveru databáze. (Pokud Vám Infoport běží na stejném stroji s databází, stačí vyplnit lokální IP adresu).

Třetí položka je nastavení portu serveru databáze. Defaultně předvyplněný údaj podle typu databáze je možné změnit.

Čtvrtá položka má význam jen pro MySQL a Microsoft SQL Server.
Vyplňujeme název schématu, do kterého si Infoport vytvoří svoje tabulky. (Pokud není schéma vytvořené na databázovém serveru, Infoport si ho vytvoří sám, když má uživatel v databázi dostatečná oprávnění).

Další dvě položky jsou uživatel a heslo. Musíme vyplnit uživatele, který má DML a DDL práva do naší zvolené databáze.

Položka Timeout slouží k nastavení maximální délky dotazu do databáze, má vliv především u dotazů během vyhledávání.

URL

V druhé sekci určíme, na jaké URL bude Infoport poslouchat.

TLS

Pokud používáme zabezpečenou komunikaci, je možné zvolit verzi/verze TLS, které považujeme za dostatečně bezpečné.
Například verze 1.1. není po roce 2021 na operačním systémů Windows podporována a neměla by se používat.

URL se skládá ze tří částí.

První určuje protokol (http nebo https), ve druhé je IP adresa a třetí část je port.
Chceme-li používat https (viz níže), musí být certifikát vystaven na stejnou IP adresu, jakou zde uvedeme.

Protocol Http1 a Http 2
Jsou to protokoly, které jsou nastavené defaultně.
Uživatel si musí nastavit jen Protocol Http1, který podporuje fungování Windows Autentizace.

Pfx File

Dalšími položkami k vyplnění jsou cesta a heslo k certifikátu k výše zadané URL.

Installed certificate

Https Redirection

Když se zapne/zaškrtne checkbox u Https Redirection, tak se všechny http requesty převádí na https a na port, který se nastaví.

Max Request Headers Total Size In KB

Tento parametr umožnuje nastavit maximální povolenou velikost requestu.
Některé requesty můžou obsahovat větší množství dat a Infoport je nedokáže zpracovat. (Například přihlášení přes OpenID, kde se posílaly všechny skupiny, ve kterých uživatel je).

Pokud chceme další URL, na kterém bude portál poslouchat, stiskneme tlačítko a vytvoří se nám nové položky k vyplnění.
Pokud chceme smazat URL, stiskneme tlačítko .

Serilog

Třetí sekce nám umožní nastavit logování Infoportu.

První položka je zaškrtávací políčko, které říká, jestli mají být logovány aktivity uživatelů. (Přehled navštívených URL).

V druhé položce volíme relativní cestu na ukládání logů.

V třetí položce vybíráme typ logování.
(Každý typ je popsán v tabulce, doporučujeme logování Information).

Tabulka pro typy logování.

Úroveň (od nejpodrobnějšího k nejméně podrobnému)	Popis
Verbose	For information that's typically valuable only for debugging. These messages may contain sensitive application data and so shouldn't be enabled in a production environment. Disabled by default.
Debug	For information that may be useful in development and debugging. Example: Entering method Configure with flag set to true. Enable Debug level logs in production only when troubleshooting, due to the high volume of logs.
Information	For tracking the general flow of the app. These logs typically have some long-term value. Example:Request received for path/api/todo
Warning	For abnormal or unexpected events in the app flow. These may include errors or other conditions that don´t cause the app to stop but might need to be investigadet. Handled exceptions are a common place to use the Warning log level. Example: FileNotFoundException for file quotes.txt.
Error	For errors and exceptions that cannot be handled. These messages indicate a failure in the current aktivity or operation (such as the current http request), not an app-wide failure. Example log message: Cannot insert record due to duplicate key violation.
Fatal	For failures that require immediate attention. Examples: data loss scenarios, out of disk space.

Ve čtvrté položce vybíráme, kam chceme, aby se logy zapisovaly. Máme tři možnosti: Konzole, Soubor nebo Obojí.

V páté položce volíme, jak často se má logovací soubor uzavírat.

Zde můžeme vidět zvolený den. Znamená to, že se nám každý den vytvoří nový soubor s logy pro portál. Logy z minulých dnů zůstávají na disku.

Po vyplnění stačí stisknout tlačítko a manager Vám zahlásí, jestli je vše v pořádku.

Active Directory - LDAP Section

V této sekci nastavujeme Active Directory pomocí LDAP protokolu.

"Active" nám určuje, jestli chceme, aby Infoport pracoval s AD.
"Automatic Login" určí, jestli se uživatelé do AD automaticky přihlásí, pokud zadají v prohlížeči URL Infoportu.
"Database Preference" nám určuje, že se při přihlašování jde nejdřív do databáze k uživatelům a teprve potom do AD
"False Login As Host" nám umožňuje zvolit, jestli chceme, aby se uživatel, který není v AD mohl přihlásit jako host portálu.

OpenID

Server Realm – vyplníme odkaz na open id server

Metadata – vyplníme odkaz na metadata open id serveru

ClientID – vyplníme odkaz na identifikátor Clienta

Client Secret – vložíme client secret

Redirect Uri – zadáme url, která se zavolá po odhlášení z infoportu

Infoport Group for Portals Admins – zadáme název skupiny, u které chceme, aby v ní byli uživatelé portálový administrátoři v Infoportu

LogoutUri – zadáme url, která odhlašuje z open id

Claim that belongs to the username – zadáme claim, podle kterého si infoport bude vytahovat infoport username z odpovědi

Claim that belongs to the email – zadáme claim, podle kterého si infoport bude vytahovat email z odpovědi

Claim that belongs to the forename – zadáme claim, podle kterého si infoport bude vytahovat křestní jméno uživatele z odpovědi

Claim that belongs to the surname – zadáme claim, podle kterého si infoport bude vytahovat příjmení uživatele z odpovědi

Claim that belongs to the groups – zadáme claim, podle kterého si infoport bude vytahovat skupiny, do kterých patří uživatel z odpovědi

Přidáme Open ID Scopes, aby se nám vracely všechny potřebné atributy

Environment

První položkou je zaškrtávací políčko, kterým určujeme, jestli chceme publikované obrázky ukládat i do databáze.
V další třech položkách si volíme relativní cestu, do které se budou ukládat publikované obrázky, kešované obrázky a dočasné soubory.

Infoport na pozadí

Infoport provádí různé funkce na pozadí.
Některé může uživatel nastavit, jiné běží podle defaultních nastaveních.
Konfigurovatelné funkce najde uživatel v souboru „appsettings.json“.
Funkce především pracují s repozitáři.

V Configuration Manageru volí uživatel některé funkce na pozadí.

Po spuštění začne funkce pracovat v pozadí a načítat postupně stromeček pro uživatele (funkce nese název InitialLoadCacheDeep v Background sekci).

SynchronizeADUserJob

Synchronizace s uživateli Infoportu je pro uživatele z AD.
Funkce se jmenuje SynchronizeADUserJob.
Opět má cron položku pro pravidelné spouštění synchornizace.

CreateUser a AddUserToGroup

CreateUser je příznak toho, jestli chceme, aby se uživatelé z AD vytvářeli do Infoportu.
AddUserToGroup je zase příznak, jestli chceme, aby se uživatelé přidávali do skupin.

SynchronizeSparxUserJob

Nyní probereme funkci pro synchronizaci Sparx uživatelů s uživateli Infoportu.
Funkce se jmenuje SynchronizeSparxUserJob.
Obsahuje jedinou položku pro nastavení (cronovské nastavení).
Podle zadaného nastavení se pravidelně synchronizuji uživatelé.

Startup Jobs

Jsou to procesy, které se spustí vždy jen jednou při startu aplikace a vykonají činnosti, které jsou potřeba provést před tím, než aplikaci začnou používat uživatelé.

Prefetch Repository Cache Job

Při každém spuštění aplikace se z databáze do paměťové keše načítá základní část stromečku repozitory.
Důvodem je zrychlení práce uživatele při procházení stromečkem.
To, kolik úrovní se načte je závislé na parametrech „Initial Load Cache Deep“ a „Maximum Auto Cache Deep“.

První „Initial Load Cache Deep“ udává, kolik úrovní se načte před tím, než aplikace začne „poslouchat“ a je k dispozici uživatelům.
Zde je vhodné volit 3 až 5 úrovní.

Hodnotu 3 pokud je repozitoř organizovaná spíše do šířky (to znamená, že na jedné úrovni je větší množství {>>50} modelů či balíčků).
Hodnotu 5 pro balíčky organizované převážně do hloubky (zanořování balíčků).

Pokud je druhý parametr „Maximum Auto Cache Deep“ nastaven na větší hodnotu než první (doporučeno je 7 až 13), pokračuje načítání dat do keše i poté, co je aplikace uživatelům dostupná.
To se děje postupně až do hloubky stromečku určené tímto parametrem.

Pokud libovolný uživatel prochází stromečkem hlouběji, než je nastaveno v parametru pro maximální automatické načtení („Maximum Auto Cache Deep“), dochází k rozšiřování keše o zobrazená data.
Další uživatelé tak mají zobrazení výrazně urychlené.
Tato nakešovaná data mají pak vliv na to, jak mohou (budou-li tak nakonfigurované) fungovat i některé další joby („Regenerate Repository Tree“, „Regenerate Existing Image“, „Regenerate Missing Image“).

Scheduler Jobs

Jsou to procesy, které se spouštějí pravidelně a slouží k udržování aplikace v dobré kondici. Jde především o občerstvování dat v paměťové a diskové keši, o různé datové synchronizace a o odstraňování nepotřebných dat a systémových procesů.

Společná nastavení u všech naplánovaných Jobů

Základní parametrem pro každý job je informace o tom, s jakou periodicitou poběží.
Je možné nastavit jeho spuštění každou minutu, nebo třeba jen jednou za měsíc.
K tomu se používá syntaxe známá jako CRON a v konfigurátoru tomu odpovídá vždy pět položek (Minute, Hour, Day of the Month, Month a Day of the week).

U každého jobu je také možné nastavit, zda se má spustit ihned po startu aplikace (serveru) a to zaškrtnutím položky „Run Immediately“.

Regenerate Repository Tree Job

Tento job je určen k periodické aktualizaci stromečku repozitáře nezávisle na uživatelích.
Při spuštění postupně prochází celý, do té doby nakešovaný stromeček a porovnává jej se stavem v databázi.
Pokud nezjistí žádné rozdíly, tak ponechá větve stromečku nedotčeny.
Pokud ale na nějaké úrovni zanoření zjistí změnu (přidaný / odebraný / změněný artefakt) odebere z keše všechny hlouběji zanořené artefakty a obnoví je z databáze.
Toto obnovení postupuje do hloubky zanoření dané parametrem „Maximum Auto Cache Deep“ ze sekce „Prefetch Repository Cache“.

Vhodné načasování je okamžik, kdy uživatelé s programem pracují minimálně, tzn. v nočních hodinách a po (případných) automatických synchronizacích modelů na úrovni databáze nějakým externím softwarem.

Regenerate Image

Obrázky diagramů se generují obecně dvěma způsoby.
Buď tím, že si uživatel zobrazí detail diagramu anebo joby na pozadí „Regenerate Existing Image" a „Regenerate Missing Image".
Po vygenerování se obrázek uloží do diskové keše a po opětovném požadavku (kteréhokoliv) uživatele, se z disku zobrazí.
Obrázky ale také zastarávají a to tím, že jej někdo upraví nebo změní jeho metadata.
Pokud si uživatel zobrazí obrázek diagramu, který byl nedávno modifikován, systém to pozná.
Zobrazí původní zastaralý obrázek z diskové keše a začne diagram přegenerovávat.
To ale zabírá určitý čas (typicky vyšší jednotky sekund) a uživatele to zdržuje.
Proto existují dva joby, které se tomuto snaží předcházet, vyhledávají zastaralé nebo dosud nevygenerované diagramy a regenerují je.

Regenerate Existing Image Job

Tento job má za úkol přegenerovávat dříve vytvořené obrázky diagramů.
Rozpoznává, jestli byl diagram od posledního vytvoření jeho obrázku modifikován a případně jej nechá znovu vytvořit a uložit do diskové keše.
Slovo Existing v názvu tohoto jobu znamená, že se práce tohoto jobu týká výhradně diagramů, k nimž v diskové keši již „nějaký“ obrázek existuje (neexistující obrázky řeší job „Regenerate Missing Image“).

Přepínač „Only By Tree Cache“ určuje, jestli se regenerace zaměří pouze na ty obrázky na disku, které patří diagramům aktuálně načteným v paměťové keši stromečku (viz. „Prefetch Repository Cache“).
Pokud tento přepínač není zaškrtnutý, job zajistí aktuálnost všech obrázků uložených v diskové keši bez ohledu na to, jaký je aktuální stav stromečku.

Přepínače „Check Modified Date“ a „Check Hash Matching“ slouží k upřesnění metody, který program použije pro rozpoznání, že obrázek je zastaralý.

První z nich „Check Modified Date“ znamená, že je kontrolováno časové razítko souboru oproti časovému razítku diagramu v databázi.
Toto je velmi rychlé, ale spolehlivost je někde okolo 90 %.
Je to dáno tím, že ne všechny úpravy na diagramu aktualizují toto časové razítko (toto je přímo vlastnost programu Enterprise Architect).

Druhý přepínač „Check Hash Matching“ určuje, že se pro kontrolu aktuálnosti použije výpočet tzv. hashe všech metadat mající vliv na vizuální stránku obrázku.
Tato metoda je sice 100 % spolehlivá, ale je časově náročná.

Oba přepínač je možné „kombinovat“.
Pokud nezaškrtneme ani jeden, tak tím programu říkáme, aby nic nekontroloval a všechny diagramy rovnou přegenerovával.
Poslední možností je zaškrtnutí obou přepínačů, díky čemuž program nejprve zkontroluje datum modifikace a pak teprve hash.
Doporučené nastavení je mít zaškrtnuté pouze „Check Modified Date“ s tím, že pravděpodobnost nepřegenerování zastaralého diagramu není až tak zásadní komplikací.
V případě, že si uživatel zobrazí (zastaralý) obrázek diagramu, je v každém případě hash kontrolován a na neaktuálnost program reaguje jeho přegenerování a následným zobrazením občerstveného obrázku.

Posledním parametrem tohoto jobu je „Gap Miliseconds“.
Jde o interval mezi generováním obrázků jednotlivých diagramů.
Ty se typicky negenerují ihned jeden za druhým, ale je zde ponechána časová prodleva.
Ta slouží k tomu, aby se mohl bez zbytečných odkladů zpracovat i požadavek uživatele na generování obrázku.
Defaultní hodnota tohoto parametru je 5000 (tzn. 5s), pokud ale víme, že v době regenerování nebudou uživatelé aktivní, je možné tento parametr výrazně snížit nebo ho nastavit na 0.

Regenerate Missing Image Job

Tento job má za úkol dogenerovávat ještě nevytvořené obrázky diagramů a ukládat je do diskové keše.
Nijak nepracuje s obrázky již vytvořenými a uloženými v keši, a to ani tehdy, pokud by byly zastaralé (k tomu slouží „Regenerate Existing Image“).

Přepínač „Only By Tree Cache“ určuje, jestli se generování zaměří pouze na diagramy aktuálně načtené v paměťové keši stromečku (viz. „Prefetch Repository Cache“).
Pokud tento přepínač není zaškrtnutý, job zajistí vygenerování všech obrázků diagramů, které jsou součásti kompletního stromečku.

Posledním parametrem tohoto jobu je „Gap Miliseconds“.
Jde o interval mezi generováním obrázků jednotlivých diagramů.
Ty se typicky negenerují ihned jeden za druhým, ale je zde ponechána časová prodleva.
Ta slouží k tomu, aby se mohl bez zbytečných odkladů zpracovat i požadavek uživatele na generování obrázku.
Defaultní hodnota tohoto parametru je 5000 (tzn. 5s), pokud ale víme, že v době regenerování nebudou uživatelé aktivní, je možné tento parametr výrazně snížit nebo ho nastavit na 0.

Clean Dcom Job

Job slouží k odstranění přebytečných (typicky nefunkčních) DCOMů z paměti operačního systému.

DCOM je prostředník při komunikaci mezi EAInfoportem a Enterprise Architectem.
DCOM je nejčastěji používán pro generování obrázků diagramů ale také k některým aktivním operacím (např založení a odstranění artefaktu).
Pro připojení ke každé jedné repozitoři je potřeba minimálně jeden DCOM.

V DCOMu občas dojde k chybě a ten je pak nezpůsobilý pro další komunikaci.
Pokud k tomu dojde, je okamžitě (a pro uživatele transparentně) vytvořena v paměti nová instance DCOMu a ta se začne používat.
Původní instance ale v tom okamžiku v paměti zůstává. Je odstraněna až tímto úklidovým jobem.

Parametr „Max Dcom Per Repository“ udává, kolik je maximum tolerovaných DCOMů v paměti na jednu repozitory.
To znamená, že program si tento parametr vynásobí počtem připojených repozitoří a zkontroluje, zda je celkový počet běžících DCOMů menší než toto číslo.
„Max Dcom Per Repository“ nijak nerozlišuje, který DCOM „patří“ k jaké repozitoři.
Pokud je limit překročen, jsou z paměti odstraněny všechny instance DCOMu a program ji je následně znovu při potřebě jejich použití vytvoří.

Pokud provozujete na jednom serveru vícero instalací EaInfoportu (což na různých portech lze), je potřeba parametr „Max Dcom Per Repository“ nastavit s vědomím, že každá instalace (má-li aktivní tento job) bude počet repozitoří počítat podle sebe.

Cleaning Disk Cache Job

Tento job slouží k čištění diskové keše.

Disková keš je adresář na disku, kam jsou ukládány obrázky diagramů, tak aby je bylo možné rychle zobrazovat uživatelům.
Některé dávno vytvořené soubory s obrázky, už nemusí mít význam. Na disku zbytečně zabírají místo a je možné je odstranit.

První ze dvou parametrů „Safety Gap Seconds“ chrání nejmladší (nejpozději vytvořené) soubory proti smazání.
Například defaultní hodnota 86400 (což je 60*60*24 s) říká, že soubory vytvořené za posledních 24 hodin se nebudou uklízet (mazat) a to ani tehdy, pokud by celková jejich velikost na disku přesahovala přes limit (daný druhým parametrem).

Druhý parametr „Disk Size Limit Bytes“ říká, jaká je maximální celková velikost souborů na disku po úklidu.
Job si seřadí soubory obrázků podle okamžiku jejich vytvoření a postupně je od nejstarších maže až do okamžiku, kdy zbylé zabírají na disku méně místa, než udává tento limit.
Pokud by se ale měli mazat už i příliš „mladé“ soubory (dle prvního parametru) mazání se ukončí a na disku budou soubory zabírat více místa.

Mezi jednotlivými běhy tohoto jobu není nijak sledované (natož regulované), že soubory na disku nezabírají příliš místa.

Velikost parametru „Disk Size Limit Bytes“ je vhodné nastavit tak, aby se soubory obrázků vygenerované pomocí „Regenerate Missing Image“ tak akorát vešli do diskového limitu. Pokud je totiž limit velikosti nižší než to, kolik zabírají obrázky, dochází k neustálému cyklickému (tzn. zbytečnému) generování a odmazávání těch samých obrázků.
Pokud je obrázek diagramu už na disku uložen, tak jeho regenerování (samozřejmě pokud nebyl jeho model rozšířen) již další nárok na diskový prostor nevyžaduje.

Nastavení serveru pro e-mailová oznámení

Vytvořili jsme tři notifikační služby, které upozorňují uživatele o změnách na diagramu

Správce musí nastavit e-mailový server, aby bylo možné odesílat notifikační e-maily uživatelům.

Mail Adress je okénko pro zadání emailového serveru.

Mail Port je okénko pro zadání emailového portu.

Mail Account je okénko pro zadání uživatelského jména, který má přístup na emailový server.

Mail Password je okénko pro zadání hesla pro uživatele.

Sender Email je nastavení emailu, který se bude ukazovat uživatelům, kterým přijde email o notifikaci o změně na EA diagramu.

Sender Name je nastavení jména, který se bude ukazovat uživatelům, kterým přijde email o notifikaci o změně na EA diagramu.

Redirect Address je políčko, kam uživatel zadá url Infoportu, aby se uživatel mohl odkázat přes odkaz v emailu na portál.

Diagram Thumbnail je checkbox, kterým se určí jestli chceme zasílat uživatelům v emailech zmenšené obrázky diagramu.

Notification Hour Job

Základním parametrem pro každý job je informace o tom, s jakou periodicitou poběží.
Je možné nastavit jeho spuštění každou minutu, nebo třeba jen jednou za měsíc.
K tomu se používá syntaxe známá jako CRON a v konfigurátoru tomu odpovídá vždy pět položek (Minute, Hour, Day of the Month, Month a Day of the Week).

U každého jobu je také možné nastavit, zda se má spustit ihned po startu aplikace (serveru) a to zaškrtnutím položky „Run Immediately“.

Tento job má za úkol zasílat uživateli upozornění na email o změně na diagramu.
Pokud nezjistí žádnou změnu na diagramu, tak nezasílá upozornění.
Pokud zjistí změnu na diagramu, tak job pošle emailem upozornění na diagram s provedenou změnou.

Uživatel může na diagramu vidět ikonku "informačního panáčka", která po najetí na ní informuje jaký typ upozornění je nastavený.

Pro nastavení hodinového upozornění, musí uživatel kliknout na ikonku a až se ikonka změní je zasílání diagramu nastaveno.

Notification Day Job

U každého jobu je také možné nastavit, zda se má spustit ihned po startu aplikace (serveru) a to zaškrtnutím položky „Run Immediately“.

Uživatel může na diagramu vidět ikonku "informačního panáčka", která po najetí na ní informuje jaký typ upozornění je nastavený.

Pro nastavení denního upozornění, musí uživatel kliknout na ikonku a až se ikonka změní je zasílání diagramu nastaveno.

Notification Week Job

U každého jobu je také možné nastavit, zda se má spustit ihned po startu aplikace (serveru) a to zaškrtnutím položky „Run Immediately“.

Uživatel může na diagramu vidět ikonku "informačního panáčka", která po najetí na ní informuje jaký typ upozornění je nastavený.

Pro nastavení týdenního upozornění, musí uživatel kliknout na ikonku a až se ikonka změní je zasílání diagramu nastaveno.

Údržba Databáze

X Frame

Správce portálu má nyní novou možnost v konfiguraci. Pokud chcete zapnout funkci XFrame musíte mít aktivní protocol Https a doporučujeme tuto funkci zapínat jen ve vnitřní síti. Funkce umožňuje vložit celý portál přes html iframe do jiných aplikací.