Administrace Lotus Domino/Notes – 7/10

Aplikace (a teď mluvím o jednotlivých databázích v Lotus Notes, nikoliv o omezené verzi Sametime či něčem podobném) dodávané společně s Lotus Notes jsou pro mnoho uživatelů takovým skrytým bonusem. Málokdo o nich totiž ví a většina lidí je překvapena, co vše vlastně dostávají v ceně a na co nemusejí poptávat partnery, aby jim to vyvinuli. Pravdou je, že postupem doby je těch databází tak nějak méně, spousta lidí vzpomíná na zlaté doby verze 4, kde bylo databází spousta a většina z nich byla opravdu užitečných. Ale i v dnešní době se hodí to, co je „zadarmo“.

Díky tomu, že většina lidí staví rovnítko mezi Lotus Notes a poštovní systém, tak tady nebudu mluvit o poštovní šabloně. Vlastně jenom krátká zmínka – do verze 7 (včetně) existovaly asi tři různé verze poštovní schránky, které se z uživatelova pohledu moc nelišily, ale vevnitř byly jiné a nasazovaly se pro jiné účely. Od verze 8 už je verze naštěstí jenom jedna.

Rezervační databáze bývá nasazována relativně často. Díky ní je možné rezervovat veškeré prostředky ve společnosti, od projektorů přes zasedací místnosti až třeba po auta. Vlastní používání je z pohledu uživatele dost jednoduché, když plánuje schůzku tak do speciálního pole vybere co bude potřebovat a vše se zarezervuje. Z hlediska administrátora je práce trochu víc, nejdůležitější je totiž správně rozmyslet strukturu a pojmenování zdrojů, které částečně kopíruje strukturu certifikátů u uživatelů. Když se to navrhne špatně tak jsou uživatelé zmatení, pokud je vše správně tak mohou být nadšení.

Dalších pět aplikací se navzájem částečně překrývá a záleží vždy na uživatelích, která se vybere. Jedná se o Diskuzní databázi, která slouží pro jednoduché diskuze s možností stromového řazení příspěvků a jejich jednoduché kategorizace. Ze zkušenosti se dá říci, že použití je opravdu jednoduché, ale v okamžiku, kdy navzájem „diskutuje“ 10 a více lidí z různých lokalit (zpoždění při replikaci) tak to chce správce takového fóra, který bude sekat slepé větve a informovat, že se to již někde vyřešilo. Ale pokud chcete rychle podiskutovat, je to asi nejlepší.

O kousek složitější je Knihovna dokumentů, která existuje dokonce ve třech verzích. Jedna úplně obyčejná, druhá s podporou Lotus SmartSuite a třetí s podporou MS Office. Pod podporou se myslí možnost mít příslušný dokument vložen přímo v LN dokumentu jako objekt, což vypadá velice efektně, ale na problémy se naráží při prohlížení na webu i při možném poškození dokumentu. Zkrátka a prostě doporučuji tu obyčejnou a dokumenty vkládat jako přílohy. Navíc v dnešní době, kdy je možné editovat dokument přímo, bez nutnosti jeho uložení na disk, upravení a vložení zpět není o čem diskutovat. Oproti Diskuzní databázi je zde možnost schvalování dokumentů a to jak sériovým tak paralelním schvalovacím cyklem, což se dá využít ve spoustě případů.

Poslední z této série je databáze TeamRoom, kterou je možné použít hlavně pro správu projektů. Narozdíl od těch předchozích to chce mít ale zkušené uživatele, jak na to člověk jenom rychle koukne tak zjistí, že vůbec netuší jak to celé použít. Osobně jsem to na jednom projektu zkoušel a se zákazníkem jsme měli problém se hlavně domluvit, jak to používat, co kdy a kde nastavit a co to znamená. Jinak je to krásné, každý dokument lze spojit s určitou etapou, přidělit týmu či konkrétním osobám nebo používat různé typy dokumentů. Možná kdyby se člověk zamyslel a dodržoval pravidla, tak by mohl být opravdu spokojen.

Journal, v české verzi nazvaný Deníkem, je databáze, která dřív vznikala na klientských počítačích sama a nikdo ji nikdy neotevřel. Český překlad je výstižný, v podstatě je to takový elektronický list na poznámky, na seznam věcí, které je třeba udělat, a určitě se vše dá využít na spoustu jiných věcí. Sám se přiznám, že jsem ho nikdy nepoužil a za celou dobu potkal jednoho člověka, který ho používal. Ale možná je lepší používat toto, než si psát poznámky a výkřiky do textového dokumentu, přestože to nemá tak krásné grafické rozhraní jako OneNote od Microsoftu.

Poslední aplikace, která je dodávaná od verze 7, je blog. Sám ho používám právě pro tyto stránky a poté co jsem si zvykl si už nemůžu stěžovat. Takže už se těším na verzi 8.0.1, kdy mi to celé zase změní. Nakolik je něco takového ovšem využitelné ve firemním prostředí je otázkou, snad by to šlo použít jako jakási obdoba intranetu, ale to závisí spíš na firmě. Nebo kdyby začaly firmy umožňovat svým zaměstnancům provozovat blogy na jejich serverech (jako IBM), pak by to bylo super.

Pokud je vám to málo, tak můžete vyzkoušet server OpenNTF, kde najdete spoustu volně dostupných aplikací. Jejich kvalita je nejrůznější, spousta z nich je pravidelně aktualizovaných a některé jsou opravdu zajímavé – aplikace pro projektové řízení, helpdesky, CRM a spousta dalších. Jediné co je potřeba, je věnovat tomu čas a projít si, co člověk potřebuje.

Jak nasadím aplikaci?

Tak tím jsem shrnul vše, co je dnes dostupné (a zajímavé pro uživatele) v aktuální verzi LN. Ale jak to vlastně s těmi aplikacemi v Lotusech funguje?

První co je třeba si říci je, že existují dva typy „databází“. První je vlastní databáze, takový soubor má koncovku NSF. A pak je šablona databáze, která má koncovku NTF. Rozdíl mezi oběma typy je jenom v koncovce – pokud tedy přejmenujete soubor z NSF na NTF tak jste právě vytvořili šablonu. A naopak. Tuším, že do verze 6, se oba typy chovaly stejně pokud se týká serveru, od verze 7 se v šablonách nepouštějí plánovaní agenti. A samozřejmě šablony nejsou vidět při otevírání databází.

Pokud tedy chcete nasadit nějakou aplikaci (a je jedno zda od IBM nebo vašeho dodavatele), tak jako první doporučuji její zkopírování na lokální disk, do datového adresáře LN. Zde se s takovou aplikací/šablonou (podle toho co dodavatel dodá a co s ní chce udělat) provede jedna základní věc – podepíše se. Provedení je jednoduché, otevře se administrační klient, na záložce Files se databáze najde (možná bude potřeba vpravo nahoře změnit co se ukazuje), klikne se na ní pravým tlačítkem a vybere se volba Sign. V dialogu se potom vybere, zda chceme podepsat aktivním ID nebo ID serveru (jasně že aktivním, když jsme lokálně a i jinak preferuji podpis administrátorským ID, alespoň je jasné, který z nich to nasadil) a co vše chceme podepsat (všechno). Tím zajistíme, že uživatelé následně nebudou dotazování, zda věří uživateli XY (typicky jméno vývojáře od dodavatele). Tuto akci samozřejmě můžete vynechat, pokud nasazujete aplikace dodané s LN.

Druhým krokem je dostat aplikaci na server. Pokud začíná od nuly, aplikace nikdy na serveru nebyla a máte na disku šablonu, tak zvolíte menu FileDatabaseNew (nebo FileApplicationsNew ve verzi 8), vyberete server, zadáte jméno aplikace (co se zobrazí uživateli) a potom opravíte jméno souboru a v jakém adresáři má být. Ve spodním okénku by měla být vidět šablona, kterou jste před chvílí podepsali, tak ji vyberte, stiskněte OK a je hotovo. Pokud se vám šablona nenabízí tak ještě můžete zkusit zaškrtávátko Show advanced templates a pokud ani poté ne, tak zkontrolujte, zda má šablona příponu ntf.

Pokud máte od dodavatele aplikaci ve formě databáze, ve které už existují nějaké dokumenty a která ještě nikdy nebyla na serveru, tak je pravděpodobně lepší udělat na serveru novou kopii či repliku (dle chuti). V tom případě aplikaci otevřete a z menu FileDatabase zvolíte New Copy případně New Replica (ve verzi 8 je tato položka umístěna ve FileReplication). Vyberete cílové umístění, stisknete OK a čekáte.

Finále v obou případech je věnováno nastavení správných přístupových práv. Jak mají být nastavena musejí říci vývojáři, vy to jenom musíte nastavit (jak, o tom dále).

Co ovšem v případě, že aplikace už na serveru je a vy jste dostali pouze její novou verzi, kterou tam máte dostat? Opět platí informace o podpisu databáze a pak jsou na výběr dvě varianty – obnova návrhu a nahrazení návrhu. Každá varianta má něco do sebe, při obnově dochází pouze k aktualizaci změněných prvků (což díky podpisu jsou všechny), při nahrazení ke změně všech návrhových prvků. Rozdíl tedy relativně není, liší se provedení. Pokud otevřete nasazenou aplikaci a zvolíte FileDatabaseRefresh design (tedy obnovu) tak budete pouze dotázání na server, kde je nová verze šablony. Pokud zvolíte Replace design, tak budete ještě dotázání na šablonu, kterou se má návrh nahradit.

V případě obnovy návrhu je ovšem důležité, aby existovala vazba mezi návrhem aplikace a šablonou. Tato vazba je velice jednoduše udělaná, ve vlastnostech databáze (FileDatabaseProperties) na čtvrté záložce je jméno šablony ze které se návrh dějí, stejné jméno musí být uvedeno u šablony na stejném místě, pouze o políčko níž.

Celou situaci ještě mohou zkomplikovat vývojáři, kteří mohou nastavit, aby každý návrhový prvek dědil z jiné šablony nebo dokonce aby měl zakázáno dědění a už u něj nikdy nedošlo ke změně. Ale to už je spíš o vývojářích, vy při změně návrhu akorát musíte sledovat spodní stavovou lištu, zda nahlásí, že je vše v pořádku.

Při změně návrhu nedochází k žádné změně dokumentů, takže pokud vývojáři v nové verzi šablony dodali i nějaké nové dokumenty, tak ty musíte přenést do ostré databáze ručně.

Jak správně nastavit práva?

Pokud si na něčem Lotusy základají, tak je to bezpečnost. Z konfigurace serveru už víte, že je možné omezit přístup k serveru, poté je možné omezit přístup k jednotlivým databázím a ve finále omezovat i přístup k jednotlivým dokumentům uvnitř databáze (což už je spíše práce vývojáře).

K databázím existuje sedm základních úrovní přístupu, které na sebe postupně stavějí a umožňují více a víc:

• Bez přístupu – nemá přístup do databáze (ale jde to trochu změnit, viz. dále)
• Depozitor – má možnost vkládat do databáze dokumenty, ale už je nikdy nevidí
• Čtenář – může pouze číst dokumenty, nemá právo je upravovat (výjimka opět potvrzuje pravidlo)
• Autor – může číst, vytvářet, upravovat a mazat (své) dokumenty
• Editor – může číst a vytvářet dokumenty včetně práva upravovat a mazat všechny dokumenty, které vidí
• Návrhář – může upravovat návrh aplikace
• Manažer – může měnit práva k aplikaci

Výše uvedené platí s výjimkou „veřejných“ dokumentů. Co je veřejné opět určuje vývojář (v poště jsou to třeba kalendářové položky) a administrátor může určit, zda uživatelé mají právo vidět či upravovat tyto veřejné položky. A toto právo se dá kombinovat i s úrovní bez přístupu nebo čtenářem, tak i bez přístupu můžete něco vidět a něco upravovat, stejně tak čtenář může některé dokumenty upravovat.

Jak jsou práva nastavená zjistíte pomocí volby FileDatabaseAccess Control.

Zde je vidět kdo má jaká práva. Položka Default je zde vždy a určuje všechny, kteří nejsou podchycení pomocí žádné skupiny, certifikátu (je možné použít */Organizace) nebo konkrétního jména. U položek je dobré dbát na správný typ – pokud o člověku prohlásíte, že je server, tak se do databáze nedostane, stejně tak když o skupině prohlásíte, že je to skupina serverů a bude v ní uveden i uživatel – do aplikace se nedostane.

Pokud je člověk uveden ve více skupinách, tak platí jejich kombinace nejvyšší kombinace s výjimkou, kdy jedna ze skupin je typu Deny List Only, pak se do aplikace nedostane. Pokud je uveden jmenovitě, tak platí práva u něj explicitně vyjmenovaná.

U každé položky je navíc možné částečně omezit práva, která uživatelé mají. Ta se omezují v pravé části pomocí checkboxů a zde jde omezit, zda uživatel má právo vytvářet dokumenty, mazat je, vytvářet soukromé agenty, vytvářet soukromé pohledy (tedy toto právo má i vždy, ale pokud mu to dovolíte zde, tak se pohled uloží do databáze a je pro něj dostupný z libovolného počítače), vytvářet sdílené pohledy, vytvářet Lotusscriptové agenty, číst či zapisovat veřejné dokumenty. Poslední právo – replikovat dokumenty – se objevilo od verze 6 a přináší relativně problémy. Uživatel, který toto právo nemá, sice nemůže databázi zreplikovat ani z ní nic zkopírovat, ale dokumenty, které vytvoří, nemají právo zreplikovat zkopírovat (díky za upozornění na chybu Tomáši Hanusovi, ve verzi 8.5.1 ale prý již kopírovat jde) ani ostatní uživatelé. A to je smutné.

Ve spodní části je ještě možnost definovat role, jejich konkrétní použití je ovšem v rukách vývojáře a administrátor nemá šanci vědět, co která z nich ovlivňuje.

Z dalších záložek tohoto dialogu je zajímavá ještě záložka poslední. Zde se nastavuje administrační server, který v případě změny jména uživatele (či jeho odchodu) může provést příslušné změny v databázi. Dobrou praxí tak je jako administrační server uvést administrační server domény (ten, který se první nainstaloval), pokud je na něm replika databáze. Pokud zde replika není, tak uvést jméno serveru, na kterém je. Co se týká pole zda měnit pole se jmény, tak je to vždy na zvážení. Přejmenování člověka v dokumentech může být příjemné, ale při jeho odchodu dojde ke smazání jména z polí a může tak dojít k tomu, že vůbec nebudete tušit, kdo dokument vytvořil nebo ho měl na starosti. Takže opatrně.

Zaškrtávátko Enforce Consistent ACL across all replicas se dříve používalo často, v dnešní době by prý už nutné být nemělo. Zajišťovalo, aby uživatelé měli stejná práva na lokální replice jako na serveru a nebyli tak zmatení (dříve mohli lokálně upravit cokoliv, ale změny se na server nedostaly).

Poslední položka je maximální úroveň přístupu z Internetu a je to asi jediná rozumná šance jak zajistit, aby aplikace nešla používat přes web. Nastaví zde No Access a přes web se do databáze nikdo nedostane.

Když budete nastavovat práva, tak nikdy nezapomeňte přidat skupinu serverů a administrátorů, obě ideálně s právy manažera. Pokud to neuděláte tak servery mohou mít problémy při replikacích a vy při administraci.