TaskPool 4.1 - administrátorský manuál

revize 200902, © ComArr, spol. s r. o.


Obsah

1. Úvod
Vysvětlení pojmů
Role v systému TaskPool
Administrátorská sekce
2. Uživatelé TaskPoolu
Vytvoření nového uživatele
Editace uživatele
3. Pooly
Karta Obecné
Karta Workflow
Karta Přístupová omezení
Karta Role
Karta Notifikace - časování
Předmět notifikace
Odesílatel notifikací
Notifikace po uživatelích
Karta Priority
Karta SLA schémata
Karta Pole
Karta E-mail Interface
Popis e-mailového rozhraní
E-mailové rozhraní pro uživatele TaskPoolu
E-mailové rozhraní pro modul Helpdesk
Řešení konfliktů v adresách
Karta Evidence nákladů
Karta Plánování
Import do jiných systémů
Karta Provazování tasků
Kopírování poolů
4. Dynamická pole
Vytvoření dynamického pole
Textfield
Textarea
Radiobutton a Selectbox
Multi Selectbox
Checkbox
Number
Counter
Date, Time a DateTime
SQL Selectbox
OnChange volání u SQL selectboxu
SQL základní
SQL závislé
SQL možnosti
SQL všechny
Možnost Nedefinováno
Příklady konfigurace SQL Selectboxů
5. Rozšíření dynamických polí
Změna hodnoty dynamického pole v závislosti na změně stavu tasku
Změna stavu tasku na základě změny dynamického pole
Konfliktní situace a jejich řešení
Omezení možností přechodů
Řešení konfliktů
6. Dynamická pole uživatelů
Modul nepřítomnosti
7. Filtry
Systémový filtr (definovaný TaskPoolem)
Definice filtru
Kopírování filtru
Smazaní filtru
8. Eskalace
Obecné vlastnosti eskalace
Eskalační e-mail
Eskalační skript
9. Licence
10. LDAP / AD
Předpoklady použití LDAP ověření
Konfigurace
Autentikátor
TaskPool autentikátor (pro řešitele)
Helpdesk autentikátor (pro zákazníky)
11. Soubory
12. Šablony
Definice vlastních šablon
Formát zdrojového kódu - XSLT
Použití reportů
13. E-mail reporty
14. POP3 přiřazení
15. Uživatelské notifikace
Zástupné řetězce - proměnné
Použití funkcí
Funkce If
Funkce NotEmpty
Funkce Iterate
Příklad notifikace
16. Ověření
Část LDAP
Předpoklady použití Helpdesku s LDAP autentizací
Princip Helpdesku s LDAP autentizací
Nastavení Helpdesku s LDAP
Přihlášení do Helpdesku pomocí autentikátoru
Část Database
Použití vzorové databáze
Manažer zadavatelů na Helpdesku
CAS (central authentication system)
17. Helpdesk
Využití zástupných řetězců
Karta Základní nastavení
Pravidla pro zasílání e-mailů
Vytvoření zákaznického požadavku na Pracovišti
Možnost e-mailové komunikace
Šablony na Helpdesku
Podmínky na Helpdesku
Karta HD Formulář
Karta Chybová hlášení
Karta Poděkování
Karta Podpis
Karta Notifikace
Karta Historie
Karta Přehled tasků
Karta Přihlášení
Karta správa hesel
Karta Registrace
Karta POP3-LDAP/DB
E-mail Interface na Helpdesku
Kopírování Helpdesků
18. SLA
SLA časy
Konfigurace SLA
Uživatelský pohled
Automatický vs. manuální FixTime
Změna SLA schématu
19. Znalostní báze
20. External Database Manager
Uživatelský pohled
Konfigurace EDM
Soubor applicationXml.xml
21. Evidence nákladů
Zamykání záznamů času
Exportování záznamů času
Vyúčtování
22. SMS modul
23. TaskPool instance
24. Stavy

Seznam obrázků

1.1. Administrátorská sekce
2.1. Vytvoření nového uživatele
3.1. Vytváření poolu: Karta Obecné
3.2. Barva poolu
3.3. Vytváření poolu: Karta Workflow (horní část)
3.4. Vytváření poolu: Karta Workflow (spodní část)
3.5. Vytváření poolu: Karta Přístupová omezení
3.6. Vytváření poolu: Karta Role
3.7. Vytváření poolu: Karta Notifikace - časování
3.8. Notifikace po uživatelích
3.9. Vytváření poolu: Karta Priority
3.10. Vytváření poolu: Karta SLA schémata
3.11. Vytváření poolu: Karta Pole
3.12. Vytváření poolu: Karta E-mail Interface
3.13. Vytváření poolu: Karta Evidence nákladů
3.14. Vytváření poolu: Plánování
3.15. Plánování v editaci tasku
3.16. Provazování tasků
3.17. Provazování tasků
4.1. Příklady dynamických polí
4.2. Vytváření dynamického pole typu Textfield
4.3. Dynamické pole Textfield v praxi
4.4. Vytváření možností polí Selectbox a Radiobutton
4.5. Dynamické pole Selectbox
4.6. Dynamické pole Multi Selectbox v praxi
4.7. Dynamické pole Checkbox v praxi
4.8. Dynamické pole DateTime v praxi
4.9. Nastavení SQL Selectboxu
5.1. Změna hodnoty dyn. pole v závisloosti na stavu workflow
5.2. Změna stavu tasku na základě změny hodnoty dynamického pole
5.3. Omezení přechodů mezi hodnotami dynamického pole
6.1. Administrace: Dynamická pole uživatelů
6.2. Administrace: Dynamická pole
6.3. Editace uživatele
6.4. Dynamická pole uživatelů: Modul nepřítomnosti
6.5. Modul nepřítomnosti: Editace uživatele
7.1. Administration: Filters
7.2. Administrace: Práva pro zobrazení filtrů
7.3. Definice filtru v administraci
8.1. Seznam eskalací
8.2. Definice eskalace
9.1. Administrace: Licence
10.1. Administrace: Nastavení zákazníka
11.1. Administrace: Soubory
12.1. Vytvoření nové šablony
12.2. Použití reportů
13.1. Vytvoření e-mailového reportu
14.1. Administrace: POP3 přiřazení
15.1. Uživatelská notifikace
16.1. LDAP autentifikátor
16.2. Vytvoření nového ověření pomocí LDAP
16.3. Vytvoření nového ověření pomocí Active Directory
16.4. Ověření pomocí databáze
16.5. Konigurace ověření při použití vzorové databáze
16.6. Příklad konfigurace CAS
17.1. Administrace: Pooly
17.2. Příklad použití zástupných řetězců
17.3. Helpdesk: Základní nastavení
17.4. Helpdesk: Správa formulářů pomocí archivu
17.5. Pravidla pro zasílání e-mailů
17.6. Manuální notifikace HD uživateli
17.7. Nový HelpDesk
17.8. Helpdesk: HD Formulář
17.9. Příklad helpdeskového formuláře bez ověření
17.10. Příklad helpdeskového formuláře za použití ověření
17.11. Příklad webového poděkování
17.12. Automatický podpis v praxi
17.13. Příklad hlavičky historie požadavku
17.14. Příklad výpisu komentářů historie požadavku
17.15. Příklad patičky historie požadavku
17.16. Příklad přehledu požadavků
17.17. Helpdesk: Přihlášení
17.18. Příklad změny hesla
17.19. Příklad formuláře zapomenutého hesla
17.20. Příklad registrace
17.21. Helpdesk: POP3-LDAP
17.22. Helpdesk: POP3-LDAP
17.23. Helpdesk: E-mail Interface
17.24. Kopírování Helpdesku
18.1. Konfigurace SLA časů
18.2. Zobrazení bez aktivního SLA
18.3. Zobrazení s aktivním SLA
18.4. Přepočet manuálních časů podle SLA
19.1. Konfigurace znalostní báze
19.2. Použití znalostní báze v TaskPoolu
20.1. Ikona pro přístup do EDM
20.2. External Database Manager
21.1. Administrace: Evidence nákladů
21.2. Přiřazení jednotlivých činností do skupin činností
21.3. Obecné nastavení evidence nákladů
21.4. Seznam vyúčtování
21.5. Zamknuté vyúčtování
21.6. Nové vyúčtování
21.7. Tvorba vyúčtování
21.8. Tisková šablona vyúčtování
22.1. Nastavení dynamického pole řešitelům
22.2. Doplnění čísla pro zasílané sms
22.3. Aktivace SMS modulu
22.4. Příklad konfigurace notifikace pro zasílání SMS
23.1. Nastavení propojení instancí
24.1. Nastavení vlastních názevů stavů a ikon

Seznam tabulek

1.1. Práva jednotlivých rolí
5.1. Postup při řešení konfliktních situací
8.1. Příklady eskalační podmínky
8.2. Zástupné řetězce pro adresáty
15.1. Proměnné pro konfiguraci těla e-mailové zprávy
15.2. Proměnné pro použití dynamických polí

Kapitola 1. Úvod

Předmluva

"Systém TaskPool prochází neustálým vývojem. Ve verzi 4.1 má stále původní grafickou podobu administrace, jako verze 2.92. Na novém vzheldu se postupně pracuje. Omluvte tedy, prosím, některé drobné odlišnosti v návodu pro administrátory, který nemusí vždy souhlasit s aktuální verzí. Změny se snažíme průběžně zapracovávat. Pokud by něco nebylo zřejmé, neváhejte kontaktovat naši podporu."

Vysvětlení pojmů

Požadavek

  • task, úkol, job

Workflow

  • Proces průběhu tasku od vložení až po vyřízení a archivaci, tedy životní cyklus tasku.

Pool

  • Samostatný prostor pro správu určité kategorie nebo typu tasků, pro které je možné:

    • Definovat vlastní pravidla zpracování

    • Definovat vlastní datovou strukturu požadavku využitím dynamických polí

    • Definovat separátní tým pro práci s požadavky v daném poolu

Filtr

  • Definované pravidlo pro zobrazení tasků vyhovujících určité podmínce nebo souboru podmínek.

Dynamické pole

  • Nová datová položka tasku definovaná administrátorem pro konkrétní pool.

Pracoviště

  • Stránka systému, kde je zobrazen seznam tasků konkrétního poolu nebo filtru a dále ostatní informace (přehled uživatelů, statistiky, nástrojová lišta).

Archiv

  • Prostor, kam jsou umístěny vyřešené, přesunuté, exportované či deaktivované tasky.

Uživatel (řešitelská role)

  • Uživatel systému, který se do TaskPoolu přihlašuje na Pracoviště. Může mít v jednotlivých poolech různé role. Počet těchto uživatelů podléhá licenci.

Zákazník (zadavatelská role)

  • Uživatel systému, který přistupuje do Zákaznického rozhraní určené pro zadávání a prohlížení zadaných požadavků. Počet těchto uživatelů není ve standardní licenci omezen.

Autor

  • Uživatel, který vytvoří task, se stává jeho autorem. Může mít zároveň všechny systémové role (kromě nahlížitelů).

Administrační část

  • Do této sekce má přístup pouze administrátor TaskPoolu a slouží ke konfiguraci celého systému.

Administrátor systému

  • Při založení licence je již definován účet administrátora. Spravovat TaskPool může pouze tato role. Administrátor TaskPoolu však může také zastávat libovolné role v rámci jednotlivých poolů a přitom mu bude zobrazena administrátorská sekce.

Notifikace

  • E-mailová zpráva informující o akci, která byla provedena některým z uživatelů TaskPoolu.

Modul Helpdesk a helpdeskový uživatel (zákazník)

  • Modul Helpdesk slouží zákazníkům nebo dalším uživatelům pro možnost zakládání tasků v TaskPoolu, aniž by měli přístup do TaskPoolu samotného. Tito uživatelé vystupují v roli zákazníků (zadavatelů) a k jednotlivým taskům přistupují přes externí webové rozhraní. Každý uživatel vidí pouze svoje požadavky, popř. pokud má uživatel roli manažera zadavatelů, vidí ještě požadavky svých podřízených. Počet těchto uživatelů není omezen. O změnách ve svých požadavcích jsou uživatelé informování notifikačními maily.

Role v systému TaskPool

V systému TaskPool existuje několik typů rolí. Podle přidělené role se uživateli určují práva na jednotlivé činnosti.

ZADAVATELSKÁ stranaŘEŠITELSKÁ strana
Manažer zadavatelů - role na straně zadavatele, která má za úkol dohlížet na realizaci tasků za stranu zadavatele.Servisní manažer - role na straně řešitele, která má za úkol dohlížet na řešení tasků.
Zadavatel - role na straně zadavatele, která může vkládat jednotlivé tasky.Řešitel - role na straně řešitele, která má za úkol vyřizovat jednotlivé tasky.
Nahlížitel - role na straně zadavatele, která má právo tasky pouze prohlížet.Nahlížitel - role na straně řešitele, která má právo tasky pouze prohlížet.

POZN.: Nahlížitel na zadavatelské straně vidí pouze záznamy připadající této straně, tedy skryté komentáře zadavatelů, záznamy času apod. Obdobná je situace s nahlížitelem na řešitelské straně.

Dále existují role Spoluřešitel a Spoluzadavatel. Spoluřešitelé a spoluzadavatelé mají možnost přispívat do tasků komentáři a dostávají z nich také notifikace. Obě role jsou popsány v uživatelském manuálu - spoluřešitelé v kapitole 4.3 Úprava tasku a spoluzadavatelé v kapitole 14. Modul Helpdesk.

POZN.: Spoluřešitelům lze nastavit plnohodnotná práva řešitele, více v kapitole 3.3 Karta Přístupová omezení.

Kompletní práva jednotlivých rolí popisuje následující tabulka, přičemž:

  • MZ = manažer zadavatelů

  • Z = zadavatel

  • Nz = nahlížitel na zadavatelské straně

  • SM = servisní manažer

  • Ř = řešitel

  • = nahlížitel na řešitelské straně

a dále:

- daná role má právo na danou činnost

- daná role nemá právo na danou činnost

- daná role může mít právo na danou činnost v závislosti na nastavení v administraci poolu na kartě "Workflow" (více v kapitole 3.2 Karta Workflow)

Tabulka 1.1. Práva jednotlivých rolí

ČinnostMZZNzSMŘ
prohlížení tasků
zadání tasku
zadání autotasku
převzetí tasku
přidělení tasku řešiteli
komentář k tasku
dokončení tasku
kontrola tasku
potvrzení tasku
deaktivace tasku

POZN.: U prohlížení tasků je možné nastavení, aby každá z rolí viděla pouze svoje tasky, toto se provádí v administraci poolu na kartě "Přístupová omezení" (kapitola 3.3. Karta Přístupová omezení).

Administrátorská sekce

Do administrátorské sekce TaskPoolu se dostaneme z pracoviště tlačítkem "Administrace" a pro návrat zpět slouží tlačítko "Pracoviště". Záložky jsou rozděleny podle jednotlivých funkcí systému. I zde platí jednotná konvence systému, kdy oranžové texty jsou zároveň odkazy s vazbou na další funkčnost.

Obrázek 1.1. Administrátorská sekce

Administrátorská sekce

Kapitola 2. Uživatelé TaskPoolu

Na kartě "Uživatelé" v administrátorské sekci je zobrazen seznam uživatelů TaskPoolu. Nejdříve jsou zobrazeni aktivní uživatelé a poté neaktivní.

Vytvoření nového uživatele

Kliknutím na ikonu Nový se zobrazí formulář pro vytvoření nového uživatele systému. Vytvořit nového uživatele může pouze administrátor, veškerá nastavení si však dále může editovat každý uživatel sám.

Obrázek 2.1. Vytvoření nového uživatele

Vytvoření nového uživatele

Uživatelské jméno a heslo jsou standardní prostředky pro přihlášení do systému. Křestní jméno a příjmení se budou zobrazovat v každém zápisu o provedení změny v systému daným uživatelem. Na zadaný e-mail mu budou chodit notifikace o změnách v tascích, které se daného uživatele týkají. Pole pro telefonní číslo je zde pouze informativní. Co do jazykových verzí systému TaskPool, standardně jsou obsaženy Čeština, Němčina a Angličtina. K dispozici je i Slovenština, v případě zájmu o tuto jazykovou verzi kontaktujte zákaznickou podporu firmy Comarr spol. s r.o.

Trvalé přihlášení bude fungovat pouze tehdy, pokud bude toto pole zaškrtnuté v uživatelském profilu. Zároveň je zde může nastavit, jak dlouho bude přihlášení platné.

Tlačítkem Zobrazovat záznamy času zapínáme zobrazování tzv. "timesheetů", více v kapitole 21. Evidence nákladů.

V poli Stav můžeme nastavit, zda má být uživatel aktivní nebo neaktivní, v druhém případě bude uživateli zamezen přístup do systému a nebudou mu doručovány notifikace. Této volby využíváme v případě, kdy uživatelovo působení v systému TaskPool ztratí smysl. Uživatele nelze přímo smazat z důvodu již vytvořených vazeb, veškeré změny a záznamy provedé uživatelem před deaktivací v systému zůstanou. Neaktivní uživatelé se také nezapočítávají do licence.

Poslední volbou je zda se bude daný uživatel synchronizovaný s LDAPem. Vice o LDAPu v kapitole 10. LDAP / AD.

Editace uživatele

Po vytvoření uživatele se jeho jméno zobrazí v administraci v seznamu na kartě "Uživatelé". Administrátor může editovat nastavení všech uživatelů, poklepáním na libovolného z nich se otevře okno pro editaci. Zde jsou možnosti nastavení již o něco zajímavější než při prostém vytváření uživatele, vše je popsáno v uživatelském manuálu v kapitole 3. Nastavení uživatele.

Kapitola 3. Pooly

Již vytvořené pooly najdeme na kartě "Pooly" v administrátorské sekci. Formulář "Úprava poolu" vyvoláme kliknutím na daný pool, zde je pak možné provést nastavení vlastností příslušného poolu. V seznamu jsou zde nejprve vypsány aktivní pooly a až poté uzavřené.

Formulář pro vytvoření nového poolu vyvoláme klepnutím na tlačítko Nový. Pod záložkami v horní části formuláře se skrývají jednotlivé karty nastavení poolu, které budou popsány v následujících podkapitolách. Veškeré nastavení lze měnit kdykoliv v průběhu existence poolu.

Karta Obecné

Na kartě "Obecné" nastavujeme základní vlastnosti poolu. Již vytvořený pool nemůže být smazán, ale pouze deaktivován. Důvodem je možná existence vazeb na další časti systému. Neaktivní pool se nezapočítává do licence.

Obrázek 3.1. Vytváření poolu: Karta Obecné

Vytváření poolu: Karta Obecné

Kolonka Kategorie je nepovinný údaj. Může sdružovat jednotlivé pooly s podobným účelem (např. Helpdesky) a sloužit tak k lepší manipulaci s těmito pooly pomocí filtrů. Více v kapitole 7. Filtry.

Barva poolu označí každý požadavek specifickou barvou na pracovišti i v detailu. Umožňuje tak intuitivnější práci s tasky, např. všechny helpdeskové tasky žluté apod.

Obrázek 3.2. Barva poolu

Barva poolu


V případě, že je použito Logo poolu, zobrazuje se na pracovišti v horní liště na levé straně.

Karta Workflow

Na této kartě definujeme proces řešení jednotlivých tasků v daném poolu.

Obrázek 3.3. Vytváření poolu: Karta Workflow (horní část)

Vytváření poolu: Karta Workflow (horní část)

Následující volby určují práva jednotlivých rolí v konkrétním poolu. Následuje popis složitějších nastavení:

Počet dní do vypršení je implicitní nastavení deadline pro nový task v daném poolu, tedy kolik dní je určeno na vyřešení tasku. Čas vypršení může dále upravovat SLA, je-li nastaveno, více v kapitole 18. SLA.

Automatické archivování znamená, že kompletně dokončené tasky (mají ikonu zeleného vykřičníku) po zadaném počtu dní automaticky přecházejí do archivu.

Přesouvání tasků je volba, díky které můžeme přesouvat tasky z daného poolu do jiného. Přesunutý task se přesune do archivu mateřského poolu ve stavu "Přesunut" a zapíše se do něj link na nový - přesunutý task. Přesunutému tasku zůstanou zachovány všechny hodnoty a historie a založí se ve stavu "Zadán k řešení". Přesouvání je vhodné použít, pokud je task omylem zadán do jiného poolu. Pokud takové nebezpečí ve vaší konfiguraci běžně nehrozí, doporučujeme tuto volbu vypnout. Zjednoduší to formulář editace tasku.

POZOR! Pokud přesouváme task do poolu, který neobsahuje stejné datové položky (např. dynamická pole) jako původní pool, u přesunutého tasku může dojít ke ztrátě dat.

Exportování / Importování tasků. Pokud je v systému nastaveno propojení dvou a více instancí systémů mezi sebou, je možné těmito volbami zapínat pooly, ve kterých se bude nabízet akce Exportovat a pooly, které se budou v propojené instanci nabízet jako cílové. Do importovaného požadavku se přenáší historie požadavku exportovaného. Množství přenesených informací záleží na konfiguraci cílového poolu.

Volba Přidělování tasků mění možnosti přidělení řešitele a spoluřešitelů.

Pokud je task Přidělován servisním manažerem, nemůže si jej řešitel sám převzít. V opačném případě si řešitelé sami tasky přebírají bez nutnosti přidělení.

Řešitel potvrzuji přidělení umožňuje řešiteli se vyjádřit k přidělenému tasku. Přidělený task může akceptovat nebo odmítnout.

Řešitel může přidělovat své tasky znamená možnost přidělit Řešiteli jeho task jiným řešitelům. Pokud není volba zaškrtnuta, má toto oprávnění pouze Servisní manažer.

Možnost přidělit vytvářený task rozšiřuje formulář nového tasku o možnost přiřadit řešitele nebo spoluřešitele (v závislosti na matici zobrazení rolí). Servisní manažer má tuto možnost vždy zapnutou.

Další volby se týkají tzv. rozšířeného workflow a jsou detailně popsány v uživatelském manuálu v kapitole 5. Rozšířené workflow v TaskPoolu. Jsou to:

  • Servisní manažer nebo manažer zadavatelů povoluje řešení tasku

  • Řešitel potvrzuje přidělení tasku

  • Servisní manažer kontroluje tasky

  • Zadavatel potvrzuje tasky

  • Fakturační smyčka

Smyčkou Schvalování podmínek nastavíme dané roli právo na schvalování deadline a ceny. Pokud bude mít toto právo např. pouze servisní manažer, ostatní uživatele mohou podat pouze návrh na změnu podmínek a servisní manažer je musí buď schválit nebo odmítnout.

Dále je možné nastavit, která role Může zakládat task zpětně. Hodnota "Zadán k řešení" je pak nastavena podle zvolené hodnoty při zadávání tasku a datum a čas skutečného zadání tasku je uvedem pouze v historii tasku v prvním komentáři.

Pokud je task ve stavu "Čekání na informace", aktivní pole Posunout o půlnoci deadline při čekání tasku zaručí, aby deadline tasku zůstávala v tomto stavu vždy stejná, resp. o půlnoci se deadline vždy prodlouží o jeden den. Např. task bude čekat týden na informace a deadline bude po celou dobu čekání vždy 5 dní. Jakmile task přejde zpět do řešení, deadline se opět začne odečítat.

Informace dodána komentářem zákazníka - pokud je task ve stavu Čeká na informaci a zákazník přidá komentář (buď ze zákaznického rozhraní nebo z e-mailu), přepne se task do předhozího stavu.

V dolní části obrazovky se pak nastavují práva pro možnost zobrazení a editace ceny a deadline jednotlivým rolím v jednotlivých stavech tasku.

Obrázek 3.4. Vytváření poolu: Karta Workflow (spodní část)

Vytváření poolu: Karta Workflow (spodní část)

V nastavení na obrázku bude moci zadavatel a řešitel stanovit cenu pouze při zakládání tasku, kdežto manažer zadavatelů a servisní manažer budou moci tuto položku editovat i ve stavech navržen k řešení, zadal k řešení a navržen k přidělení.

Karta Přístupová omezení

Pokud je v poolu větší množství zadavatelů a řešitelů, je vhodné blíže řídit zobrazování tasků a zasílání notifikací. Na této kartě můžeme nastavit, které tasky budou jednotlivým rolím přístupné a ze kterých tasků budou dostávat notifikace. Každý zadavatel, resp. řešitel může volitelně vidět všechny tasky a dostávat z nich notifikace, anebo vidět všechny tasky a dostávat notifikace pouze ze svých tasků. Poslední možností je vidět pouze svoje tasky a pouze z těchto tasků dostávat notifikace. Tímto nastavením docílíme zpřehlednění poolu jednotlivým rolím.

Obrázek 3.5. Vytváření poolu: Karta Přístupová omezení

Vytváření poolu: Karta Přístupová omezení

Sekci Zobrazení seznamu uživatelů určuje práva, která role vidí kterou roli, a to v libovolném seznamu uživatelů. Tento seznam nalezneme např. při přidělování tasku řešiteli apod. Defaultně je nastaveno, že všichni vidí všechny uživatele daného poolu, doporučujeme toto nastavení ponechat.

V sekci Skryté komentáře nastavujeme, které role mají právo vkládat k taskům skryté komentáře. Obecně platí, že skrytý komentář někoho z řešitelské strany (Řešitel, Servisní manažer) není viditelný zadavatelské straně (Zadavatel, Manažer zadavatelů) a opačně. Je také možno povolit, že komentář bude při každé úpravě tasku implicitně skrytý. Tím lze zamezit případnému úniku interních informací.

Možnost odesílat urgentní notifikace znamená, že daná role bude mít při úpravě tasku v dolní části checkbox "Urgentní". Pokud tento checkbox zaškrtne, všem uživatelům poolu přijde notifikace s výstražným statusem "URGENTNÍ !!!". Tato volba je zavedena proto, že někteří uživatelé nedokážou rozeznat rozdíl mezi skutečně urgentní záležitostí a tou méně důležitou, proto lze možnost zasílání urgentních notifikací zakázat.

Pokud je volba Zobrazovat zadavateli druhé a další přidělení nastavena na hodnotu "NE", zadavatel tasku uvidí v historii pouze první přidělení tasku konkrétnímu řešiteli. Pokud je poté task přidělen jinému řešiteli, tak tento zápis v historii již zadavatel neuvidí. Pokud je zvoleno "ANO", vidí zadavatel veškerou historii přebírání tasku, což však pro něj může být často zbytečná informace, a právě proto je zavedena tato volba.

Poslední volbou je Spoluřešitel přebírá práva řešitele. Pokud je tento checkbox zapnutý, má spoluřešitel stejná práva jako řešitel tasku. Pokud je vypnutý, může spoluřešitel pouze přidávat k tasku komentář a dostává z něj notifikace.

Karta Role

Uživatelé jsou vytvářeni a editováni na úrovni TaskPoolu. Role jsou uživatelům přidělovány administrátorem na úrovni poolu. V každém poolu lze do rolí definovat dostupný počet uživatelů (dle licence). Každému uživateli lze v konkrétním poolu přiřadit jednu ze 6 rolí. Každý pool musí obsahovat alespoň jednoho servisního manažera.

Obrázek 3.6. Vytváření poolu: Karta Role

Vytváření poolu: Karta Role

U každého uživatele je na konci označení [A] nebo [N], které odpovídá jeho stavu – aktivní nebo neaktivní. V seznamu nepřiřazených uživatelů jsou zobrazeni jen aktivní uživatelé. Zatržením pole Zobrazit neaktivní uživatele se do seznamu doplní i tito.

POZN.: Pokud v poli "Nepřiřazení" nejsou vidět žádní uživatelé, je nutné uživatele nejprve vytvořit (viz kapitola 2. Uživatelé TaskPoolu).

Stačí označit jednoho či více uživatelů v levém poli, a pomocí šipky ">>" přiřadit tyto uživatele do dané role. Analogicky lze postupovat obráceně. Změnu v rolích lze provádět kdykoliv během existence poolu, stejně tak jako jakékoliv jiné nastavení vlastností poolu.

POZN.: Pokud je uživatel deaktivován, je možné mu ponechat role ve všech poolech pro případ budoucí opětovné aktivace.

Karta Notifikace - časování

Notifikace jsou e-mailová upozornění uživatelům na změny v TaskPoolu. Na kartě "Notifikace - časování" můžeme nastavit frekvenci odesílání. Také nastavujeme adresu odesílatele a formát předmětu notifikačního mailu.

Obrázek 3.7. Vytváření poolu: Karta Notifikace - časování

Vytváření poolu: Karta Notifikace - časování

POZN.: Notifikace mohou být kromě e-mailů zasílány také formou SMS zpráv, viz kapitola 22. SMS.

V této sekci nastavujeme samotné časování notifikací. Volba Vždy zaručí, že notifikace bude odeslána okamžitě při změně tasku. To je však někdy obtěžující a proto lze nastavit hodnotu Perioda. Zde můžeme nastavit např. zasílání notifikací v době od 8:00 do 17:00 s periodou 1 hodiny. Tento souhrnný e-mail pak bude obsahovat notifikace ze všech tasků, které byly během minulé hodiny upraveny. Pokud zvolíme Nikdy, notifikace z poolu nebudou chodit vůbec. Výjimkou je urgentní notifikace, pokud je při úpravě tasku zaškrtnuto pole "Urgentní", dojde notifikace všem členům poolu.

Předmět notifikace

TaskPool umožňuje konfiguraci předmětu notifikačních e-mailů. Je možné nastavit odlišný předmět notifikace pro každý pool zvlášť. To lze využít např. pro lepší filtrování příchozí pošty či lepší přehlednost požadovaných hodnot.

POZN.: Tato nastavení se nevztahují na periodické notifikace, jejichž formát předmětu je pevný.

Ke konfiguraci předmětu notifikace lze využít všechny zástupné řetězce vypsané v dolní části obrazovky a zároveň lze mezi ně vložit libovolný statický text. Statický text se vkládá bez uvozovek a zobrazuje se vč. diakritiky.

Např. řetězec:

Comarr: <#ACTION> - Pool: <#JOBPOOL_NAME> / <#JOB_NAME>

může zobrazit např. tento text (samozřejmě záleží na konkrétní akci):

Comarr: Task zadán k řešení - Pool: Helpdesk / Nefunkční tiskárna ve druhém patře

POZN.: Někteří uživatelé nemusí mít právo vidět některé hodnoty. Např. zadavatel nemusí mít právo vidět interní řešitelskou prioritu tasku. I pokud je tomuto uživateli taková hodnota umístěna do notifikace, v e-mailu se mu nezobrazí.

Vkládání řetězců je velmi intuitivní, zde blíže rozebereme pouze případy s dynamickými poli (více o dynamických polích v kapitole 4. Dynamická pole.

  • <#DYNAMIC_FIELD identifikatorPole> - Hodnota dynamického pole s identifikátorem "idenitifikatorPole". Standardně se hodnoty dynamických polí objeví v předmětu notifikace pouze pokud dojde ke změně dotyčného dynamického pole. Pokud ke změně nedojde, hodnota se nezobrazí. Standardně je také v předmětu notifikace zobrazován i jeho název. I zde platí, že pokud je příjemcem notifikace uživatel v roli, která nemá právo dynamické pole vidět, v předmětu notifikace mu pole nebude zobrazeno.

    Řídící řetězce se do zástupných řetězců vkládají podle syntaxe:

    <#DYNAMIC_FIELD identifikator[Always][NoLabel]>

    • Always - způsobí, že dynamické pole se v předmětu notifikace zobrazí vždy, tj. nejen při jeho změně.

    • NoLabel - bude zobrazena pouze hodnota dynamického pole bez popisku.

      POZN.: Použití dynamického pole typu TextArea v předmětu notifikace je možné, ale víceřádkové vstupy systém v notifikacích převádí na jednořádkové. Doporučujeme vyhnout se jejich použití v předmětu notifikace.

      Příklady (předpokladem je vytvořené pole typu RadioButton, s identifikátorem "pb", s popiskem "Uloženo na pobočce:" a možnými hodnotami "Praha" a "Brno"):

      <#DYNAMIC_FIELD pb> - V případě změny pole bude zobrazeno např. "Uloženo na pobočce: Praha", pokud ke změně nedojde, nezobrazí se nic.

      <#DYNAMIC_FIELD pb Always> - Vždy bude zobrazeno např. "Uloženo na pobočce: Praha".

      <#DYNAMIC_FIELD pb Always NoLabel> - Vždy bude zobrazeno např. "Praha".

      <#DYNAMIC_FIELD pb NoLabel> - Pokud dojde ke změně zobrazí se např. "Praha", pokud ne, nebude zobrazeno nic.

Odesílatel notifikací

Dle pole "Od" (From) v notifikačním mailu lze snadno třídit notifikace v poštovním klientu do jednotlivých složek dle toho, z jakého poolu byly zaslány.

Notifikace po uživatelích

Tato volba umožňuje nastavit každému uživateli poolu unikátní časování notifikací. Tlačítko "Notifikace po uživatelích" se zobrazí při editaci již vytvořeného poolu (nelze provádět při vytváření nového poolu, protože ještě nejsou vložení uživatelé) dole na liště vedle tlačítek "Uložit" a "Zavřít okno".

Obrázek 3.8. Notifikace po uživatelích

Notifikace po uživatelích

Ve výběrovém poli nahoře lze pak vybrat konkrétního uživatele a změnit pro něj nastavení individuálně.

  • Podle nastavení v poolu - časování notifikací je převzato z nastavení poolu.

  • Podle nastavení uživatele - časování notifikací je převzato z uživatelského profilu, kde se dá nastavit stejným způsobem, jako zde v poolu.

  • Individuálně - časování notifikací lze nastavit zcela individuálně pro daného uživatele v daném poolu bez ohledu na nastavení uživatele či poolu.

Karta Priority

Na této kartě nastavujeme počet úrovní priorit využívaných daným poolem (tedy například od 1 do 4) a rovněž názvy jednotlivých priorit v podporovaných jazycích (Kritická, Vysoká, Střední, Nízká atd.). Můžete také určit, která priorita bude při zakládání tasku výchozí.

Dále zde lze nastavit, zda bude priorita zobrazena jako ID (číslo 1-5), nebo jako Label (nastavený název daného stupně priority). Toto lze nastavit zvlášť pro detailní zobrazení a pro výpis tasků.

V dolní části formuláře lze nastavit právo vidět prioritu tasku podle rolí (sloupec "Zobrazit") a také právo měnit prioritu tasků podle rolí a stavu tasku (ostatní sloupce).

Obrázek 3.9. Vytváření poolu: Karta Priority

Vytváření poolu: Karta Priority

Při konfiguraci na obrázku vidí prioritu všechny role, přitom Manažer zadavatelů a Zadavatel mohou určit prioritu pouze při zakládání tasku a Servisní manažer může měnit prioritu při zakládání a ve stavech Zadal k řešení, Převzat, Navržen k přidělení a Nové podmínky.

Karta SLA schémata

Na této kartě je možné nastavit, která SLA schémata budou použita pro daný pool a které bude výchozí. Nastavení práv pro změnu a zobrazení SLA a pro nastavení manuálního update time probíhá obdobně jako u priorit nebo dynamických polí. Podrobně o konfiguraci SLA schémat v kapitole 18. SLA.

Obrázek 3.10. Vytváření poolu: Karta SLA schémata

Vytváření poolu: Karta SLA schémata

Karta Pole

Na této kartě lze nastavit, která dynamická pole budou v poolu zobrazena a kterým rolím. Do jednotlivých poolů přidělujeme dynamická pole z globálního seznamu vytvořených polí. Více v kapitole 4. Dynamická pole.

Obrázek 3.11. Vytváření poolu: Karta Pole

Vytváření poolu: Karta Pole

U polí, která chceme vložit do poolu, je třeba mít vlevo aktivní checkbox "Zobrazit pole" a zadat hodnotu "Pořadí", dle které se budou pole v tasku zobrazovat. Jako pořadí se zadávají kladná čísla od sebe různá. Pole s nejnižším číslem bude zobrazeno nejvýše. Doporučujeme číslovat pole např. 10, 20, 30 atd. z důvodu možného přidávání dalších polí mezi již existující pole, to by číslování 1, 2, 3 apod. neumožnilo.

Práva vidět a editovat pole lze nastavit obdobně jako u nastavení priorit po rozkliknutí příslušného odkazu "Upravit přístupová omezení". Jednotlivým rolím lze přesně nastavit, zda budou pole vidět a ve kterých stavech tasku budou mít možnost pole upravit. Hodnota "Zobrazit i ve výpisu" určuje, zda bude hodnota pole zobrazena i ve výpisu tasků na pracovišti. Pokud zde nechceme zobrazovat hodnoty prázdných polí, toto zrušíme checkboxem "Nezobrazovat prázdná dynamická pole na pracovišti".

Dále lze nastavit ve kterých stavech bude vyžadvoáno zadat hodnotu daného pole. V konfiguraci na obrázku např. nebude možné dokončit task bez zadání hodnoty do pole "Counter".

Karta E-mail Interface

Taskpool umožňuje nastavit vybírání e-mailové schránky přes IMAP nebo POP3 protokol a z došlých e-mailů vytvářet tasky. Potom mohou jak uživatelé TaskPoolu, tak helpeskoví uživatelé zakládat tasky nebo přidávat komentáře pouhým zasláním e-mailu na danou e-mailovou adresu.

Popis e-mailového rozhraní

Pro příjem e-mailových požadavků je využíván protokol IMAP nebo POP3, známý zejména z e-mailových klientů, kde jsou jím e-maily stahovány do počítače. Zde je princip obdobný, ale e-maily se vloží do TaskPoolu jako nové tasky. Toto nastavení se provádí pro každý pool zvlášť. Je tak jasné, do kterého poolu se budou tasky z dané schránky vkládat.

K umožnění příjmu e-mailů je potřeba změnit stav na aktivní a vyplnit konfigurační položky.

Obrázek 3.12. Vytváření poolu: Karta E-mail Interface

Vytváření poolu: Karta E-mail Interface

V případě, že chceme Použít TLS ověření, je mimo zaškrtnutí toho políčka nutné do Javy importovat nástroj "Keytool" podle návodu na této adrese: https://docs.oracle.com/javase/8/docs/technotes/tools/#security

V momentě, kdy přijde po aktivaci této funkce na zadanou adresu libovolný e-mail, TaskPool z něho vytvoří nový task v daném poolu. Předmět e-mailu je brán jako předmět tasku, text e-mailu se uloží do popisu tasku. Datum vypršení tasku se nastaví implicitně pro daný pool. Pokud v TaskPoolu řešitel na tento task odpoví, původnímu odesílateli (zadavateli) dojde odpověď na e-mail. Pokud znovu odpoví na tento e-mail, reakce se zapíše jako komentář k již existujícímu tasku. Odesílatel tak vůbec nemusí tušit, že je v cestě vůbec nějaký TaskPool.

E-mailové rozhraní pro uživatele TaskPoolu

Pro povolení e-mailového rozhraní přímo pro uživatele TaskPoolu je třeba ještě namapovat jejich jména na adresy, ze kterých by e-maily měly chodit. Tyto adresy nemusí být totožné s adresami, na které chodí těmto uživatelům notifikace. Mapování se provádí na kartě "POP3 přiřazení" v administrační části. Více v kapitole 14. POP3 přiřazení.

E-mailové rozhraní pro modul Helpdesk

I modul Helpdesk nabízí příjem požadavků e-mailem. To je možné provádět pro ověřované uživatele Helpdesku (jak LDAP, tak DB ověřování) i pro uživatele bez ověření (pokud je to v nastavení Helpdesku povoleno). Více v kapitole 17.16. E-mail Interface na Helpdesku.

POZN.: E-mailové rozhraní Helpdesku má přednost před klasickým e-mailovým rozhraním. V poolu je možné nastavit pouze jedno z nich, pokud budou aktivní obě, task vytvořený z došlého e-mailu bude vždy vypadat jako helpdeskový.

Řešení konfliktů v adresách

Ke konfliktům dochází, když je jedna e-mailová adresa přiřazena jak uživateli TaskPoolu, tak Helpdesku. Prioritu představuje pořadí, ve kterém se zprávy z POP3 schránky vybírají:

  • Nejdříve systém v e-mailové schránce najde a vybere všechny e-maily od mapovaných uživatelů TaskPoolu a přiřadí je k taskům.

  • Potom najde a vybere zprávy od ověřovaných uživatelů Helpdesku (LDAP nebo DB ověření) a přiřadí je k taskům.

  • Pokud je v nastavení Helpdesku povoleno anonymní zakládání tasku, pak zbylé e-maily ve schránce vybere a vloží je jako požadavky od anonymních uživatelů Helpdesku. Pokud není povoleno anonymní zadávání tasků, zbylé e-maily budou odstraněny!

Karta Evidence nákladů

Na této kartě nastavujeme práva pro jednotlivé skupiny činností záznamů času. Více o konfiguraci záznamů času v kapitole 21. Evidence nákladů.

Obrázek 3.13. Vytváření poolu: Karta Evidence nákladů

Vytváření poolu: Karta Evidence nákladů

Pro každou roli můžeme přidělit jednu skupinu činností. V našem příkladu byla servisním manažerům přidělena skupina činností Customer service a řešitelům skupina Developement. Při vytváření záznamu času se budou každé roli zobrazovat všechny činnosti z dané skupiny činností a budou do nich moci zapisovat.

V další části obrazovky nastavujeme možnosti zobrazení. Na výběr jsou tyto:

  • Záznamy uživatelů vidí uživatel a manažeři poolu - Záznamy času uvidí pouze konkrétní řešitel a všichni servisní manažeři daného poolu. Záznamy zadavatelů uvidí pouze konkrétní zadavatel a všichni manažeři zadavatelů daného poolu.

  • Záznamy uživatelů vidí i ostatní ze stejné strany - Všechny záznamy času uživatelů z řešitelské strany (Řešitel, Servisní manažer) jsou viditelné řešitelské straně, to samé platí pro zadavatelskou stranu.

  • Záznamy času vidí všichni uživatelé poolu včetně protistrany - Jedná se o zcela otevřené nastavení. Každý uživatel, který má v poolu nějakou roli, uvidí záznamy času každého uživatele daného poolu.

Formát zadávání záznamů volíme následující:

  • Datum začátku a konce nebo datum začátku a počet hodin - při zadávání záznamu času bude nutné vždy zadat datum a čas začátku činnosti a dále zadat buď počet hodin nebo datum a čas konce.

  • Pouze počet hodin - při zadávání záznamu času bude stačit zadat pouze hodnotu odpracovaných hodin.

Dále nastavujeme, kterým rolím se zobrazí součet všech vykázaných časů k danému tasku.

Karta Plánování

Funkce plánování slouží pro přehlednou evidenci harmonogramu řešení jednotlivých tasků. Řešení každého tasku je možné naplánovat na libovolný termín či časový úsek. Schéma naplánovaných tasků je pak možné importovat do softwarů pracujících s kalendáři, otestovány jsou aplikace Microsoft Outlook 2007 a 2010 a Mozilla Lightning, Apple iCal a Google Calendar.

Obrázek 3.14. Vytváření poolu: Plánování

Vytváření poolu: Plánování

Práva na tvorbu plánování se nastavují stejně jako pro dynamická pole, právo plánovat tedy můžeme přidělit např. pouze řešitelské straně apod. Stejně tak lze nastavit ve kterých stavech bude toto pole povinné. V editaci tasku se pak oprávněným rolím zobrazí další dvě položky, do kterých se vyplňují datumy pro plánování.

Obrázek 3.15. Plánování v editaci tasku

Plánování v editaci tasku

Podle nastavení na obrázku máme práci na daném tasku naplánovaou od 3.6.2018 od 8:00 do 3.6.2018 do 11:30.

V případě aktivní volby Využívat hodnotu "vyprší" když jsou datumy nevyplněné odpadá nutnost vyplňování jednotlivých datumů. Pokud je alespoň jedno pole nevyplněné, TaskPool automaticky dosadí hodnotu vyprší (deadline). Pro lepší kontorlu při plánování tasků však doporučujeme tuto volbu vypnout.

Import do jiných systémů

Import naplánovaných tasků do kalendářových systémů je možné provést buď automaticky nebo manuálně. Oba postupy jsou popsány v uživatelském manuálu v kapitole 11. Plánování.

URL daného kalendáře je možné získat dvěma způsoby. Zde bude popsán právě ten, u kterého je potřeba asistence administrátora.

Pro příklad použijeme import do Mozilla Lightning, postup importu v ostatních aplikacích je obdobný. Pomocí volby Soubor -> Nový objekt -> Kalendář... otevřeme okno pro vytvoření nového kalendáře.

Karta Provazování tasků

Na této kartě je možné blíže specifikovat možnosti vazeb mezi jednotlivými tasky. Provazování tasků je popsáno v uživatelském manuálu v kapitole 6. Vazby mezi tasky.

Obrázek 3.16. Provazování tasků

Provazování tasků

Volné provazovaní tasků umožňuje jednotlivým rolím při úpravě tasků v daném poolu vytvářet libovolné vazby do jiných poolů, do kterých mají přístup. Mohou tedy vytvářet nové rodičovské tasky, podřízené tasky a odkazy k danému tasku nebo těmito vazbami svazovat task s dalšími již existujícími tasky.

Kopírovat zadavatele - volba umožní zkopírovat do cílového poolu zadavatele původního požadavku (pokud to umožňuje konfigurace cílového poolu).

Informovat nadřízený task o dokonční - pokud je tato volba zaškrtnuta, dojde při ukončení (dokončení, deaktivaci, přesunutí nebo exportu) subtasku k vložení komentáře do nadřízeného tasku. Pokud dojde k ukončení posledního subtasku, hlásí komentář Ukončení všech subtasků.

Na této kartě je dále možné nastavit tlačítka pro zjednodušení vytváření vazeb. Tlačítko předem definuje, která vazba a do kterého poolu se bude vytvářet. V okně úpravy tasku se pak tyto tlačítka zobrazí pod oknem pro komentář a po kliknutí na ně se automaticky zobrazí formulář pro založení nového tasku do předem nastaveného poolu.

Okno pro přidání vazby může vypadat takto:

Obrázek 3.17. Provazování tasků

Provazování tasků

Pokud má daný uživatel (role) právo na volné provazování tasků, je mu dostupné po kliknutí na odkaz pod tlačítky.

Kopírování poolů

Konfiguraci jednotlivých poolů je možné kopírovat. Kopíruje se pouze konfigurace, tasky zadané v daném poolu se nekopírují. Kopírování je možné provést kliknutím na tlačítko "Kopírovat Pool" ve výpisu poolů. Objeví se formulář pro vytvoření nového poolu s tím rozdílem, že veškerá konfigurace včetně názvu se shoduje s konfigurací kopírovaného poolu. Stačí změnit název poolu a kliknout na tlačítko "Uložit". V seznamu poolů se objeví nový pool se shodnou konfigurací. Samozřejmě je možné v kopírované konfiguraci dále provádět libovolné změny. Podobně je možné kopírovat Helpdesky, viz kapitola 17.17. Kopírování Helpdesků.

Kapitola 4. Dynamická pole

Dynamická pole umožňují definovat libovolné přídavné datové struktury. Lze je vytvářet v administraci TaskPoolu a přiřazovat jednotlivým poolům.

Obrázek 4.1. Příklady dynamických polí

Příklady dynamických polí

Dynamická pole defacto reprezentují další vlastnosti tasku a lze je dále využít pro uchování různých hodnot v tasku nebo např. v kombinaci s filtry pro zobrazení tasků podle hodnot těchto polí. Dynamická pole také umožňují načítat do tasku data z externích databází.

Vytváření a editace dynamických polí je k dispozici na kartě "Pole" v administrátorské sekci. Vytváření probíhá standardně pomocí tlačítka "Nový" a editace kliknutím na název již existujícího pole.

Vytvoření dynamického pole

Ve formuláři pro vytvoření nového pole nejprve vybereme typ dynamického pole, systémový identifikátor (jedná se o název, který jednoznačně identifikuje pole a je pro každé pole unikátní), dále pak název pole podle jednotlivých jazyků (jak se zobrazí uživatelům TaskPoolu) a výchozí hodnotu pole. Výchozí hodnota se bude implicitně zobrazovat do první úpravy pole, např. u textových polí je to předvolený text.

Do kolonky "OnChange" je možné zapsat libovolný javascript. Těchto scriptů může být i více, oddělují se znakem středníku (";"). Tyto scripty se automaticky provedou vždy po načtení pole. Můžeme tak tvořit např. závislosti mezi jednotlivými poli. Toto je popsáno a nastaveno v ukázkových konfiguracích, které vám na požádání rádi předvedou naši pracovníci.

Tyto vlastnosti mají všechna pole společná. Další vlastnosti se liší podle typu pole a budou přiblíženy v následujících kapitolách.

Textfield

Toto pole slouží pro zápis libovolného textu do jednoho řádku. Po volbě typu pole se dá kromě obecných vlastností zadat velikost pole a maximální počet znaků, oboje v počtech znaků.

Obrázek 4.2. Vytváření dynamického pole typu Textfield

Vytváření dynamického pole typu Textfield

V praxi pak pole vypadá takto:

Obrázek 4.3. Dynamické pole Textfield v praxi

Dynamické pole Textfield v praxi

Textarea

Dynamické pole Textarea je podobné typu pole Textfield s tím rozdílem, že umožňuje zápis textu na více řádků. Při vytváření máme možnost nastavit počet řádků pole a jeho šířku.

Radiobutton a Selectbox

Tyto dva typy pole mají obdobná nastavení, liší se především zobrazením. Výhodou Radiobuttonu je také nutnost pouze jednoho kliku pro vybrání určité z možností, u selectboxu jsou nutné kliky dva. Selectboxem je ale navíc možné řídit workflow tasku, více v kapitole 5. Rozšíření dynamických polí.

Při vytváření nového pole vybereme typ pole, a kromě obecných vlastností vytvoříme jednotlivé položky výběru, a to na kartě "Možnosti".

Do pole "Výchozí hodnota" zadáváme ID výchozí možnosti.

Obrázek 4.4. Vytváření možností polí Selectbox a Radiobutton

Vytváření možností polí Selectbox a Radiobutton

U pole typu Selectbox se nabízí našeptávač, který usnadňuje nalezení hledaného záznamu.

Obrázek 4.5. Dynamické pole Selectbox

Dynamické pole Selectbox

Multi Selectbox

Dynamické pole Multi Selectbox pracuje podobně jako klasický Selectbox, ale umožňuje vybrat několik možností najednou.

Obrázek 4.6. Dynamické pole Multi Selectbox v praxi

Dynamické pole Multi Selectbox v praxi

Checkbox

Tento typ pole představuje zaškrtávací pole. kromě obecných vlastností nemá toto pole jiné možnosti nastavení.

Obrázek 4.7. Dynamické pole Checkbox v praxi

Dynamické pole Checkbox v praxi

Number

Pole typu Number je podobné poli Textfield s tím rozdílem, že uchovává pouze číselnou hodnotu. TaskPool hlídá vstupní hodnoty pole a jiné než číselné nepovolí. Pro zápis desetinných čísel je použita desetinná tečka (v poli se pak tedy zobrazí např. 10.564, u celých čísel se zobrazí 10.0).

Counter

Tento typ reprezentuje čítač. Hodnota vložená do tohoto pole při úpravě tasku původní hodnotu nenahrazuje, ale přičítá. Pokud tedy do pole typu Counter s hodnotou 20 napíšeme při úpravě tasku hodnotu 5, po uložení bude v poli hodnota 25. Jednotlivé změny pole jsou zapsány v historii tasku. Zadávat lze i záporné hodnoty.

Hodnota tohoto pole může mít desetinnou podobu (např. 15.27), přičemž TaskPool používá stejně jako v poli Number desetinnou tečku.

Toto pole je vhodné použít např. pro zápis ujetých kilometrů. Nedoporučujeme pole používat pro zápis odpracovaných hodin, k tomu je v TaskPoolu implementována speciální funkce, více v kapitole 21. Evidence nákladů.

Date, Time a DateTime

Jak název napovídá, v těchto polích lze uchovávat hodnoty data, času, resp. hodnoty data i času zároveň. Na ty pak lze použít rozšířené možnosti třídění, např. ve filtrech můžeme vyhledávat určité časové úseky, více v kapitole 7. Filtry.

Vstupy se zadávají ve formátu:

  • Pole Date - den.měsíc.rok

  • Pole Time - hodina:minuta

  • Pole DateTime - den.měsíc.rok hodina:minuta

Pro zadávání dat lze využít přidružené kalendáříky.

Obrázek 4.8. Dynamické pole DateTime v praxi

Dynamické pole DateTime v praxi

SQL Selectbox

Pro konfiguraci tohoto pole je nutná základní znalost jazyka SQL a Javascriptu. Pokud těmito znalostmi nedisponujete, doporučujeme konfiguraci konzultovat s pracovníky Comarr spol. s r.o.

SQL Selectbox je pole, které umožňuje využívat externí databázi. Používáme ho např. když chceme použít selectbox s velkým počtem možností, které jsou uloženy právě v externí databázi nebo pro vytvoření postupně závislých polí. Vyhneme se tak nutnosti konfigurovat každou možnost zvlášť do klasického selectboxu. Může se jednat o výběr typů zařízení, pracovišť apod. Výčet možností je velmi flexibilní, protože nepracuje se statickým výčtem možností, ale s SQL dotazy.

Předpokladem pro vytvoření SQL Selectboxu je správně nakonfigurované ověření. V tomto ověření je určena databáze, která bude použita pro výběr možností SQL Selectboxu (více o ověření v kapitole 16. Ověření).

Podobně jako u klasického Selectboxu můžeme zvolit, zda bude použit našeptávač. Našeptávač je vhodný zejména tehdy, pokud máme na výběr velké množství možností.

OnChange volání u SQL selectboxu

Zopakujme, že do tohoto pole se zadávají příkazy, které se postupně vykonají po načtení dynamického pole a při změně hodnoty tohoto pole. Jednotlivé příkazy se oddělují středníkem (";"), jedná se javascriptový kód. U SQL Selectboxu mohou být tyto příkazy:

  • LoadDependentOptionsByHdUsername('promenna') – aktualizuj SQL selectbox s názvem "promenna" za použití parametru HDUsername. HdUsername je uživatelské jméno uživatele přihlášeného na helpdesku.

  • LoadDependentOptions('promenna', this.value) - aktualizuj SQL selectbox s názvem "promenna" za použití parametru aktuální hodnoty tohoto dynamického pole.

  • LoadDfValuesFromDb('n','SELECT a as dfa FROM … WHERE …') – nastavení hodnot dynamických polí dotazem z databáze, přičemž pro dotaz je použito ověření číslo n.

Příklad 1)

LoadDependentOptionsByHdUsername('CSlokalita')

...do dynamického pole CSlokalita vytvoří nový seznam možností za použití hodnoty HdUsername.

Příklad 2)

LoadDependentOptions('CSzarizeni', this.value)

...do dynamického pole CSzarizeni vytvoří nový seznam možností za použití aktuální hodnoty tohoto pole.

Příklad 3)

LoadDfValuesFromDb('3','SELECT z.sn as CSsn, z.pn as CSpn,
   p.nazev as CSprojekt, z.id_tp_sla as sla_schema FROM zarizeni z
   JOIN projekt p ON(z.id_projekt = p.id)
   WHERE z.id = \':fieldValue\'', this.value)

...do polí CSsn, CSpn, CSprojekt, sla_schema zapíše hodnoty dle uvedeného SQL dotazu, přičemž do \':fieldValue\' dosadí aktuální hodnotu tohoto pole a použije ověření číslo 3.

POZN.: Z těchto příkladů je zřejmé, že je možné adresovat nejen dynamická pole, ale i jiné proměnné tasku.

SQL základní

Samotné SQL příkazy pro výběr možností se nastavují na kartě "Možnosti".

Výběr "Připojení k databázi" nám nabízí všechna nakonfigurovaná ověření. Zvolené ověření se bude používat pro výběr možností SQL Selectboxu.

Obrázek 4.9. Nastavení SQL Selectboxu

Nastavení SQL Selectboxu

SQL základní vrací seznam hodnot, které mají být naplněny do SQL Selectboxu po otevření stránky.

Příklad 1)

SELECT l.id as optionIdent, l.nazev as label FROM lokalita l
   WHERE l.id = 0

...vrátí seznam všech lokalit, kde id = 0.

Příklad 2)

SELECT 0 optionIdent, '' as label, '' as shortcut

...doplní prázdné hodnoty do selectboxu.

SQL závislé

Vrátí seznam všech závislých možností SQL Selectboxu, které mohou být zvoleny. Tento dotaz je použit pouze v případě závislého volání (LoadDependentOptions...). Množinu lze omezit též v závislosti nadřazeného dynamického pole či helpdeskového uživatele.

Příklad 1)

(SELECT 0 as optionIdent,'' as label, '' as shortcut)
   UNION SELECT l.id as optionIdent, l.nazev as label
   FROM lokalita l LEFT JOIN uzivatel u
   ON (u.id_zakaznik = l.id_zakaznik)
   WHERE l.aktivni = 1 AND u.login = '?'

...vybere seznam lokalit dle helpdeskového zákazníka. Protože však v tomto příkladu neexistuje nadřazené dynamické pole, které by předalo svojí hodnotu pro vymezení množiny, ale množina má být vymezena dle aktuálního helpdeskového zákazníka, je nutno při zobrazení této proměnné ještě jednou obnovit s tím, že sdělíme, která hodnota má být použita – uživatelské jméno helpdeskového uživatele. Toto uděláme tak, že na záložce "Základní" do pole "OnChange" zapíšeme příkaz "LoadDependentOptionsByHdUsername('lokalita');", příčemž 'lokalita' je název této proměnné SQL Selectboxu.

POZN.: Aby tato konstrukce fungovala správně i na Helpdesku, musí být v helpdeskovém formuláři použit input <#hd_login> (může být i hidden). Více v kapitole 17. Helpdesk.

Dále v uvedeném příkladu je použita hodnota "aktivni" u lokalit k tomu, aby byly zobrazovány pouze aktivní lokality. Konstrukce "(SELECT 0 as optionIdent,'' as label, '' as shortcut) UNION" před příkazem pro výběr z databáze je použita k tomu, aby součástí seznamu hodnot byla i prázdná hodnota (tj. implicitně nezvolena žádná hodnota). V nastavení "výchozí hodnota" lze pak např. zvolit 0, aby byl implicitně nastaven tento prázdný řádek.

Příklad 2)

V podřízeném SQL Selectboxu "zarizeni", které má být závislé na konkrétní lokalitě, může SQL pro výběr možností vypadat takto:

(SELECT 0 as optionIdent,'' as label, '' as shortcut)
   UNION SELECT id as optionIdent, tag as label FROM zarizeni
   WHERE id_lokalita = '?' AND aktivni = 1 ORDER BY label

Do nadřazeného SQL Selectboxu je nutno do pole "OnChange" vložit tento příkaz: "LoadDependentOptions('CSzarizeni', this.value)".

SQL možnosti

Slouží k výběru hodnot, které jsou zobrazeny po výběru konkrétní možnosti (např. ve výpisu tasků).

Příklad 1)

SELECT l.id as optionIdent, l.nazev as label
   FROM lokalita l WHERE l.id = '?'

SQL všechny

Slouží k širší definici všech možností. Výsledný seznam je použit pro ad-hoc vyhledávání (Quickfilter) a při výpisu závislých hodnot na HDUsername, v případě, že se nejedná o helpdeskový task.

Přestože u SQL Selectboxu je již volba způsobu zobrazení, u SQL všechny je navíc možné zvolit, zda-li je tento vyhledávací prvek v Quickfiltru zobrazen jako Autocomplete či Selectbox. Je to z toho důvodu, že množina zobrazená v SQL Selectboxu může být většinou omezená nadřazeným polem, avšak souhrn všech možností může být značně velký.

Příklad 1)

SELECT l.id as optionIdent, l.nazev as label FROM lokalita l

Možnost Nedefinováno

U každého SQL Selectoboxu je možné povolit možnost "Nedefinováno". S touto možností se pracuje na úrovni TaskPoolu, nemusí tedy vůbec existovat v databázi. Možnost Nedefinováno není obsahem SQL dotazu, ale v případě použití se vždy nalepí na výsledek SQL dotazu a obsahuje hodnotu nula ("0").

Možnost nedefinováno není dobré používat tam, kde některý z dotazů tuto hodnotu obsahovat nemá. V těchto případech je správné, aby tuto možnost vracel přímo SQL dotaz - tedy buď aby byla možnost Nedefinováno obsažena již v databázi nebo její zobrazování zařídit modifikací SQL dotazu pomocí operátoru UNION.

Možnosti Nedefinováno je možné nastavit label v každém ze tří jazyků, včetně rozšířeného labelu a zkratky.

Příklady konfigurace SQL Selectboxů

Příklad 1) Jednoduchý SQL selectbox

Dynamické pole má identifikátor "Kategorie".

SQL základní: SELECT 0 optionIdent, '?' as label
   UNION SELECT k.ID as optionIdent, k.kategorie as label
   FROM kategorie k WHERE k.aktivni = 1
SQL závislé: (prázdné)
SQL možnosti: SELECT k.ID as optionIdent, k.kategorie as label
   FROM kategorie k WHERE k.ID = '?'
SQL všechny: SELECT k.ID as optionIdent, k.kategorie as label
   FROM kategorie k
Výchozí hodnota: 0

Příklad 2) SQL Selectbox závislý na jiném SQL Selectboxu

Dynamické pole má identifikátor "Podkategorie". V tomto příkladu použijeme SQL Selectbox nakonfigurovaný dle příkladu 1 a navíc vytvoříme druhý závislý SQL Selectbox "Podkategorie".

Do konfigurace nadřazeného pole (v příkladu 1) navíc zapíšeme do pole "OnChange" tento příkaz: LoadDependentOptions('Podkategorie', this.value);

Podřazený SQL Selectbox "Podkategorie" pak obsahuje tyto hodnoty:

SQL základní: SELECT 0 optionIdent, '?' as label
SQL závislé: SELECT 0 optionIdent, '' as label UNION SELECT pk.ID as
   optionIdent, pk.podkategorie as label FROM podkategorie pk
   WHERE pk.kategorie = '?' and pk.aktivni = 1
SQL možnosti: SELECT pk.ID as optionIdent, pk.podkategorie as label
   FROM podkategorie pk WHERE pk.ID = '?'
SQL všechny: SELECT pk.ID as optionIdent, pk.podkategorie as label
   FROM podkategorie pk
Výchozí hodnota: 0

Příklad 3) SQL Selectbox závislý na přihlášeném uživateli

Dynamické pole má identifikátor "Lokalita".

Do pole "OnChange" zapíšeme tento příkaz: LoadDependentOptionsByHdUsername('lokalita');

SQL základní: SELECT 0 optionIdent, '?' as label
SQL závislé: SELECT l.ID as optionIdent, l.lokalita as label
   FROM lokalita l join users u on (u.lokalita = l.ID)
   and u.username = '?' and l.aktivni = 1
SQL možnosti: SELECT l.ID as optionIdent, l.lokalita as label
   FROM lokalita l WHERE l.ID = '?'
SQL všechny: SELECT l.ID as optionIdent, l.lokalita as label
   FROM lokalita l

Kapitola 5. Rozšíření dynamických polí

Pro pochopení této kapitoly doporučujeme nejdříve přečíst kapitolu 4. Dynamická pole.

Pole typu Selectbox má některé rozšířené vlastnosti, které mohou ovlivňovat workflow celého poolu a umožňují administrátorům průběh řešení tasků zcela přizpůsobit požadavkům firmy.

Tasky mohou měnit své stavy pouze na základě hodnot tohoto dynamického pole a naopak. Lze si vytvořit vlastní stavy tasků (např. pro odbyt "Objednán", "Ve výrobě", "Skladem", "Expedován"). TaskPool pak stavy sám odliší a uživatel vůbec nemusí používat stavy TaskPoolu (Zadán k řešení, Převzat, apod.). Vlastní firemní terminologií se tedy dá "překrýt" terminologie TaskPoolu.

Dále je možné nastavit pravidla pro přechody mezi jednotlivými možnostmi Selectboxu. Implicitně jsou povoleny všechny přechody, tedy z libovolné hodnoty můžeme pole přepnout na libovolnou jinou hodnotu. Toto rozšíření umožňuje nastavit přesná pravidla pro tyto přechody. Např. pokud je zboží již expedováno, nemůže být ještě na skladě. Můžeme provést takové nastavení, které umožní přechod z "Skladem" na "Expedován", ale opačně to už nepůjde.

Tato nastavení se definují pro každé pole typu Selectbox zvlášť.

Změna hodnoty dynamického pole v závislosti na změně stavu tasku

Hodnota Selectboxu se může automaticky měnit na základě změny stavu tasku (automatické, či provedené uživatelem).

Pro každý Selectbox lze pomocí trojice hodnot definovat podmínku, při jejímž splnění dojde ke změně hodnoty dynamického pole. Tato trojice hodnot se skládá z:

  • Koncový stav workflow - tedy změna stavu (např. Dokončen), která by měla změnu hodnoty dynamického pole spustit.

  • Počáteční stav dynamického pole - hodnota, ze které by se pole mělo změnit. Pokud je aktuální hodnota pole různá od hodnoty nastavené zde, změna hodnoty pole se při změně stavu neprovede.

  • Koncový stav dynamického pole - tedy hodnota dynamického pole, která bude do pole umístěna po uskutečnění akce.

Pro úspěšné spuštění akce musí být splněny obě podmínky (počáteční hodnota dynamického pole a změna stavu na koncový stav workflow).

Podmínky jsou definovány pomocí výběru možných hodnot Selectboxu a jsou nezávislé na rolích uživatelů v poolu a aktuální workflow poolu. Pokud uživatel nemá právo měnit hodnotu dynamické pole a provede změnu workflow (např. dokončí task), dynamické pole zůstane nezměněno. O změnách workflow a hodnot dynamických polí jsou uživatelé standardně upozorňováni notifikacemi a tyto změny jsou zaznamenávány v historii tasku.

Obrázek 5.1. Změna hodnoty dyn. pole v závisloosti na stavu workflow

Změna hodnoty dyn. pole v závisloosti na stavu workflow

Pokud v našem příkladu kdokoliv v poolu (kdo má současně právo měnit hodnotu tohoto dyn. pole) převezme task a zároveň bude u dotyčného tasku hodnota tohoto Selectboxu Čeká na objednání, pak se provede automatická změna hodnoty pole na Objednáno. Podobný sled událostí proběhne při dokončení tasku.

Změna stavu tasku na základě změny dynamického pole

Pro každý Selectbox je možné pomocí dvojice hodnot definovat podmínku, při jejímž splnění dojde ke změně stavu tasku. Dvojice ve složení:

  • Koncová hodnota dynamického pole - hodnota dynamického pole, která spouští automatickou akci.

  • Koncový stav workflow - hodnota, na kterou se změní stav tasku, pokud dojde ke změně dynamického pole na koncovou hodnotu v podmínce.

Podmínky jsou nezávislé na roli uživatelů v poolu a aktuální workflow nastavené v poolu. Pokud uživatel nemá právo měnit workflow a provede změnu dynamického pole, workflow zůstane nezměněno.

Obrázek 5.2. Změna stavu tasku na základě změny hodnoty dynamického pole

Změna stavu tasku na základě změny hodnoty dynamického pole

O změnách workflow a dynamických polí jsou uživatelé standardně upozorňováni notifikacemi a tyto změny jsou zaznamenávány v historii tasku.

TaskPool obsahuje stavy, do kterých nelze automaticky přejít, protože jsou nutné další parametry změny stavu.

Stavy, do kterých nelze automaticky přejít:

  • V zastoupení zadán k řešení - vyžaduje hodnotu zadavatele

  • Navržen k přidělení - vyžaduje hodnotu navrženého řešitele

  • Přidělen - vyžaduje hodnotu řešitele

  • Nové podmínky - vyžaduje hodnotu deadline, popř. ceny

Konfliktní situace a jejich řešení

V průběhu řešení tasku může dojít k tzv. konfliktním situacím. Tyto situaci nastávají ve chvíli, kdy by mělo dojít ke změně workflow na stav, který v daném poolu není možný. V daném poolu např. vůbec nemusí být možný stav Potvrzen, ale může existovat pravidlo, které tuto změnu požaduje. Tyto situace jsou potom řešeny podle následujícího klíče:

Tabulka 5.1. Postup při řešení konfliktních situací

Konfliktní stavAkce v případě, že daný stav není v poolu možný
Navržen k řešeníZadán k řešení
ZkontrolovánA) Čekání na archivaci B) Bez akce
PotvrzenA) Čekání na archivaci B) Bez akce
VyúčtovánČekání na archivaci

POZN.: Pravidlo A) platí, pokud ve workflow již není žádný další stav, pravidlo B) platí, pokud ve workflow je ještě nějaký jiný stav před archivací.

Dále může docházet ke konfliktům, způsobených odlišnostmi pravomocí jednotlivých rolí, např. Zadavatel nemůže task převzít. Tyto konflikty se potom řeší následujícím způsobem (číselné označení stavů tasků je popsáno v kapitole 7.2. Definice filtru):

  • Převzetí tasku je možné pouze pro Řešitele a Servisní manažery. Jedná se o přechod ze StateID < 10 do StateID > 10. Uživatel, který vyvolá přechod, je pak u tasku uveden jako Řešitel (netýká se stavu Čekání na informace).

  • Při přechodu ze StateID > 10 do StateID < 10 je z tasku odebrán řešitel (netýká se stavu Čekání na informace).

Těmto konfliktům je možné efektivně předcházet nastavením práv pro možnost úpravy dynamického pole v jednotlivých stavech. Ta se nastavují v konfiguraci poolu na kartě "Pole" (viz kapitola 3.8. Karta Pole). Zadavateli tak např. neumožníme úpravu pole do té doby, než je task převzat.

Omezení možností přechodů

Tato funkce umožňuje kontrolovat situaci, kdy hodnota dynamického pole může být závislá na hodnotě předchozí. V praxi tedy můžeme určit, na které hodnoty můžeme současnou hodnotu změnit, a na které ne. Tato omezení jsou nezávislá na rolích uživatelů a workflow v daném poolu.

Konfiguraci omezení přechodů lze provést pro každou kombinaci původní a nové hodnoty pole pomocí matice, kterou najdeme na kartě "Přechody". Řádky matice znamenají původní hodnotu dyn. pole, sloupce pak značí cílovou hodnotu. Pokud je pole zašktrnuto, daná změna pole bude povolena. V opačném případě bude přechodu zamezeno.

Obrázek 5.3. Omezení přechodů mezi hodnotami dynamického pole

Omezení přechodů mezi hodnotami dynamického pole

V příkladu na obrázku bude možné přecházet mezi jednotlivými hodnotami pole pouze "vzestupně". Jakmile tedy přepnu pole na možnost "Objednáno", návrat zpět na "Čeká na objednání" a "nezadáno" nebude možný.

Řešení konfliktů

Pokud je to možné, konfigurujte pole tak, aby ke konfliktům nemohlo dojít. Ve většině případů je to možné. Nejlépe lze předejít vznik konfliktu pomocí nastavení práv pro úpravu daného dynamického pole (viz kapitola 3.8. Karta Pole).

Pokud přesto ke konfliktu dojde, podmínky se vyhodnocují v následujícím pořadí.

  1. Workflow a pravidla TaskPoolu

  2. Omezení možností přechodů mezi stavy dynamického pole v závislosti na stavu dynamického pole

  3. Změna stavu dynamického pole v závislosti na změně workflow

  4. Změna stavu workflow v závislosti na změně hodnoty dynamického pole

Další kolize může nastat, když se změní více polí a tyto změny mají způsobit více různých změn stavu tasku. Důrazně proto doporučujeme používat pouze jedno pole pro změny stavů.

Kapitola 6. Dynamická pole uživatelů

Tato funkce nám umožní přidat dynamická pole nejen do poolů, ale i do konfigurace uživatelů. Můžeme tak každému uživateli nastavit např. jednotlivé firemní oblasti, které má na starost a podle toho filtrovat a zasílat notifikace. Pokud bude založen task týkající se pouze specifické oblasti, notifikováni mohou být pouze uživatelé spravující tuto oblast. Podobným způsobem můžeme o jednotlivých uživatelích uchovávat neomezené množství informací. Konfigurace se provádí v administraci na kartě "Dynamická pole uživatelů".

Obrázek 6.1. Administrace: Dynamická pole uživatelů

Administrace: Dynamická pole uživatelů

Pole přiřadíme k uživatelům tlačítkem Použít. Po kliknutí se tlačítko změní na Zrušit, čímž pole z uživatelských profilů odebereme.

POZOR! Při odebírání dynamického pole z uživatelských profilů může dojít ke ztrátě dat!

Zda je pole použito u uživatele můžeme vidět i v přehledu dynamických polí na kartě "Pole" v administrátorské sekci. Ve sloupci "Použito" vidíme "Uživatelé: ANO".

Obrázek 6.2. Administrace: Dynamická pole

Administrace: Dynamická pole

Pokud je pole k uživateli přiřazeno, zobrazí se ve formuláři pro editaci uživatele. Editaci svého profilu může každý uživatel vyvolat kliknutím na svoje jméno v pravém horním rohu obrazovky. Administrátor může navíc editovat profily všech uživatelů kliknutím na příslušné jméno na kartě "Uživatelé" v administrátorské sekci.

V našem příkladu jsme přiřadili k uživateli selectbox určující, o kterou firemní oblast se uživatel primárně stará. Toto pole přibude do dolní části editačního formuláře uživatele. Ten pak může pole kdykoliv editovat.

Obrázek 6.3. Editace uživatele

Editace uživatele

Každé dynamické pole může být přiřazeno k poolu, a zároveň k uživateli. Takto nakonfigurujeme naše příkladové pole "Oblast". Pole zpřístupníme zadavateli a ten pak zadá požadavek, při jehož zadávání oblast specifikuje. Díky tomu může TaskPool zasílat notifikace pouze těm uživatelům, kteří se starají o danou oblast. V tomto případě podmínku vložíme výjimečně do pole "Komu" v konfiguračním formuláři notifikace.

  • <#implementers.dynamicFields.oblast=task.dynamicFields.oblast>

V tomto případě pošle TaskPool při založení tasku notifikaci všem řešitelům, u kterých se bude shodovat hodnota dynamického pole uživatele s hodnotou dynamického pole v tasku. Jinými slovy pokud zadavatel zadá požadavek týkající se managementu, notifikace dojde pouze uživatelům, kteří mají na starosti management.

Bližší nápovědu, jak naložit s dynamickými poli uživatele najdeme pod editačním formulářem notifikace v sekci "Komu". Možnosti notifikací jsou detailně rozebrány v kapitole 15. Uživatelské notifikace.

Modul nepřítomnosti

Rozšířením dynamických polí uživatelů je tzv. Modul nepřítomnosti. Jedná se o funkčnost umožňující každému uživateli definovat, ve kterém období nebude dostupný. TaskPool pak neumožní přidělování tasků nepřítomným uživatelům.

Modul nepřítomnosti se konfiguruje v administraci v dolní části karty "Dynamická pole uživatelů".

Obrázek 6.4. Dynamická pole uživatelů: Modul nepřítomnosti

Dynamická pole uživatelů: Modul nepřítomnosti

Pro správnou funkčnost tohoto modulu je třeba mít nadefinována dvě dynamická pole typu Date nebo DateTime. Jedno je pak použito jako pole pro zadání začátku nepřítomnosti a druhé pro zadání jejího konce. V našem příkladu máme nakonfigurována dvě pole typu Date s labely "Dovolená od" a "Dovolená do" (pořadí se řídí identifikátorem příslušeného dynamického pole. Po kliknutí na tlačítko Uložit Modul nepřítomnosti se tato pole objeví v editaci uživatelského profilu.

Obrázek 6.5. Modul nepřítomnosti: Editace uživatele

Modul nepřítomnosti: Editace uživatele

Dobu nepřítomnosti si může každý uživatel definovat sám, administrátor má navíc právo definovat dobu nepřítomnosti všem uživatelům systému.

Eskalace a filtry vztahující se k nepřítomnosti uživatelů se tvoří pomocí podmínek pro dynamická pole uživatelů, nápovědu najdeme pod editačním formulářem eskalací/filtrů v sekcích "Komu" a "Dynamická pole". Více o filtrech v kapitole 7. Filtry a o eskalacích v kapitole 8. Eskalace. Zde uvedeme některá vzorová nastavení pro práci s modulem nepřítomnosti.

  • Podmínka filtru, který zobrazí všechny tasky s datem vypršení v době nepřítomnosti jejich řešitele.

    task.takenByExt.dynamicFields.dovolenaOd <= task.deadline & task.takenByExt.dynamicFields.dovolenaDo >= task.deadline

    POZN.: Identifikátory "dovolenaOd" a "dovolenaDo" je třeba změnit podle toho, jaká dynamická pole jsou pro modul nepřítomnosti použita.

  • Eskalace, která odebere řešitele všem taskům, jejichž termín dokončení se nachází v době nepřítomnosti jejich řešitele.

    Podmínka bude stejná jako u filtru, eskalaci je pouze nutné nastavit aby prováděla skript. Tento skript bude odebírat task řešiteli (task tedy bude znovu nepřevzatý) a bude vypadat takto: task.assign=0;

Kapitola 7. Filtry

Filtry umožňují definovat libovolná pravidla pro zobrazování tasků na pracovišti. Můžeme tak zobrazovat tasky napříč všemi pooly dle všech vlastností, které tasky mají (řešitel, priorita, datum vypršení, stav a mnoho dalších) včetně kombinace těchto vlastností. Můžeme tak např. zobrazit pouze tasky, které náleží aktuálně přihlášenému uživateli, dosud nepřevzaté tasky apod. Každý filtr má svůj název a seznam všech dostupných filtrů je přihlášenému uživateli zobrazen ve výběrovém poli v horní části pracoviště. Připomeňme si názvosloví:

Pool

  • Samostatný prostor pro správu určité kategorie nebo typu požadavků (tasků). Pooly vytváří administrátor a umožňuje do nich uživatelům přístup prostřednictvím udělení role v poolu. Pool je de facto také filtr. Jedná se o systémový filtr definovaný na úrovni TaskPoolu, který je automaticky generován při založení nového poolu. Podmínkou (viz další podkapitola) tohoto filtru je: "zobraz všechny tasky, které náleží do tohoto poolu". Každý task náleží pouze do jednoho poolu.

Filtr může být trojího typu:

Filtr definovaný administrátorem

  • Jedná se o filtr vytvářený a editovaný pouze administrátorem TaskPoolu. Administrátor může uživatelům umožnit přístup k těmto filtrům.

Filtr definovaný uživatelem

  • Každý uživatel si může nadefinovat svoje vlastní filtry. Možnosti definice jsou stejné jako u administrátorského filtru s tím rozdílem, že uživatel nemůže filtr zpřístupnit ostatním uživatelům.

    POZN.: Uživatelský filtr může ostatním uživatelům zpřístupnit administrátor, od té chvíle se však filtr bere jako administrátorský a jeho původní tvůrce ho již nemá možnost modifikovat.

Quickfilter

  • Toto je rychlý a snadno dostupný filtr přímo na pracovišti. Uživatelsky je velmi přívětivý a je možné ho použít bez znalosti zápisu podmínek, této funkci je věnována kapitola 10.2. Quickfilter v uživatelském manuálu.

Tvorba a editace uživatelských filtrů je přístupná na pracovišti pomocí tlačítka Jiné akce -> Filtry. Zde se zobrazí seznam "Moje filtry", tzn. filtry, ke kterým má přihlášený uživatel přístup.

Kompletní přístup k seznamu filtrů (defaultní filtry poolů, administrátorské filtry, uživatelské filtry) a k jejich editaci je umožněn v administrátorské sekci na kartě "Filtry". Nový filtr vytvoříme kliknutím na "Nový", editaci již existujícího vyvoláme kliknutím na daný filtr.

Obrázek 7.1. Administration: Filters

Administration: Filters

POZN.: Tlačítko Export do iCal slouží pro export naplánovaných tasků do kalendářových aplikací, více v kapitole 3.11.1. Import do jiných systémů.

Systémový filtr (definovaný TaskPoolem)

Systémový filtr je automaticky vygenerován systémem TaskPool při založení nového poolu a zobrazuje všechny tasky, které jsou obsaženy v tomto poolu (samozřejmě jsou respektována přístupová omezení v nastavení poolu). Ve výpisu filtrů nalezneme systémové filtry v části "Filtry aktivních poolů" a "Filtry neaktivních poolů".

Systémový filtr nelze uživatelem ani administrátorem editovat, administrátor má pouze možnost nastavit práva pro přístup jednotlivých uživatelů k tomuto filtru, a to po kliknutí na odkaz Uživatelé u příslušného filtru. Práva nastavujeme pomocí checkboxů "Přístup" a "Viditelný".

V levém horním rohu formuláře je vidět textové pole "Označ uživatele z Pool ID". Do něj lze vepsat ID poolu a po klepnutí na odkaz Označ systém zpřístupní filtr všem uživatelům, kteří mají v tomto poolu členství.

Obrázek 7.2. Administrace: Práva pro zobrazení filtrů

Administrace: Práva pro zobrazení filtrů

Definice filtru

Tlačítkem Nový vyvoláme formulář pro definici nového filtru, editovat již existující filtr můžeme kliknutím na jeho název. Nápovědu a seznam použitelných zástupných řetězců nalezneme pod formulářem pod tlačítky "Řazení | Podmínky | atd...".

Obrázek 7.3. Definice filtru v administraci

Definice filtru v administraci

Volba Řazení určuje systém zobrazování tasků daného filtru. Doporučujeme zapisovat volbu "DEFAULT", řazení tasků tak zůstane stejné, jako ve filtrech poolů. Řadit lze však i např. podle ID tasku a jeho dalších vlastností, více se dozvíme po rozkliknutí nápovědy "Řazení".

Pokud není zaškrtnuto pole Rozlišovat archivované/nearchivované tasky, do filtru budou připadat tasky jak aktivní, tak archivované či deaktivované, zruší se tedy dělení na pracoviště a archiv.

Informace zobrazená ve výpisu tasku je nastavení, co se bude u tasků na pracovišti zobrazovat ve sloupci "Komentáře". Toto nastavení nijak nezmění funkčnost daného filtru, lze tedy použít kteroukoliv variantu. Doporučujeme používat volbu "Zobrazit poslední komentář" - tato volba zobrazuje naposledy přidaný komentář a změněné hodnoty, jako je datum vypršení, dynamická pole apod. Více o tomto nastavení v kapitole 3.3. Karta Přístupová omezení.

Stěžejní jsou při definici filtru Podmínky. Ty určují, které tasky budou daným filtrem zobrazeny. K definici podmínek lze využít téměř všech vlastností tasků a pomocí logických operátorů "&" (AND - a) a "|" (OR - nebo) podmínky kombinovat. Více se dozvíme po rozkliknutí nápovědy "Podmínky". Použitelné vlastnosti tasků pro filtrování i s příklady najdeme v nápovědě "Vlastnosti tasku".

Seznam všech ID stavů, poolů, uživatelů, dynamických polí a jiných je zobrazen v nápovědě "Aktuální hodnoty".

Syntaxe pro zadávání podmínek je objekt.vlastnost. Objektem bývá nejčastěji task, popř. pool nebo i uživatel, příklad syntaxe najdeme vždy v nápovědě. Pokud se vrátíme k obrázku definice filtru, vidíme podmínku:

  • task.poolId=1 | task.poolId=2

Touto podmínkou ve filtru zobrazíme tasky, které se nachází v poolu s id=1 a zároveň tasky z poolu id=2. Pokud chceme např. zobrazit pouze tasky z těchto poolů, které jsou již dokončené, rozšíříme podmínku o stateId:

  • (task.poolId=1 | task.poolId=2) & task.stateId=20

POZN.: Při použití logického operátoru "|" (OR-nebo) je nutné výraz závorkovat z důvodu menší priority než výraz "&" (AND-a).

Další příklady filtrů:

  • pool.category LIKE 'helpdesk' - pokud používáme kategorie poolu (nastavuje se v administraci poolu na kartě "Obecné", kapitole 3.1. Karta Obecné), tento filtr zobrazí všechny tasky z poolů s kategorií "helpdesk".

  • task.takenBy=curruser.id - touto podmínkou pohodlně vytvoříme univerzální filtr, jež zobrazí všechny tasky, převzaté aktuálně přihlášeným uživatelem.

  • task.isStarred = 1 - tato podmínka slouží pro zobrazení oblíbených požadavků (označených hvězdičkou). Tento seznam je uživatelský (každý uživatel vidí své oblíbené), ale filtr lze vytvořit jako administrátorský a pak jej přidělovat jednotlivým (nebo všem) uživatelům.

Obdobným způsobem můžeme použít veškeré ostatní podmínky uvedené v nápovědě a pomocí logických operátorů je kombinovat. Syntaxe každé podmínky zvlášt je popsána v nápovědě "Vlastnosti tasku" pod definicí filtru.

Kopírování filtru

Každý filtr lze kopírovat a jeho kopie editovat a ukládat pod jiným názvem. Po kliknutí na tlačítko Kopírovat filtr na formuláři pro editaci filtru se vymaže název filtru. Po zadání nového názvu a uložení se v seznamu objeví nový filtr a původní kopírovaný zůstane zachován. Před uložením je možné nový filtr libovolně modifikovat.

Smazaní filtru

Filtr smažeme kliknutím na odkaz Smazat u příslušného filtru. Filtry vytvořené TaskPoolem (implicitní filtry poolů) smazat nejdou, můžeme ho pouze odebrat všem uživatelům, takže se na pracovišti ve výběru filtrů zcela přestane zobrazovat.

Kapitola 8. Eskalace

Eskalace je funkce, která rozšiřuje kontrolní mechanismy systému. Seznam eskalací je k dispozici v Administraci v záložce Eskalace. Kromě názvu a definice je v seznamu zobrazen dopad na výkon serveru (v sekundách).

Obrázek 8.1. Seznam eskalací

Seznam eskalací

Pokud je podmínka splněna, eskalace umožňují provádět dva druhy činností:

  1. Zasílání e-mailů

    Pomocí e-mailů můžeme uživatele automaticky upozorňovat na tasky splňující nadefinovanou eskalační podmínku. Kontrola splnění dané podmínky se u všech tasků provádí každou minutu. Hlavní rozdíl oproti notifikacím je tedy v tom, že se podmínky kontrolují bez nutnosti změny stavu tasku. Můžeme tak např. nastavit e-mailové upozornění, že se blíží termín vypršení tasku a s taskem se nic neděje. Notifikace kontroluje splnění podmínky vždy při libovolné změně tasku, podobné upozornění by tedy pomocí notifikace nebylo možné. Každá eskalace se po splnění její podmínky zasílá pouze jednou, nehrozí tak duplikování zaslaných e-mailů (pokud není vybrána volba Opakovat).

  2. Provádění skriptů

    Pomocí skriptů je možné automaticky provádět změny v tascích. Např. pokud se zákazník nevyjádří k dodanému řešení tasku do jednoho týdne, pomocí eskalace se task po týdnu automaticky schválí apod.

Popis obou funkcí je blíže popsán v následujících podkapitolách.

Obecné vlastnosti eskalace

V poli Podmínka definujeme, za jakých okolností má být eskalace zaslána. Definice podmínek zde funguje stejně jako u filtrů, v případě nejasností tedy čtěte kapitolu 7. Filtry. Nápovědu opět vyvoláme rozkliknutím jednotlivých odkazů pod formulářem.

Obrázek 8.2. Definice eskalace

Definice eskalace

Pod definici podmínky je tlačítko Test, které slouží k otestování definice a jejího dopadu na výkonnost serveru v podobě délky trvání v ms.

Eskalovat pouze v pracovní dny spouští eskalace pouze v pracovní dny.

Volba Opakovat umožňuje kontrolovat a provádět tu samou akci na steném tasku opakovaně. Pokud není zaškrtnuto, je akce na každém tasku provedena pouze jednou (pokud nedojde k stisku tlačítka Uložit & Reset ).

Prováděná akce nastavuje, zda bude eskalace sloužit k zasílání e-mailů nebo provádění skriptů. Oběma možnostem se věnují následující kapitoly.

Syntaxe pro zadávání podmínek je také stejná jako u filtrů: objekt.vlastnost. Vlastnosti tasků použitelné pro účely eskalace jsou shodné s vlastnostmi tasků pro účely filtrů.

Tabulka 8.1. Příklady eskalační podmínky

PodmínkaVýznam
task.poolId=1 & task.toDeadline<=1Zahrne tasky z poolu s id=1, u kterých je počet dní zbývajících do vypršení menší nebo roven 1.
task.stateId=0 & task.priority=1Zahrne tasky, které jsou ve stavu "Zadán k řešení" a mají prioritu 1.

POZN.: Pokud dojde ke splnění podmínky, eskalace je spuštěna a danému tasku je změněn příznak dané eskalace. To zabrání duplicitnímu spuštění eskalace na daném tasku, splnění podmínek se totiž kontroluje každou minutu. Tento příznak můžeme zrušit stisknutím tlačítka Uložit & Reset. Tím se daná eskalace uloží a zároveň smaže příznak u všech tasků, kde již byla daná eskalace spuštěna. V ten moment se znovu odešlou e-maily resp. provedou skripty u všech tasků splňujících danou podmínku.

Eskalační e-mail

Pokud se rozhodneme, že eskalace bude sloužit k zasílání e-mailů, je potřeba zasílaný e-mail nakonfigurovat.

Pole "Komu"

Do pole "Komu" je možné zadat ID uživatele (najdeme v nápovědě "Aktuální hodnoty", e-mailovou adresu nebo některý zástupný řetězec. Pokud použijeme zástupné řetězce, e-mail bude zaslán všem uživatelům dané role.

Tabulka 8.2. Zástupné řetězce pro adresáty

Zástupný žetězecVýznam
<#implementers>Všichni řešitelé
<#serviceManagers>Všichni servisní manažeři v daném poolu
<#observersOfImplementers>Nahlížitelé na straně řešitele
<#submitters>Všichni zadavatelé
<#managersOfSubmitters>Všichni manažeři zadavatelů
<#observersOfSubmitters>Nahlížitelé na straně zadavatele
<#submitter>Zadavatel konkrétního tasku
<#coSubmitters>Spoluzadavatelé konkrétního tasku
<#implementer>Řešitel konkrétního tasku
<#coImplementers>Spoluřešitelé konkrétního tasku

Do pole s adresáty lze zadat i více hodnot oddělených středníkem nebo čárkou, tedy např.:

2; 3; matej.kotrba@taskpool.cz; <#serviceManagers>; <#implementer>

Pole "Předmět" a "Text"

Do pole "Předmět" a "Text" zadáváme předmět a tělo zasílaného e-mailu. Pro automatické doplňování hodnot lze taktéž využít zástupných řetězců, nabízených v sekci nápovědy "Vlastnosti tasku", k dispozici máme také vzorový kód.

Zástupné řetězce pro použití v textu mají oproti použití v podmínkách mírně odlišnou syntaxi: <#objekt.vlastnost>. Kromě této drobné změny funguje zápis stejně jako u podmínek filtrů a eskalací.

Zasílat e-mail jako

Zasílaný e-mail může mít formu prostého textu nebo HTML.

Jazyk

Jazyk zasílaného e-mailu. Podle této hodnoty se doplňují např. názvy dynamických polí apod.

Stav

Zde lze eskalaci deaktivovat. Není tedy potřeba ji rovnou mazat, pokud není dočasně potřeba.

Druh komentáře

Po splnění eskalační podmínky se do historie dotyčného tasku zapisuje systémový komentář o spuštění eskalace. V tomto komentáři je i celkový seznam příjemců eskalační zprávy. Zde lze nastavit formu komentářů:

  • veřejné - standardní komentář viditelný všem, kteří mají právo vidět task

  • neveřejné zadavatelské - skrytý řešitelské straně

  • neveřejné řešitelské - skrytý zadavatelské straně

  • bez komentáře - o spuštění eskalace nebude veden zápis do historie

Eskalační skript

Pomocí skriptů můžeme s taskem na základě splněné podmínky automaticky provádět různé akce. Tuto funkci můžeme využít mimo jiné k automatizaci workflow, které se ve firmě opakuje, např.:

  • pokud zákazník nezareaguje na task do 14 dnů, task deaktivuj

  • pokud vypršela deadline, změň hodnotu daného dynamického pole

  • pokud je task více jak den nepřevzatý, automaticky ho přiděl danému řešiteli

...a spousta dalších. Podmínky spuštění skriptu se opět definují stejně jako u filtrů (kapitola 7. Filtry).

Počet akcí, které skript provádí, může být libovolný. Jednotlivé příkazy se oddělují středníkem. Syntaxe je následující.

  • task.property = hodnota

  • task.dynamicFields.identifikatorPole = hodnota

Jako "property" můžeme použít hodnoty stateId, deadline, assign a waitForAssign. Pomocí eskalace tedy můžeme měnit stav tasku, jeho deadline, přidělovat task řešitelům (popř. navrhovat k přidělení), či ho řešitelům odebírat. Dále můžeme měnit hodnoty dynamických polí.

Na pravé straně přířazení mohou být tyto hodnoty:

  • číslo

    task.stateId = 20 - nastaví hodnotu stateId na 20, tedy dokončí task

  • řetězec

    task.dynamicFields.popisProblemu = 'toto je textový řetězec, který skript zapíše do dynamického pole s identifikátorem popisProblemu'

  • now - proměnná obsahující aktuální datum a čas, je možné použít i čas s případným přičtením/odečtením daného časového úseku, jednotky jsou d (dny), h (hodiny), m (minuty), např. now-10m (aktuální čas mínus deset minut)

  • today - proměnná obsahující aktuální datum, opět možné použít např. today-3d

  • null

  • a libovolná proměnná z následujícího výčtu:

'id' | 'name' | 'sequenceid' | 'poolid' | 'stateid' | 'createddate' | 'createdby' | 'takenby' | 'takendate' | 'approvedtime' | 'confirmedtime' | 'finishedtime' | 'handover' | 'tohandover' | 'lastcommentdate' | 'hdnote' | 'hdusername' | 'hdcompany' | 'hduserid' | 'sidetask' | 'price' | 'price2' | 'newprice' | 'priority' | 'deadline' | 'newdeadline' | 'currency' | 'newcurrency' | 'todeadline' | 'slaschemaid' | 'slapriorityid' | 'slapriorityseqid' | 'fixtime' | 'reactiontime' | 'relativefixtime' | 'relativereactiontime' | 'relativeworkingfixTime' | 'relativeworkingupdatetime' | 'relativeworkingreactiontime'

POZN.: Hodnoty, které přiřazujeme do dynamických polí musí respektovat formát pole, např. do pole typu number nelze přiřadit textový řetězec apod. Časové položky tasku musí být ve formátu "YYYY-MM-DD", tedy např. "2018-03-23". Tyto hodnoty lze aplikovat pouze pro pole typu textfield, date a datetime. Pokud chceme měnit hodnotu dynamického pole typu checkbox, jako hodnoty slouží 'on' a 'off'.

Příklad 1)

  • task.stateId = 20; task.dynamicFields.zpusobReseni = 3 - při splnění podmínky skript dokončí daný task a změní dynamické pole (Selectbox, Radiobutton nebo Multiselectbox) s identifikátorem "zpusobReseni" na hodnotu s id=3.

Příklad 2)

  • task.dynamicFields.casDokonceni = 'finishedTime' - naplní dynamické pole s idetifikátorem "casDokonceni" hodnotou skutečného dokončení tasku.

Příklad 3)

  • task.assign = 0 - odebrání tasku řešiteli.

Kapitola 9. Licence

Licence je zasílána pracovníky Comarr spol. s r.o. při zakoupení produktu TaskPool.

Kliknutím na kartu "Licence" v administrační části se zobrazí následující okno:

Obrázek 9.1. Administrace: Licence

Administrace: Licence

Parametry licence Počet uživatelů, Počet uživatelů (řešitelská strana), Počet poolů, Počet poolů s Helpdeskem, Počet SLA modulů a Počet mobilních HD zadavatelů se vztahují vždy pouze na aktivní uživatele a pooly. Deaktivovaní uživatelé a pooly se nezapočítávají do celkového počtu. Počet tasků je ve všech případech neomezen.

Pole Počet uživatelů (řešitelská strana) uvádí maximální počet uživatelů, kteří mohou být současně v rolích na řešitelské straně (řešitel a servisní manažer). Rozdíl mezi celkovým počtem uživatelů a počtem uživatelů na řešitelské straně může být vyplněn uživateli, kteří figurují jen na straně zadavatelů (zadavatel nebo manažer zadavatelů).

Aktuální stav využití je zobrazen v položce Aktuální počet, kde:

  • U - počet uživatelů (users)

  • DevU - počet uživatelů na řešitelské straně (developer users)

  • P - počet poolů (pools)

  • HD - počet poolů s Helpdeskem (Helpdesks)

  • SLA - počet SLA schémat (SLA)

  • J - počet tasků (jobs)

  • HD mobile - počet aktivních helpdeskových zadavatelů

Pro nejjednoduší aktivaci licence slouží pole Import licence, pomocí kterého lze přímo naimportovat obdržený licenční soubor. Pokud se z nějakého důvodu rozhodnete vložit licenci ručně, veškeré údaje musí být vyplněny přesně v souladu s objednávkou a obdrženou licencí (např. firma včetně mezer, diakritky, velkých a malých písmen - tedy case sensitive), v opačném případě bude licence nefunkční. Pole Počet uživatelů a Počet poolů nelze měnit bez změny obsahu pole Licence.

Je možné vložit logo vlastníka licence, které se bude objevovat ve všech oknech systému vlevo nahoře. Logo zobrazované na pracovišti vpravo nahoře lze změnit v nastavení každého poolu zvlášť.

Pokud zadáme do pole URL adresu, pod kterou je mapován TaskPool (např. http://taskpool.vasefirma.cz), bude se tato URL objevovat ve všech notifikacích. Dále bude jako odesílatel notifikací uveden e-mail: taskpool@taskpool.vasefirma.cz. Pokud chcete adresu odesílatele změnit, lze tak učinit v nastavení konkrétního poolu.

POZOR! Při zadání nesprávné URL nebudou v notifikacích funkční linky na konkrétní tasky a přílohy v tascích.

URL zákaznického Helpdesku je URL odkazu "Hlášení chyby" na libovolné stránce TaskPoolu v pravém dolním rohu. Tento odkaz je primárně nastaven na zákaznický Helpdesk systému TaskPool firmy Comarr spol. s r.o. Vyplněním vlastního URL je možné tento odkaz změnit.

Pole Používat vlastní username a Kód zákazníka se používá při ověřování uživatelů TaskPoolu přes LDAP. Pokud toto ověřování nechcete používat, ponechte obě pole nevyplněna. Práce s LDAP je popsána v následující kapitole.

Kapitola 10. LDAP / AD

LDAP (Lightweight Directory Access Protocol) je protokol umožňující efektivní sdílení strukturovaných informací po TCP/IP. V praxi to znamená např. seznam zaměstnanců firmy, jejich přihlašovací jména, domovské adresáře, osobní informace, e-mailové adresy nebo čísla telefonů. Strukturu informací si lze v LDAP představit jako strom, jehož koncové větve obsahují konkrétní údaje.

Jednou z funkcí LDAPu je možnost ověření uživatele při přihlašování do TaskPoolu. Výhodou tohoto způsobu ověření je především stejné uživatelské jméno a heslo pro všechny aplikace využívané danou firmou. Další výhodou je možnost celý proces ověření automatizovat a tím vytvořit vstup do systému uživatelsky mnohem příjemnější. Ověření pak může probíhat spuštěním souboru, který automaticky otevře prohlížeč a přihlásí konkrétního uživatele. Toto automatické přihlašování je možné použít jak do TaskPoolu, tak do Helpdesku. Tomuto způsobu přihlašování je věnována kapitola 10.3 Autentikátor.

Předpoklady použití LDAP ověření

Záznamy uživatelů musí být v LDAP vyhledatelné podle atributu obsahující ID, kterým se uživatel přihlašuje ke své pracovní stanici.

Příklad:

  • uživatel se přihlašuje pod ID: novakj

  • v LDAPu musí být možné dohledat odpovídající záznam např. pomocí: (uid=novakj)

  • nalezený záznam musí dále obsahovat ostatní pole, která se mapuji do TaskPoolu:

    • povinně: příjmení, e-mail

    • volitelně: telefon, firma

Dále je nutné splnit tyto systémové požadavky:

  • LDAP server a možný přístup serveru s instalací TaskPoolu k tomuto

  • TaskPool verze 2.1 a vyšší

Konfigurace

Pro zprovoznění LDAP ověření je nutné postupně vykonat tyto kroky:

  1. V administrátorské sekci TaskPoolu na kartě "Licence" je třeba zaškrtnout volbu "Používat vlastní username" a do textového pole "Kód zákazníka" vložit zvolený kód, např. comarr. Přihlášení do TaskPoolu bude nadále možné pouze po uvedení tohoto kódu v přihlašovacím dialogu.

    POZOR! Pokud je zašktnuta volba "Používat vlastní username" a nastavení uložíme, volbu již není možné měnit!

    Pokud se na přihlašovací obrazovce nezobrazuje pole "Kód zákazníka", pak je nutné v souboru Taskpool.properties (ten se nachází v domovském adresáři TaskPoolu v podadresáři WEB-INF) upravit řádek customer.default.code na customer.default.code=VášZvolenýKód.

    Hodnota customer.default.code v souboru Taskpool.properties se musí shodovat se zvoleným kódem zákazníka (pokud je řádek např. customer.default.code=nazevfirmy, pak kód zákazníka je nazevfirmy).

  2. Na kartě "Nastavení zákazníka" v administrační části je nutné zadat hodnoty požadovaných parametrů. Po vyplnění údajů můžete provést test tlačítkem "Otestovat připojení". Musí být vyplněna všechna pole, jinak nebude fungovat LDAP Synchronizace.

    POZN.: Atribut "Vyhledat vzor" musí být u většiny konfigurací v závorkách.

  3. Kliknutím na tlačítko "LDAP Synchronizace" se provede synchronizace, kde můžeme zvolit další způsoby mapování.

  4. U uživatelů, pro které chceme použít LDAP ověření, zaškrtneme volbu "Synchronizovat s LDAPem" ve formuláři úpravy uživatele. Pokud je toto nastavení uloženo, nebude dále možné upravovat jeho osobní údaje (dokud se pole opět neodškrtne).

Obrázek 10.1. Administrace: Nastavení zákazníka

Administrace: Nastavení zákazníka

Autentikátor

Autentikátor slouží pro automatické přihlášení na Pracoviště nebo do helpdeskového rozhraní přes LDAP ověření. Autentikátor ověří uživatele přihlášeného na počítači a otevře okno prohlížeče na přihlášení. TaskPool ověří uživatele proti LDAP serveru a automaticky přihlásí uživatele.

Autentikátor lze nalézt v distribuci TaskPoolu v adresáři "\WEB-INF\tools". Zde jsou adresáře "TaskPoolLogin" (pro řešitele) a "HelpdeskLogin" (pro zákazníky / zadavatele).

Spustitelné soubory "TaskPoolLogin.bat" a "HelpdeskLogin.bat" mohou být uloženy na souborový sever a vzdáleně spuštěny. Není nutné je instalovat na každou stanici.

Ke spouštění na stanici je třeba mít nainstalovaný Virtual Java Runtime. Další podmínka je správné nastavení LDAP v TaskPoolu.

TaskPool autentikátor (pro řešitele)

Adresář "TaskPoolLogin" obsahuje 3 soubory:

  • TaskpoolLogin.bat - spustitelný soubor autentikátoru

  • TaskpoolLogin.jar - vlastní autentifikátor (Java library)

  • TaskpoolLogin.cfg - konfigurační soubor

Konfigurační soubor je nezbytený pro správnou funkci. Tyto 3 body je třeba správně nastavit:

  • authURL = [URL TaskPool]/LDAPLogin

    např.: pokud je URL https://www.taskpool.net , tak hodnota bude https://www.taskpool.net/LDAPLogin

  • loginURL = [URL TaskPool]/login.do?ldap

    např.: pokud je URL https://www.taskpool.net , tak hodnota bude https://www.taskpool.net/login.do?ldap

  • customerID = [code of customer] - zde se vyplní Kód zákazníka (stený, jako při přihlášení na Pracoviště). Pokud není třeba pro přihlášení zákazníka vyplňovat, použijte výraz ze souboru "WEB-INF\Taskpool.properties" na řádce "customer.default.code=".

Se správnou konfiguraci lze spustit soubor "TaskpoolLogin.bat" a dojde k automatickému přihlášení řešitele na Pracoviště.

Helpdesk autentikátor (pro zákazníky)

Je nutné nastavit konfigurační soubor:

  • authURL = [URL Helpdesk] - lze najít v nastavení helpdesku na záložce "LDAP/DB", stejně jako LDAP Login URL: https://[URL]/servlet/HelpdeskLoginLDAP?eid=[id]&authId=?????

    Parametr "authId=?????" je velmi důležitý. Pokud chcete používat automatické přihlášení, je nutné místo otazníků vyplnit ID LDAP autentifikaci. ID autentifikaci lze najít napravo od jména autentifikace v závorkách. Pokud máte pouze jednu autentifikaci, není možné ID vyplnit.

  • loginURL = vložte URL helpdesku

Se správnou konfiguraci lze spustit soubor "HelpdeskLogin.bat" a dojde k automatickému přihlášení zákazníka na heldpesk.

Kapitola 11. Soubory

V administrační části je možné uložit na server soubory, které budou TaskPoolem dále využívány. Tyto soubory pak můžeme použít např. v konfiguraci Helpdesku (17. Helpdesk) nebo tiskových šablon (12. Šablony).

Obrázek 11.1. Administrace: Soubory

Administrace: Soubory

Po nahrání souboru na server se v seznamu zobrazí odkaz na soubor a jeho URL. Toto URL můžeme použít i jako externí URL pro stažení daného souboru zákazníkem apod.

POZN.: Pokud je daný soubor využíván přímo na serveru (např. v helpdeskových šablonách), cestu k němu je možné zadat jako relativní, což je z programátorského hlediska elegantnější řešení, v našem případě jako:

..//getUserFile?customerId=1&ilename=HDhlavicka_cs.html

Pokud nahráváme soubor, který je zde již nahraný a nese stejný název, pouze proběhla např. aktualizace souboru, stačí při nahrávání zaškrtnout checkbox Přepsat stávající. Vyhneme se tak klasickému postupu "Smazat -> Nahrát". Soubor je také možné upravit přímo na serveru pomocí tlačítka Upravit.

Kapitola 12. Šablony

Systém TakPool umožňuje exportovat tasky z aktuálního filtru na pracovišti do určité formy datového souboru. Data pak mohou být dále zpracována v jiné aplikaci. Standardní formy exportu z jsou CSV, HTML, XML a RTF.

Konfiguraci šablon nalezneme v administraci na kartě "Šablony". V horní části jsou vypsány systémové šablony, jejichž obsah je pro uživatele neměnný. Po upgradu systému TaskPool se může jejich obsah mírně měnit. Pokud chcete zachovat stejnou podobu dané šablony, je možné vytvořit kopii a používat šablonu jako uživatelskou.

K dispozici je několik defaultních šablon, standardně aktivní pro všechny pooly.

POZOR! Jako vstupní data pro výpis šablony se berou všechny tasky z aktuálně zobrazeného filtru.

  • Vyúčtování - VIZ VYÚČTOVÁNÍ

  • Export_counters - exportuje všechny hodnoty polí typu counter.

  • Export_CSV - exportuje aktuálně zobrazený filtr do formátu CSV. Výstupní soubor této šablony obsahuje veškeré dostupné informace o všech zobrazených tascích.

  • Export_timesheets - exportuje záznamy času (více v kapitole 21. Evidence nákladů).

  • Export_user_timesheets - exportuje záznamy času daného uživatele, tuto funkci může každý uživatel aktivovat ze svého profilu.

  • Dále jsou k dispozici šablony, jejichž výstupem jsou statistické grafy. Jejich názvy i použití jsou velice intuitivní, nebudou zde tedy dále rozebírány.

Definice vlastních šablon

Po kliknutí na tlačítko Nový se zobrazí okno pro definici šablony.

Obrázek 12.1. Vytvoření nové šablony

Vytvoření nové šablony

Název

Dostupné šablony jsou uživateli zobrazeny po najetí kurzorem na tlačítko "Tisk" na pracovišti. Název šablony se bude v seznamu zobrazovat jako jednotlivá možnost exportu.

Nahrát

Touto cestou je možné nahrát soubor se zdrojovým kódem šablony. Pokud budeme tento kód psát ručně, toto pole není nutné vyplňovat.

Zobrazit v

Nastavení, zda se bude šablona zobrazovat ve výpisu, v detailu tasku nebo v detailu uživatele. Také je možné šablonu použít pro vyúčtování, to je popsáno v uživatelském manuálu v kapitole 9.2. Vyúčtování.

Nastavení

Zde nastavujeme, která data se budou při exportu generovat. Např. bez zaškrtnutí pole "generovat historie" nebude možné použít žádný údaj z historie tasku. Pokud však tyto hodnoty nejsou v šabloně použity, zákaz jejich generování urychlí export dat pomocí šablony.

Formát

Výsledný soubor, který vznikne exportem, lze si vybrat mezi HTML, XML, CSV a RTF.

Encoding

Zde nastavíme kódování výstupu, na výběr je UTF-8 a WINDOWS-1250.

Stav

Zde je možné šablonu dočasně deaktivovat.

Přístupová omezení

Nastavení přístupových omezení se dělá pro každou šablonu zvlášť. Definuje se, pro jaké pooly a kterým rolím bude šablona přístupná (servisní manažer, řešitel, manažer zadavatelů, zadavatel).

Formát zdrojového kódu - XSLT

Definice šablon pro systém TaskPool se provádí pomocí XSLT transformací. XSLT se používá pro transformaci XML dokumentů buď na jiné XML (např. pro jiné DTD), do HTML, nebo do jiných typů souborů.

Zobrazení seznamu tasků lze přepnout do formátu XML. Toto zobrazení získáme, pokud v URL adrese výpisu tasků (která má např. tento tvar: http://www.taskpool.net/list?source=tp.sbs&method=lf&xsl=lf.xsl&format=html) smažeme poslední dva parametry, tedy vše od parametru xsl (URL pak bude vypadat zhruba takto: http://www.taskpool.net/list?source=tp.sbs&method=lf). Toto zobrazení obsahuje XML výpis všech tasků v aktuálním filtru, včetně jejich charakteristik a nastavených parametrů a poskytuje tak velmi rozsáhlé možnosti exportů, které jsou omezené pouze vaší fantazií a potřebami firmy.

Při tvorbě výstupů lze využít např. i vlastní css reporty nebo obrázky, a to pomocí uživatelských souborů popsaných v předchozí kapitole.

Použití reportů

Nadefinované reporty se ukládají do adresáře /logos/customer_[id]/templates/ v kořenovém adresáři TaskPoolu. Do adresáře "logos" se ukládají také veškeré přílohy k taskům, celý adresář "logos" je tedy vhodné zálohovat. Problematika zálohování je popsána v příručce správce v kapitole 4. Zálohování.

Pro použití reportu přímo v systému TaskPool stačí najet myší na tlačítko "Tisk" na pracovišti a zobrazí se nabídka dostupných reportů pro aktuálně zobrazený filtr přihlášeného uživatele.

Obrázek 12.2. Použití reportů

Použití reportů

Kapitola 13. E-mail reporty

E-mail report je funkce využívající reporty popsané v předcházející kapitole. Umožňuje automaticky vygenerovat výstup a posílat ho na zvolené e-mailové adresy za zvolený časový úsek.

POZN.: Do e-mailového reportu jsou zahrnuty pouze ty tasky, ve kterých došlo od minulého odeslání reportu ke změně.

Nový report vytvoříme v administraci na kartě "E-mail reporty" tlačítkem "Nový". Formulář pro konfiguraci vypadá následovně:

Obrázek 13.1. Vytvoření e-mailového reportu

Vytvoření e-mailového reportu

Nápověda ke každé části konfigurace je opět obsažena jednotlivými odkazy pod formulářem.

V poli Podmínka volíme, které tasky budou zahrnuty jako vstupní data pro exportní šablonu. Zápis podmínek se provádí stejným způsobem jako u filtrů (7. Filtry). Můžeme tedy report omezit např. pouze na jeden pool apod.

Do pole Komu je možné vypisovat narozdíl od eskalací pouze jednotlivé e-mailové adresy, oddělené čárkou nebo středníkem. Pole Předmět je předmět zasílaného e-mailu. V sekci Šablona zvolíme, podle které šablony bude proveden export.

Termín se nastavuje podobně jako u autotasků (více v uživatelském manuálu v kapitole 12. Autotask). Po kliknutí na tlačítko Přepočítat TaskPool spočítá poslední a následující spuštění daného e-mailového reportu. Kliknutím na Uložit & Reset uložíme daný report a vyresetujeme datum posledního spuštění. Po této akci dojde ihned k opětovnému odeslání reportu a následující odeslání již probíhá dle nastaveného časování.

Kapitola 14. POP3 přiřazení

Nastavením POP3 přiřazení lze umožnit založení tasku uživatelem bez přihlášení do TaskPoolu. Uživatel pouze odešle e-mail na určitou adresu a TaskPool z něj vytvoří task. Předmět zprávy se stane předmětem tasku, tělo zprávy jeho popisem.

Na kartě "POP3 přiřazení" mapujeme e-mailové adresy na konkrétní uživatele TaskPoolu. E-mail došlý z dané adresy se založí tak, jako kdyby ho dotyčný uživatel zadal přes klasické rozhraní a bude v něm tedy uveden jako zadavatel.

Obrázek 14.1. Administrace: POP3 přiřazení

Administrace: POP3 přiřazení

Pokud aktivujeme tlačítko Automaticky přiřadit aktivní uživatele TaskPoolu, systém ke všem aktivním uživatelům přiřadí jejich standardní e-mailové adresy uvedené v uživatelském profilu každého z nich. Adresa musí být unikátní, ke stejnému uživateli nelze zadat více adres a taktéž nelze použít stejnou adresu pro více uživatelů.

Dále je nutné mít aktivní e-mail interface pro pool, do kterého chceme došlé tasky vkládat. Toto nastavení se provádí pro každý pool zvlášť na kartě "E-mail Interface" v nastavení poolu. V kapitole 3.9. Karta E-mail Interface je uvedeno více podrobností o možnostech e-mailové komunikace. Tam se také nastavuje konkrétní schránka, kterou bude TaskPool pro vytváření tasků vybírat.

Tato funkce je totožná s funkcionalitou z modulu Helpdesk, kde e-mailové rozhraní funguje pro helpdeskové uživatele (viz kapitola 17.16. E-mail Interface na Helpdesku). Při shodnosti e-mailových adres tak může dojít ke konfliktu při vybírání schránky. TaskPool řeší případné konflikty v adresách následujícím způsobem:

  • Nejdříve v e-mailové schránce najde a vybere všechny e-maily od mapovaných uživatelů TaskPoolu a přiřadí je k taskům.

  • Potom najde a vybere zprávy od ověřovaných uživatelů Helpdesku (LDAP nebo DB ověření) a přiřadí je k taskům.

  • Pokud je v nastavení Helpdesku povoleno anonymní zakládání tasku, pak se zbylé e-maily ve schránce vloží jako požadavky uživatele Helpdesku bez registrace (kapitola 17.12. Karta Přihlášení.

    POZOR! Pokud není povoleno zadávání helpdeskových tasků bez registrace, zbylé došlé zprávy jsou odstraněny!

Kapitola 15. Uživatelské notifikace

Kromě defaultních notifikací z poolu můžeme nadefinovat také notifikace uživatelské. Jejich výhodou je možná konfigurace způsobu jejich zasílání, stejně jako jejich obsahu a adresátů. Možnou nevýhodu představuje nutnost ruční konfigurace. Uživatelské notifikace mohou fungovat buď samostatně, nebo jako doplnění defaultních notifikací. Pomocí podmínek lze zajistit např. dohled pouze nad vybranými tasky a ulehčit si třídění v osobní poště.

Uživatelské notifikace spojují výhody filtrů a notifikací. Je nastavena určitá podmínka pro zaslání notifikace a při změně libovolného tasku se tato podmínka vyhodnocuje. Podmínku může představovat např. změna stavu, vypršení deadline nebo určitá hodnota dynamického pole. Pokud dojde ke splnění podmínky, nastaveným adresátům se zašle předdefinovaná zpráva. Tímto mechanismem lze přesně určit, ze kterých tasků bychom chtěli notifikace dostávat a které pro nás nejsou důležité.

Princip notifikací je velmi podobný eskalacím, které jsou popsány v kapitole 8. Eskalace. Základním rozdílem je fakt, že u eskalací dochází ke kontrole splnění podmínky periodicky v časových intervalech, ale u notifikací se kontrola splnění podmínky provádí při každé úpravě tasku. Tím lze docílit zesílené kontroly vybraných tasků, popř. vyšší urgenci řešení těchto tasků jejich řešiteli.

Každému uživati TaskPoolu vyhovuje jiný systém zasílání notifikací, je proto možné zcela vypnout implicitní notifikace z poolů a nakonfigurovat zasílání e-mailů pouze na některé akce pomocí uživatelských notifikací.

Obrázek 15.1. Uživatelská notifikace

Uživatelská notifikace

Notifikace na obrázku bude informovat zadavatele tasku o jeho dokončení. Pole Podmínka funguje stejně jako u filtrů a eskalací a pole Komu funguje stejně jako u eskalací, vše je také popsáno v nápovědě pod formulářem. Pole Text obsahuje vlastní tělo notifikace. K dispozici je vzorový kód, který je shodný s kódem standardních notifikací z poolu a dynamicky se mění podle hodnot tasku. Tělo notifikace je samozřejmě možné libovolně měnit včetně použití statického textu.

Zástupné řetězce - proměnné

Zástupné řetězce můžeme použít v textu notifikace. Lze tak nastavit výpis téměř všech vlastností tasku a tím přizpůsobit vzhled zprávy.

Některé z vlastností uvedených níže nemusí pro danou akci existovat (např. pokud se k tasku pouze přidá komentář bez další akce, pak proměnná <#task.history.assignedTo> nebude naplněna). Pokud přesto takovou proměnnou použijeme, nezobrazí se na daném místě žádný text (ostatní proměnné budou normálně fungovat).

V uživatelských notifikacích je oproti filtrům a eskalacím navíc možné použít vlastnost tasku "history", pomocí níž přistupujeme do historie tasku. Vlastnosti zde zmiňované nelze použít pro definici podmínky notifikace, ale pouze pro konfiguraci textu!

Tabulka 15.1. Proměnné pro konfiguraci těla e-mailové zprávy

ŘetězecVýznam
<#task.history.action>Akce, která byla s taskem provedena (např. "Task upraven")
<#task.history.created>Čas změny tasku
<#task.history.createdBy>Uživatel, který změnu provedl
<#task.history.assignedTo>Jméno uživatele, kterému byl task přidělen (nemusí existovat)
<#task.history.comment>Komentář k provedené akci (nemusí existovat)
<#task.history.deadline>Deadline tasku
<#task.history.price>Cena
<#task.history.currency>Měna
<#task.history.priority>Priorita
<#task.history.stateId>Stav tasku po úpravě
<#task.history.publicId>Typ komentáře (0 - veřejný, 1 - zadavatelský, 2 - řešitelský)
<#task.history.dynamicFieldsObj>Seznam změněných datumových dynamických polí. Každý z objektů v seznamu má vlastnost name (vrací název pole) a value (vrací hodnotu pole).
<#task.history.attachments>Seznam příloh (nemusí existovat). Každý z objektů má vlastnosti uploadDesc (název přílohy) a uploadId (id přílohy do odkazu).
<#recipient.firstname>, <#recipient.lastname>Jméno a příjmení příjemce zprávy
<#task.priorityLabel>Pojmenování priority tasku, jak je označena v nastavení

S dynamickými poli se pracuje obdobně. Můžeme navíc použít parametry value a name. Jejich použití shrnuje následující tabulka. Způsob použití najdete v následujících podkapitolách.

Tabulka 15.2. Proměnné pro použití dynamických polí

ŘetězecVýznam
<#task.history.dynamicFieldsObj.id.name>Jméno dynamického pole
<#task.history.dynamicFieldsObj.id.value>Hodnota dynamického pole

POZN.: Hodnoty "id" představují identifikátory daného dynamického pole a je nutné je změnit podle konkrétní konfigurace.

Použití funkcí

Pro definici vzhledu těla notifikace lze použít několik funkcí, které mohou zpřehlednit výpis nebo zvýraznit nejdůležitější informace. Funkce také umožňují práci s proměnnými, které vracejí seznam (např. seznam dynamických polí nebo příloh). Funkce, které můžeme využít jsou:

  • If - test na splnění určité podmínky

  • NotEmpty - test na naplnění proměnné daty

  • Iterate - opakování určité činnosti

Funkce jsou podrobně pospsány dále. Syntaxe použití funkcí je následující:

<block:JmenoFunkce[podminka]>
    Kod, ktery ma byt proveden
<#endBlock>

V ukázce je nutné při použití funkcí použít element #block a uzavřít tak kód, který má být proveden.

Elementy #block je možné seskupovat. Můžeme tedy použít funkci uvnitř jiného elementu #block, ale musíme tyto elementy očíslovat. Syntaxe je potom následující:

<block1:JmenoFunkce[podminka]>
    Kod, provedeny funkci 1 pred funkci 2
    <block2:JmenoDruheFunkce[podminka]>
        Kod provedeny funkci 2
    <#endBlock-2>
    Kod, provedeny funkci 1 po ukonceni funkce 2
<#endBlock-1>

Takto lze vnořit libovolný počet funkcí.

Funkce If

Tato funkce je běžně užívána pro testování splnění určité podmínky. Pokud je podmínka splněna, pak je proveden kód, který funkce ohraničuje. Jako podmínku lze použít kteroukoliv podmínku v běžném formátu TaskPoolu, kterou známe z filtrů a eskalací. Nápověda k vlastnostem tasku je uvedena pod konfiguračním formulářem.

Použití funkce If na příkladu skrytého komentáře:

<#block:If[task.history.publicId=1 | task.history.publicId=2]>
- skrytý komentář
<#endBlock>

Funkce NotEmpty

Tato funkce ošetřuje případ, kdy některé proměnné nejsou naplněny daty. Její použití není povinné. Pokud v tomto případě bude použita proměnná, která je aktuálně prázdná, nevypíše TaskPool žádný text. Jednalo by se tedy spíše o kosmetickou vadu. Tuto funkci lze také použít pro vylepšení orientace v e-mailu. Pokud nás u daného tasku zajímá hlavně každá změna ceny, můžeme její případnou změnu v tělě e-mailu zdůraznit.

Jako podmínka se této funkci předává název proměnné, kterou chceme testovat. Syntaxe je tato:

<block:JmenoFunkce[proměnná]>
    Kod, ktery ma byt proveden, v pripade, ze promenna
    je naplnena daty.
<#endBlock>

Příklad se změnou ceny bude vypadat např. takto:

<block:NotEmpty[task.history.price]>
    <h2>Byla provedena zmena ceny,
    nova cena je <#task.history.price>.</h2>
<#endBlock>

V případě změny ceny bude toto oznámeno ve zprávě velkými písmeny.

Funkce Iterate

Tato funkce slouží pro procházení seznamu proměnných. Do podmínky se zapisuje název proměnné, která vrací seznam.

Použití funkce Iterate na příkladu procházení seznamem dynamických polí:

<table>
<#block:Iterate[task.history.dynamicFieldsObj]>
<tr><td><#task.history.dynamicFieldsObj.name></td><td>
<#task.history.dynamicFieldsObj.value></td></tr>
<#endBlock>
</table>

V tomto případě budou do tabulky vypsány názvy a hodnoty všech změněných dynamických polí.

Další případ ilustruje výpis všech přidaných příloh:

<#block-1:NotEmpty[task.history.attachments]>
     <tr><td colspan="2">Přílohy</td></tr>
     <#block-2:Iterate[task.history.attachments]>
                 <tr><td>&nbsp;</td><td>
<a href=
    "http://www.taskpool.net/file.do?id=<#task.history.attachments.uploadId>">
                 <#task.history.attachments.uploadDesc></a></td></tr>
     <#endBlock-2>
<#endBlock-1>

Tento kód vypíše všechny názvy příloh, které budou zároveň aktivními odkazy na přílohy do TaskPoolu. Kód funkce Iterate je zde uvnitř funkce NotEmpty. Kdyby byla funkce použita samostatně (bez bloku NotEmpty), výsledkem by byla tabulka, v níž by byly prázdné odkazy na nefungující stránky.

Příklad notifikace

Zde je uveden příklad nakonfigurované notifikace. Bude vypadat zhruba tak, jak ji známe z TaskPoolu. Jsou v ní použity všechny funkce.

<html>
<body>
<table>
<tr><td colspan="2"><h5><#task.history.action> (<#task.id>)
    <#block:If[task.history.publicId=1 | task.history.publicId=2]>
    - skrytý komentář
    <#endBlock></h5></td></tr>
<tr><td colspan="2">&nbsp;</td></tr>
<tr><td>Zpráva pro</td><td><#recipient.firstname> <#recipient.lastname>
          </td></tr>
<tr><td>Kým</td><td><#task.history.createdBy.firstname> 
<#task.history.createdBy.lastname></td></tr>
<tr><td>Datum</td><td><#task.history.created></td></tr>
<tr><td colspan="2">&nbsp;</td></tr>
<tr><td>Pool</td><td><#pool.name></td></tr>
<tr><td>Předmět</td><td>
<a href=
    "http://www.taskpool.net/showJob.do?id=<#task.id>"><#task.name></a>
</td></tr>
<tr><td>Popis</td><td><#task.desc></td></tr>
<tr><td colspan="2">&nbsp;</td></tr>
<tr><td>Priority</td><td><#task.priority></td></tr>
<#block:NotEmpty[task.history.comment]>
<tr><td>Komentář</td><td><#task.history.comment></td></tr>
<#endBlock>
<#block:NotEmpty[task.history.price]>
<tr><td>Cena</td><td><#task.history.price>&nbsp;
<#task.history.currency></td></tr>
<#endBlock>
<#block:NotEmpty[task.history.price]>
<tr><td>Deadline tasku</td><td><#task.history.deadline></td></tr>
<#endBlock>
<#block:Iterate[task.history.dynamicFields]>
<tr><td><#task.history.dynamicFields.name></td><td>
<#task.history.dynamicFields.value></td></tr>
<#endBlock>
<#block:Iterate[task.history.dynamicFieldsObj]>
<tr><td><#task.history.dynamicFieldsObj.name></td><td>
<#task.history.dynamicFieldsObj.value></td></tr>
<#endBlock>
<#block-1:NotEmpty[task.history.attachments]>
<tr><td colspan="2">Přílohy</td></tr>
<#block-2:Iterate[task.history.attachments]>
    <tr><td>&nbsp;</td><td>
<a href=
"http://www.taskpool.net/file.do?id=<#task.history.attachments.uploadId>">
   <#task.history.attachments.uploadDesc></a></td></tr>
<#endBlock-2>
<#endBlock-1>
</body>
</html>

Kapitola 16. Ověření

Funkce Ověření umožňuje definovat administrátorovi TaskPoolu přístup do externí databáze. Tato databáze bývá nejčastěji využívána pro evidenci zákazníků. Takovou databázi pak můžeme použít např. pro ověřování do Helpdesku (kapitola 17. Helpdesk) nebo např. jako seznam možností pro SQL selectbox (kapitola 4.10. SQL selectbox).

Přístup do Helpdesku pomocí ověření přináší několik výhod. První výhodou je automatické načtení osobních hodnot zákazníka (jméno, e-mail, telefon apod.) při zadávání nového helpdeskového požadavku. Druhou hlavní výhodou je možnost přehledného sledování a vyřizování všech požadavků, které daný uživatel do systému zadal.

Ověření může být více typů - vůči Windows doméně prostřednictvím protokolu LDAP či Active Directory, nebo vůči externímu relačnímu databázovému systému, a to MySQL, MSSQL nebo Firebird a nebo vůči protokolu CAS (Central Authentication System).

Pokud nechcete blíže zkoumat možnosti konfigurace jednotlivých typů ověření a spokojíte se s rychlým zprovozněním ověření pomocí vzorové databáze, je možné rovnou přeskočit na kapitolu 16.3. Použití vzorové databáze.

Část LDAP

LDAP (Lightweight Directory Access Protocol) je protokol umožňující efektivní sdílení strukturovaných informací po TCP/IP. V praxi to znamená např. seznam zaměstnanců firmy, jejich přihlašovací jména, domovské adresáře, osobní informace, e-mailové adresy nebo čísla telefonů. Strukturu informací si lze v LDAP představit jako strom, jehož koncové větve obsahují konkrétní údaje.

Autentizace pomocí LDAP přináší oproti autentizaci přes databázi dvě hlavní výhody. První výhoda je stejné přihlašovací údaje pro všechny aplikace využívané danou firmou, tedy např. do operačního systému, do TaskPoolu, na Helpdesk atd. Druhou výhodou je možnost automatizace celého ověření. Přihlášení pak může probíhat pomocí spouštěcího souboru, který uživatele do Helpdesku (nebo i do TaskPoolu) automaticky přihlásí, více v kapitole 16.1.4. Přihlášení do Helpdesku pomocí autentikátoru.

Samozřejmě i v případě použití LDAP autentizace máme možnost plného přizpůsobení layoutu jednotlivých stránek Helpdesku potřebám firmy.

Předpoklady použití Helpdesku s LDAP autentizací

Pro správnou funkci LDAP autentizace jsou nutné tyto systémové požadavky:

  • LDAP server a možný přístup serveru s instalací TaskPoolu k tomuto

  • TaskPool verze 1.7.3 a vyšší

Záznam uživatele musí být v LDAP vyhledatelný podle atributu obsahující ID, kterým se uživatel přihlašuje ke své pracovní stanici.

Příklad:

  • uživatel se přihlašuje pod ID: novakj

  • v LDAPu musí být možné dohledat odpovídající záznam např. pomocí: uid = novakj

  • nalezený záznam musí dále obsahovat atributy dalších polí, které se mapuji do helpdesku:

    • povinně: jméno, příjmení, e-mail

    • volitelně: telefon, firma

Princip Helpdesku s LDAP autentizací

Princip ověření bez automatického autentikátoru je následovný:

  1. Uživatel vyplní login a heslo do přihlašovací obrazovky.

  2. TaskPool zjistí z LDAPu ID uživatele.

  3. TaskPool obdrží z LDAP serveru další údaje o uživateli a předá je do helpdeskového formuláře. Tím je uživatel ověřen, může zadat task a také vidí všechny své dříve zadané požadavky.

  4. V případě, že TaskPool neobdrží od LDAP serveru potvrzení o existenci uživatele a správnosti přihlašovacích údajů, považuje se uživatel za neověřeného a musí do Helpdesku vstoupit bez přihlášení, tedy zadat svoje jméno, e-mail apod. a současně nevidí přehled dříve zadaných požadavků.

Na obrázku je znázorněno schéma přihlášení pomocí LDAP automatického autentifikátoru.

Obrázek 16.1. LDAP autentifikátor

LDAP autentifikátor

Nastavení Helpdesku s LDAP

Pro zprovoznění LDAP autentizace je nutné:

  • v nastavení ověření nastavit proměnné pro přístup k LDAP serveru

  • nastavit layout přehledu požadavků, které uživatel zadal k řešení

  • nastavit layout přihlašovací obrazovky

Formulář pro vytvoření nového ověření vyvoláme kliknutím na tlačítko Nový na kartě "Ověření" v administrační části.

Obrázek 16.2. Vytvoření nového ověření pomocí LDAP

Vytvoření nového ověření pomocí LDAP

Tlačítkem Autofill máme možnost automaticky vložit do konfiguračního formuláře přístupové řetězce pro LDAP.

Ověření může být i více, proto má každé svůj specifický název. Uživatel si pak při přihlašování do Helpdesku např. vybere svoji vlastní firmu apod. A stejně jako většinu funkcí TaskPoolu, tak i ověření můžeme snadno deaktivovat.

LDAP URL

  • URL Adresa LDAP serveru ve formě protokol://adresa:port. Například ldap://ldap.vaseadresa.cz:389 a pro Secure LDAP ldaps://ldap.vaseadresa.cz:636.

Uživatelské jméno

  • Uživatelské jméno, pod kterým se TaskPool přihlašuje k LDAP serveru. V Active Directory zadáváme uživatelské jméno ve tvaru domain\username.

Heslo

  • Heslo pro přihlášení k LDAP Serveru.

Vyhledávat od

  • Specifikace oblasti ve které má TaskPool prohledávat LDAP objekty. Odpovídá anglickému termínu Search Base. Pokud máte ve firmě více organizačních jednotek (např. OU=Sales in O=IBM and OU=Development in O=IBM) a OU=sales není při autentizaci využíváno, je dobré omezit vyhledavaní pouze na OU=Developement zadaním "OU=Development" nebo "O=IBM" a urychlit tak proces autentizace uživatele. V základním případě postačí doména, tedy např. OU=Development, O=IBM, DC=IBZ, DC=CZ.

Použít DN pro login

  • Touto volbou určujeme, zda bude k přihlašovacímu jménu automaticky doplněna cesta ke konkrétnímu záznamu ve struktuře LDAPu. Příklad:

    • volba Aktivní - login vyplněný na formuláří: "novak", login použitý pro připojení k LDAPu: CN=novak,DC=comarr,DC=cz

    • volba Neaktivní - login vyplněný na formuláří: "novak", login použitý pro připojení k LDAPu: novak

POZN.: Active Directory toto nastavení nemusí vyžadovat.

Vyhledat vzor pro uživatele

  • Specifikace filtru za který bude TaskPool dosazovat jednotlivé uživatele, aby ověřil jejich identitu na LDAP serveru. Např. (uid={0}), kde "uid" je proměnná s uživatelskými jmény a "{0}" je zástupný znak pro uživatelské jméno uživatele. Dalším příkladem může být ObjectClass=person. Tento vzor bude vyhledávat pouze ty uživatele, kteří mají v příznaku type hodnotu "person".

POZN.: Při použití Secure LDAP je před použitím LDAP autentizace nutné naimportovat do JAVY příslušné bezpečnostní certifikáty.

SQL pro změnu hesla, SQL pro vložení uživatele

  • Tyto volby jsou při nastavení LDAP autentizace irelevantní, TaskPool nemá oprávnění měnit přístupové údaje v LDAPu. Toto nastavení je možné využít při ověřování přes databázi.

Mapování LDAP

  • Dále je nutné zadat příslušné proměnné LDAP objektů k příslušným popiskům, např:

  • Jméno: givenName

  • Příjmení: sn

  • E-mail: mail ...atd.

POZN.: Sekce "Dotaz pro vyhledání skupiny uživatelů" je určena pro konfiguraci manažera zadavatelů na Helpdesku. Vše potřebné je uvedeno v kapitole 16.4. Manažer zadavatelů na Helpdesku.

Tlačítkem Ověřit připojení a mapování uživatelů je možné otestovat funkčnost konfigurace.

Uvedeme zde ještě příklad nastavení pro Active Directory, kde je konfigurace podobná.

Obrázek 16.3. Vytvoření nového ověření pomocí Active Directory

Vytvoření nového ověření pomocí Active Directory

Přihlášení do Helpdesku pomocí autentikátoru

Na následujícím obrázku je schéma přihlášení pomocí výše zmíněného automatického autentikátoru. Jedná se o dávku, která po spuštění uživatele do Helpdesku (či TaskPoolu) automaticky přihlásí. Tento autentikátor najdeme v adresáři se soubory systému TaskPool:

..\ROOT\WEB-INF\tools\HelpdeskLogin\

Manuál k němu najdeme v příručce správce, tedy v souboru:

..\ROOT\help\TaskPool_cz_install.pdf

Podobným způsobem máme možnost používat automatické přihlášení přímo do řešitelského rozhraní TaskPoolu:

..\ROOT\WEB-INF\tools\TaskPoolLogin\

Část Database

V části Database lze nastavit, aby uživatelé při přihlášení k Helpdesku mohli být ověřováni pomocí externí databáze (např. firemní databáze klientů). Stejně jako v případě LDAP jsou osobní údaje načteny z databáze a není nutné je vyplňovat.

Toto ověření je funkčně prakticky shodné s LDAP autentizací, pouze probíhá na jiném základě databáze.

Při použití databázového rozhraní navíc můžeme použít velmi užitečný nástroj External Database Manager, pomocí kterého můžeme spravovat data externích databází přímo z rozhraní TaskPoolu, více v kapitole 20. External Database Manger.

Database rozhraní se konfiguruje na stejném formuláři jako LDAP, typ ověření a databáze nastavujeme v horní části pomocí výběrových polí. Pomocí tlačítka Autofill systém automaticky vyplní konfigurační pole základními příkazy.

Obrázek 16.4. Ověření pomocí databáze

Ověření pomocí databáze

DB řetězec

  • Jedná se o řetězec používaný pro připojení k databázi. Specifikují se v něm podrobnosti spojení, jako je jméno databáze, server, port a kódování.

    • Pro MySQL se může jednat o tento řetězec:

      jdbc:mysql://localhost:3306/customerdb?useUnicode=true&characterEncoding=utf8

      Jedná se o připojení na lokální server na portu 3306 a na databázi "customerdb" a kódování "utf8".

    • Pro MSSQL (ovladač JTDS) se může jednat o tento řetězec:

      jdbc:jtds:sqlserver://localhost:1433/customerdb

      Opět se jedná o připojení na lokální server, port 1433 a databáze "customerdb".

Uživatelské jméno a heslo

  • Uživatelské jméno a heslo pro připojení k databázi.

Connection pool

  • Metodu Connection pool, neboli Sdružování připojení, lze použít pro rychlejší připojení k databázi. Nedoporučujeme používat mimo vnitřní síť. Nelze použít pro LDAP/AD.

SQL pro ověření hesla

  • SQL dotaz, který se použije pro ověření hesla konkrétního uživatele, např.:

    select count(*) from contact where username = '{0}' and password = '{1}' AND isActive = 1

POZN.: U SQL příkazů konfigurovaných v ověření není nutné na konci příkazů zapisovat středník. Nápovědy k jednotlivým SQL příkazům jsou uvedeny vždy pod kolonkou pro daný příkaz.

SQL pro změnu hesla

  • Tento příkaz vyplňujeme, pokud v Helpdesku využíváme možnost změny hesla samotnými uživateli.

    update contact set password = '{2}' where username = '{0}' and password = '{1}'

SQL pro vložení uživatele

  • Tento příkaz vyplňujeme, pokud v Helpdesku využíváme možnost registrace účtů samotnými uživateli.

    call insertContactAndCompany('{hd_login}', '{hd_pass}', '{hd_firstname}', '{hd_lastname}', '{hd_e_mail}', '{hd_phone}', '{hd_note}', '{hd_company}', 0, 1)

SQL pro výběr uživatele

  • SQL dotaz vracející právě jeden řádek s údaji uživatele. Jako zástupný řetězec pro ID uživatele používáme {0} (ID je standardně myšleno uživatelské jméno).

    select * from contact join company on (contact.companyId = company.id) where username = '{0}' AND isActive = 1

Mapování

  • V této sekci se nastavuje mapování jednotlivých údajů pro Helpdesk na konkrétní sloupce tabulky.

Funkčnost konfigurace můžeme otestovat tlačítkem Ověřit připojení a mapování uživatelů. Po úspěšném připojení k databázi můžeme provést testovací přihlášení.

Použití vzorové databáze

Pro rychlé zprovoznění ověření pomocí databáze je možné použít přednastavenou databázi. K dispozici je verze pro MySQL i MSSQL. Obě databáze se nachází v adresáři se soubory TaskPoolu:

..\ROOT\WEB-INF\tools\edm\database.MySQL.sql

..\ROOT\WEB-INF\tools\edm\database.MSSQL.sql

POZN.: V tomto adresáři se nachází i soubor applicationXml.xml, který slouží ke zprovoznění již zmíněné funkce External Database Manager. Pro snadné zprovoznění této funkce je opět možné použít vzorovou variantu, více v kapitole 20. External Database Manager.

Pro snadné zprovoznění databáze stačí naimportovat tabulku obsaženou v jednom ze souborů na databázový server. Zde si ukážeme variantu pro MySQL, pro MSSQL je situace podobná.

V případě MySQL můžeme provést import databáze v příkazovém řádku následujícími příkazy:

mysql -uroot -p   //vstup do MySQL pod uživatelem 'root'
create database externalDB;   //vytvoření databáze
exit;   //odchod z MySQL

Nyní jsme vytvořili prázdnou databázi, do které naimportujeme tabulky ze souboru database.MySQL.sql tímto způsobem:

mysql externalDB < c:\database.MySQL.sql -uroot -p

Samozřejmě za předpokladu, že daný soubor se nachází v kořenovém adresáři disku C, v opačném případě je potřeba uvést plnou cestu k souboru. Nyní je potřeba ještě vytvořit uživatele a přidělit mu práva k databázi. Samozřejmě je možné použít uživatele 'root', pro větší bezpečnost však doporučujeme mít pro každou externí databázi zvláštního uživatele.

mysql -uroot -p   // vstup do MySQL pod uživatelem 'root'
create user extdbuser identified by 'heslo';   //vytvoření uživatele 'extdbuser' s heslem 'heslo'
grant all privileges on externalDB.* to extdbuser identified by 'heslo';
   // uživateli 'extdbuser' tímto příkazem přiřadíme veškerá práva pro databázi 'externalDB'
exit;   //odchod z MySQL

Nyní máme připravenou databázi a stačí již pouze nastavit ověření, což provedeme jednoduše stisknutím tlačítka Autofill na formuláři tvorby nového ověření. Tím se v konfiguračním formuláři vyplní všechny potřebné položky. Jediné co upravíme je přístup k samotné databázi. Za předpokladu, že databázový server se nachází na lokálním serveru na portu 3306 bude nastavení vypadat takto:

Obrázek 16.5. Konigurace ověření při použití vzorové databáze

Konigurace ověření při použití vzorové databáze

Manažer zadavatelů na Helpdesku

I Helpdesk umožňuje použití role manažera zadavatelů. Manažer vidí v přehledu svých požadavků také požadavky svých podřízených a může do nich přispívat komentáři, popř. schvalovat navržené podmínky.

CAS (central authentication system)

Systém jednotného přihlášení CAS umožňuje uživateli po přihlášení automatický přístup do všech aplikací, které jsou součástí CAS služby. CAS podporuje také jednotné odhlášení.

Systém TaskPool bývá zpravidla přidáván již do funkčního CAS systému, ale v principu není problém vytvořit CAS pro TaskPool samostatně.

Do systému CAS se musí TaskPool zaregistrovat pod správnou URL adresou.

Obrázek 16.6. Příklad konfigurace CAS

Příklad konfigurace CAS

Poznámka: V poli Firma je uveden název ´veřejnost´ v jednoduchých uvozovkách, což značí, že se vžy do pole Firma vypíše tento textový řetězec.

Kapitola 17. Helpdesk

Modul Helpdesk slouží pro oddělení TaskPoolu od uživatelů Helpdesku pomocí webových formulářů. Helpdeskový uživatel vůbec nemusí mít přístup do TaskPoolu a přesto do něj může zakládat tasky. Proto budeme v této kapitole nazývat helpdeskový task požadavkem a jeho zadavatele zákazníkem. Když zákazník zadá požadavek přes webové rozhraní, v TaskPoolu se tento požadavek založí jako helpdeskový task, se kterým nadále pracujeme jako s taskem klasickým. Pokud řešitelská strana na požadavek odpoví, zákazníkovi přijde upozornění o reakci na jeho požadavek a pomocí webového formuláře nebo i odpovědi na e-mail může znovu reagovat.

POZN.: Přístup do Helpdesku je možný jednak bez nutnosti přihlašování pomocí uživatelského jména a hesla, v takovém případě zákazník vyplní svoje kontaktní údaje vždy při zadávání nového požadavku. Dále je možné mít pro každého zákazníka svůj vlastní login, díky němuž odpadá nutnost vyplňovat kontaktní údaje a zároveň je mu umožněno mít na jednom místě výpis všech jeho dříve zadaných požadavků. Při použití ověření je také možné rozdělovat role helpdeskových uživatelů na klasického zadavatele a manažera zadavatelů, podobně jako v řešitelském rozhraní TaskPoolu. O této problematice se více dočteme v kapitole 16. Ověření, kterou doporučujeme přečíst nejdříve. V následující kapitole bude problematika ověřování zmiňována poměrně často.

Kompletní nastavení modulu Helpdesk se zobrazí po klepnutí na odkaz upravit v kolonce "Stav helpdesku" u příslušného poolu. Po kliknutí se otevře nové okno, kde jsou jednotlivé možnosti nastavení modulu Helpdesk rozděleny do záložek, podobně jak je tomu v nastavení poolu.

POZN.: Konfiguraci helpdesku je možné provést pomocí pár kliknutí pomocí vzorových kódů, postup je popsaný v kapitole 17.2. Karta Základní nastavení. Doporučujeme však mít alespoň základní znalost o zástupných řetězcích v Helpdesku hojně využívaných, proto na danou kapitolu nedoporučujeme ihned přeskakovat.

Obrázek 17.1. Administrace: Pooly

Administrace: Pooly

Využití zástupných řetězců

Vzhled všech webových formulářů na Helpdesku je volně konfigurovatelný. Princip jejich tvorby je podobný principu tvorby klasické webové stránky pomocí jazyka HTML. Odlišná je pouze tvorba samotných formulářů. Místo klasických HTML polí pro input totiž využíváme zástupných řetězců. Tyto řetězce nám tvorbu formulářů zjednodušují, každý zástupný řetězec v kódu představuje jedno pole pro input na webovém formuláři. Lze tak jednoznačně určit, který údaj v tasku bude dané pole reprezentovat. Zástupné řetězce ale mohou sloužit i pro výpis určitých hodnot, více se dozvíme v dalších podkapitolách.

Seznam dostupných zástupných řetězců s popisem jejich významu je zobrazen zpravidla vlevo na kartě konfigurace každého formuláře.

Použití zástupných řetězců je jednoduché. Zástupný řetězec stačí zkopírovat nebo přepsat na požadované místo. Na obrázku je příklad takového seznamu řetězců a ukázka využití v externím odkazu na helpdeskový požadavek, používaného v helpdeskových notifikacích. Místo zástupných řetězců <#id> a <#lang> TaskPool automaticky doplní příslušné ID tasku a preferovaný jazyk helpdeskového zobrazení.

Obrázek 17.2. Příklad použití zástupných řetězců

Příklad použití zástupných řetězců

Karta Základní nastavení

První položkou konfigurace Helpdesku je karta "Základní nastavení". V hlavičce tohoto okna vidíme, ke kterému poolu se konfigurace daného Helpdesku vztahuje.

Helpdesk můžeme podobně jako pooly a uživatele deaktivovat. Při deaktivaci není umožněn příjem nových požadavků (přes web ani přes e-mail), ale na historii již zadaných požadavků lze stále přistupovat. Toto nastavujeme pomocí pole Stav.

Obrázek 17.3. Helpdesk: Základní nastavení

Helpdesk: Základní nastavení

Identifikační kód Helpdesku je unikátní identifikátor každého Helpdesku, který se bude zobrazovat v odkazu na helpdeskové tasky. Musí začínat písmenem. Odkaz na www rozhraní odkazuje na vlastní Helpdesk. Celý Helpdesk je možné nakonfigurovat v různých jazykových mutacích (viz obrázek výše). Odkazy jsou vytvořeny na nejpoužívanější jazyky.

POZN.: Konfiguraci není nutné vyplňovat ve všech jazycích, stačí nakonfigurovat tu jazykovou verzi, kterou budeme používat.

Tlačítko Správa formulářů pomocí archivu slouží pro snadné nahrání helpdeskových formulářů, popř. pro vytvoření zálohy již nakonfigurovaného Helpdesku. Po rozkliknutí odkazu se objeví následující možnosti:

Obrázek 17.4. Helpdesk: Správa formulářů pomocí archivu

Helpdesk: Správa formulářů pomocí archivu

Po stisku tlačítka Stáhnout archiv uložených formulářů systém vytvoří *.zip archiv všech formulářů daného helpdesku, jeho uložení do počítače pak funguje stejně jako např. stahování souborů z internetu. Zároveň můžeme pomocí takového archivu rychle nakonfigurovat nový Helpdesk, popř. archiv použít k obnovení zálohy. V takovém případě stačí vložit archiv do okna pro nahrání souboru a po uložení TaskPool tento soubor automaticky zpracuje a nahraje všechny potřebné formuláře. Pro správnou funkčnost musí být dodrženy správné názvy jednotlivých souborů v archivu.

POZN.: Pokud chceme pro vstup do Helpdesku použít ověření, i tato funkce umožňuje import vzorové konfigurace, více v kapitole 16.3. Použití vzorové databáze. Dané ověření je pak potřeba aktivovat v konfiguraci Helpdesku, to provedeme na konfigurační kartě "Přihlášení", více v kapitole 17.12. Karta Přihlášení.

WWW-rozhraní je určeno pro komunikaci se zákazníkem. Umožňuje zadání požadavku, prohlížení jeho historie a pokračování v komunikaci formou přidávání dalších komentářů. Tento odkaz je automaticky generován podle zvoleného identifikátoru Helpdesku. Po kliknutí na něj se uživatel dostane do samotného Helpdesku.

POZN.: Pro integraci Helpdesku do webových stránek je možné využít HTML element <iframe>. Jedná se o rámec, který lze jednoduše vložit do webových stránek na vyhrazené místo. Z důvodu přirozených nevýhod tohoto elementu však toto řešení příliš nedoporučujeme. Vhodnější řešení je zavést pro Helpdesk na stránkách samostatný oddíl, popř. subdoménu.

Kód pro vložení Helpdesku pomocí iframu by vypadal např. takto:

<iframe scrolling="no" height="500" width="560" frameborder="0" src="http://www.taskpool.biz//servlet/HelpdeskDynamic?eid=Helpdesk1&lang=cs"></iframe>

Odkaz musí být shodný s vygenerovaným odkazem v sekci "WWW-rozhraní", jazyk je možné zvolit ručně.

Odkaz na historii tasku se chová podobně. Pod polem pro jeho zadání najdeme jeho defaultní podobu. Pokud budeme jako na obrázku provozovat TaskPool na serveru http://localhost:8080, bude odkaz vypadat takto:

http://localhost:8080//servlet/HelpdeskView?id=<#id>&lang=<#lang>

Toto je univerzální URL, kde zástupné řetězce <#id> a <#lang> budou v notifikaci nahrazeny konkrétními hodnotami. Pokud používáme např. jenom českou verzi konkrétního Helpdesku, může odkaz vypadat takto:

http://localhost:8080//servlet/HelpdeskView?id=<#id>&lang=cs

Další položkou na této kartě jsou Jazyky. Zde je nutné povolit alespoň jeden z nich a nastavit, který jazyk bude defaultní. Helpdesk umožňuje, stejně jako celý systém, trojjazyčnou variantu zobrazení.

TaskPool posílá zákazníkům notifikace podobně jako přímým uživatelům TaskPoolu. Pomocí těchto e-mailů probíhá komunikace mezi zákazníkem a řešitelskou stranou. Zákazníkovi dojde notifikace o změně jím zadaného požadavku a tělo notifikace obsahuje odkaz na jeho historii. Po rozkliknutí odkazu se zákazník dostane přímo do Helpdesku a může pokračovat v komunikaci. V sekci Nastavení zasílaného e-mailu nastavujeme vlastnosti těchto e-mailových notifikací. Odesílatel je podobně jako u notifikací v poolu hodnota, která bude zobrazena v zaslaném e-mailu v poli "Od". Předmět odpovídá předmětu zasílaného e-mailu.

Sekce Pravidla pro zasílání e-mailů a Vytvoření tasku přes TaskPool budou vysvětleny v následující podkapitole.

Výchozím chováním TaskPoolu je, že pokud helpdeskový uživatel přidá komentář k již dokončenému požadavku, požadavek se znovu automaticky otevře. Volbou Otevírat již archivované tasky můžeme nastavit, aby se tyto tasky neotevírali. Pokud tato volba nebude zaškrtnuta, dokončený nebo i archvivovaný task se komentářem zákazníka neotevře.

Volba Změna helpdeskového uživatele umožňuje zadávat tasky na Helpdesku v zastoupení. V praxi může helpdeskový uživatel po přihlášení do Helpdesku pod svým loginem vybrat jiného uživatele z daného ověření, pod kterým task zadá. Poděkování za požadavek s adresou na jeho historii pak dojde tomuto uživateli, nikoliv zastupujícímu zadavateli. Třetím checkboxem v nastavení určíme, zda se tyto změny uživatele budou zapisovat do historie tasku.

POZN.: Ke správné funkci změny helpdeskového uživatele je nutné mít v helpdeskovém formuláři zástupný řetězec <input name="hd_autocomplete" />, který umožňuje výběr konkrétního uživatele.

Pravidla pro zasílání e-mailů

Základní workflow při řešení helpdeskových požadavků je následující:

  1. Zadání požadavku helpdeskovým uživatelem (zákazníkem)

  2. Převzetí tasku řešitelem

  3. Komunikace ze strany řešitele

  4. Komunikace ze strany zadavatele

  5. Vyřešení požadavku řešitelem a dokončení tasku

  6. Případné potvrzení zadavatelem nebo vrácení požadavku řešiteli k přepracování

V sekci Pravidla pro zasílání e-mailů je možné nastavit, v jakých případech bude zákazníkovi zasílána notifikace.

Obrázek 17.5. Pravidla pro zasílání e-mailů

Pravidla pro zasílání e-mailů

"Poděkování" znamená potvrzovací e-mail o přijetí nového požadavku k řešení. V možnosti "Zasílat ostatní informace a změny" je zahrnuto např. prosté přidání komentáře k požadavku řešitelem. Ostatní volby jasně plynou z názvu dané možnosti.

Může se stát, že si nepřejeme zákazníka notifikovat o určitém typu akcí, např. při převzetí požadavku k řešení nebo při jeho archivaci. V takovém případě tyto volby zrušíme. Pokud dojde k situaci, kdy upravujeme task a provádíme akci při které dle daného nastavení nemá přijít zákazníkovi notifikace, v okně úpravy tasku v TaskPoolu se zobrazí volba Email HD uživateli. Pokud toto pole zaškrtneme, po uložení tasku dojde zákazníkovi notifikace o provedené změně v tasku. Je tedy na řešiteli, ve kterých případech zákazníka informovat. Lze např. použít zcela manuální přístup k zasílání notifikací zrušením veškerých automaticky zasílaných notifikací.

Obrázek 17.6. Manuální notifikace HD uživateli

Manuální notifikace HD uživateli

Vytvoření zákaznického požadavku na Pracovišti

Helpdeskový task je možné vytvořit přímo v řešitelském rozhraní TaskPoolu. Můžeme tak zadat task v zastoupení za helpdeskového uživatele, tedy zákazníka. V praxi to znamená, že při zadávání tasku vyplníme údaje o zákazníkovi a po uložení tasku dojde tomuto uživateli poděkování za požadavek, podobně jako kdyby požadavek zadal sám přímo na Helpdesku. Pokud chceme používat tuto volbu, alespoň jedna z rolí pro ni musí mít v daném poolu oprávnění. To nastavení se provede v sekci "Vytvoření tasku přes TaskPool". Zde také nastavujeme, zda bude možné v daném helpdeskovém poolu zadávat klasické interní tasky.

Obrázek 17.7. Nový HelpDesk

Nový HelpDesk

POZN.: Funkce Spoluzadavatelé je přístupná pouze při použití ověření. Princip je podobný jako u spoluřešitelů. Spoluzadavatel vidí daný požadavek i ve svém přehledu helpdeskových požadavků, má možnost k němu přispívat komentáři a dostává z něj notifikace.

Ostatní položky formuláře jsou již shodné s vytvářením klasického tasku.

Možnost e-mailové komunikace

Komunikace mezi zákazníkem a řešitelem požadavku je možná i čistě na základě e-mailových zpráv. Zákazník tak nemusí pro každou reakci na požadavek navštěvovat webové rozhraní. Stačí, aby odpověděl na zaslanou notifikaci klasickým způsobem (volbou "Odpovědět" ve svém e-mailovém klientu) a TaskPool připojí tuto odpověď do požadavku jako poslední komentář.

POZN.: Pro správný chod této funkcionality je nutné mít aktivované e-mailové rozhraní pro konkrétní pool (více v kapitole 17.16. E-mail Interface na Helpdesku).

Pro identifikaci požadavku v TaskPoolu slouží speciální zástupný řetězec <#hd_hash_id>, který vložíme do pole "Předmět" v části "Nastavení zasílaného e-mailu". Předmět zaslané notifikace pak bude mít tvar např. "Helpdesk -id ##84735100166##". Po odpovědi na notifikaci se pomocí ID v předmětu notifikace přiřadí komentář ke konkrétnímu požadavku.

POZN.: Citace původního obsahu notifikace se do komentáře nepřenáší.

Pole pro předmět helpdeskové notifikace může vypadat např. takto:

  • Helpdesk - id: <#hd_hash_id>

Šablony na Helpdesku

Nyní se dostáváme k samotné tvorbě helpdeskových formulářů. Protože téměř každá helpdesková stránka obsahuje společné prvky (např. hlavička a patička), TaskPool umožňuje v jednotlivých formulářích využívat šablony, tedy společný kód uložený v samostatném souboru. Tento soubor nahrajeme na server v administraci na kartě "Soubory" (kapitola 11. Soubory). Na tento soubor se pak můžeme odkázat z kódu libovolné stránky tímto způsobem:

  • <#template_include file="HDhlavicka.html"> - pokud je v sekci "Soubory" nahrán soubor "HDhlavicka.html", do zdrojového kódu formuláře bude vložen jeho obsah.

Práci se šablonami je možné rozšířit o posílání parametrů. To umožňuje např. snadnou změnu loga u každého z jednotlivých Helpdesků. V šabloně uložené v souborech musí být tento kód:

<img src="<#template_attribute name="logoSpolecnosti">" />

Název parametru v tomto případě představuje "logoSpolecnosti" a může být pro něj použit libovolný řetězec bez diakritiky. Odkaz na šablonu s parametrem bude v kódu formuláře vypadat takto:

<#template_include file="HDhlavicka.html">
<#template_param name="logoSpolecnosti"
   value="http://www.taskpool.net/img/ref_comarr.gif">
<#template_include_end>

Do šablony "HDHlavicka.html" bude jako parametr "logoSpolecnosti" posláno URL http://www.taskpool.net/img/ref_comarr.gif.

Podmínky na Helpdesku

Pro zobrazování určitých elementů je možné použít podmínky. Můžeme tak např. zajistit zobrazení určitého textu pouze tehdy, pokud je task dokončen nebo např. pokud je uživatel ověřen apod. Nejčastěji používané podmínky jsou tyto:

<#if "user_authenticated">
   <a href="<#hd_overview_url>">Vaše požadavky</a>
<#endif>

Tato podmínka zajistí, aby se odkaz pro přehled zadaných požadavků zobrazoval pouze ověřenému uživateli.

Další podmínkou je možné určit, které konkrétní roli bude zobrazen daný text.

<#if "roleId == 2">Text pro zadavatele<#endif>
<#if "roleId == 16">Text pro manažera zadavatelů<#endif>

Pomocí třetí podmínky je možné zobrazovat obsah podle stavu požadavku. Tento konkrétní příklad slouží ke schvalování podmínek na Helpdesku. Pokud jsou řešitelem navrženy nové podmínky (deadline, cena), task přejde do stavu se stateId=202 a uživateli Helpdesku se zobrazí selectbox, kde může podmínky přijmout nebo odmítnout.

<#if "stateId = 202">
   Byly navrženy nové podmínky, souhlasíte? <#hd_customer_confirm>
<#endif>

Karta HD Formulář

Helpdeskový formulář je základní stránka Helpdesku, na které zákazník zadává svůj požadavek. Vyplňuje přitom svoje kontaktní údaje (jméno, e-mail, telefon), popis problému a volitelně další hodnoty (SLA, prioritu, apod.).

Pro zobrazení jednotlivých vstupních polí se využívají zástupné řetězce, popsané v kapitole 17.1. Využití zástupných řetězců. Místo každého zástupného řetězce se do stránky automaticky vygeneruje vstupní pole pro text (případně i pro vložení přílohy).

POZOR! Elementy <form> a </form> se do kódu nezapisují! Tyto elementy TaskPool generuje automaticky a při jejich ručním zápisu bude Helpdesk nefunční!

Základní schéma formuláře je k dispozici po rozkliknutí odkazu Ukaž vzorový kód. Ze vzorového kódu se dá snadno pochopit princip fungování zástupných řetězců. Jejich popis najdeme v levé části stránky pro konfiguraci formuláře. V této části stránky je také možné zvolit, které hodnoty budou při vyplňování formuláře povinně vyžadovány. Pokud je pole označeno jako povinné, TaskPool k němu automaticky doplní ve formuláři hvězdičku. V případě, že nebude povinné pole vyplněno a formulář bude odeslán, zobrazí se stránka chybového hlášení.

Na této stránce je dále možné nastavit velikost pole pro popis požadavku a text odesílacího tlačíka.

Obrázek 17.8. Helpdesk: HD Formulář

Helpdesk: HD Formulář

Výsledný helpdeskový formulář pak může vypadat např. takto:

Obrázek 17.9. Příklad helpdeskového formuláře bez ověření

Příklad helpdeskového formuláře bez ověření

Obrázek 17.10. Příklad helpdeskového formuláře za použití ověření

Příklad helpdeskového formuláře za použití ověření

POZN.: Jak již bylo řečeno, při použití ověření uživatel nemusí vyplňovat svoje osobní údaje. Ty jsou načteny z databáze při ověření uživatele. Zároveň na formuláři bez ověření není dostupný přehled již zadaných požadavků a funkce spoluzadavatelé. Tyto funkce je možné využít pouze s aktivním ověřením. Ověření zároveň funguje jako ochrana proti spamovacím robotům, při použití formuláře bez ověření doporučujeme použít kontrolu captcha. Kód pro vložení je následující:

<#if "!user_authenticated">
  <tr><th><label for="captcha"></label></th><td><img src="../captcha.jpg"/></td></tr>
  <tr><th><label for="captcha2">Opište kód z obrázku*</label>
      </th><td><input type="text" name="captcha_key_name"/></td></tr>
<#endif>

Karta Chybová hlášení

Stránka chybového hlášení se zákazníkovi zobrazí v případě, kdy nevyplnil všechna povinná pole. Pro návrat na zadávací formulář doporučujeme použít javascriptový odkaz (viz vzorový kód), aby nedošlo ke ztrátě vyplněných údajů. Všechny případné nedostatky při vyplňování formuláře lze ošetřit pomocí javascriptu, k zobrazení chybového hlášení tak vůbec nemusí dojít.

Karta Poděkování

Po úspěšném odeslání požadavku se zákazníkovi zobrazí poděkování za požadavek spolu s odkazem na jeho historii, případně se mu odešle e-mail s podobným obsahem (viz 17.2.1. Pravidla pro zasílání e-mailů).

Na této kartě definujeme layout webového i e-mailového poděkování. Opět je k dispozici vzorový kód.

Webové poděkování může vypadat např. takto:

Obrázek 17.11. Příklad webového poděkování

Příklad webového poděkování

Karta Podpis

Na této kartě definujeme automatický podpis, který může použít řešitelská strana odpovědích na helpdeskové požadavky. Opět můžeme využívat všechny zástupné řetězce uvedené v levé části konfigurační karty.

Předvolený text se po kliknutí na tlačítko Podpis vloží pod napsaný komentář, a to nezávisle na aktuální pozici kurzoru.

Obrázek 17.12. Automatický podpis v praxi

Automatický podpis v praxi

Karta Notifikace

Notifikace je zákazníkovi zaslána, když řešitel s jeho požadavkem provede nějakou zákazníkovi viditelnou akci (komentář, převzetí, dokončení apod.). Např. v případě skrytých komentářů nebo přidávání podřízených tasků k požadavku notifikace zákazníkovi nechodí. V notifikaci by měl být odkaz na webovou stránku, kde má zákazník možnost přidat nový komentář, tedy na historii požadavku.

Karta Historie

Historie požadavku je helpdeskový ekvivalent detailu tasku v řešitelském rozhraní TaskPoolu. Zákazník zde vidí chronologii řešení daného požadavku a zároveň do něj může přispívat komentáři, přílohami, schvalovat podmínky apod. V historii se vypisují všechny akce, které jsou pro zákazníka viditelné.

Hlavička

Hlavička je horní část webové stránky historie požadavku. V nastavení vzhledu hlavičky je možno zadat zástupné řetězce pro informace o požadavku a pro přidání komentáře (formulář pro odpověď), toto okno však doporučujeme umístit do dolní části obrazovky. Může se pak stát, že by helpdeskový uživatel přidával svůj komentář bez přečtení řešitelova.

V praxi může hlavička historie požadavku vypadat takto:

Obrázek 17.13. Příklad hlavičky historie požadavku

Příklad hlavičky historie požadavku

Výpis komentářů

Do této části se zadává vzor pro zobrazení jednotlivého komentáře. TaskPool pak tento vzor automaticky použije pro zobrazení každého.

Obrázek 17.14. Příklad výpisu komentářů historie požadavku

Příklad výpisu komentářů historie požadavku

Patička

Patička je spodní část webové stránky historie požadavku. Do patičky je možné umístit stejné zástupné řetězce jako do hlavičky.

POZOR! Hlavička a patička historie požadavku není totéž, co hlavička a patička celého webového rozhraní Helpdesku!

Obrázek 17.15. Příklad patičky historie požadavku

Příklad patičky historie požadavku

Karta Přehled tasků

Přehled tasků funguje pouze pro ověřené uživatele. Bez ověření zákazník nemůže zobrazit seznam jím zadaných požadavků. Pokud se uživatel k Helpdesku přihlašuje, ať už pomocí LDAP či externí DB, lze jej v helpdeskovém systému personalizovat.

Karta pro přehled tasků představuje výpis požadavků zadaných konkrétním uživatelem. K požadavkům je možné pro lepší orientaci zobrazit doplňující vlastnosti.

Hlavička, výpis a patička

Hlavička je horní část webové stránky přehledu požadavků.

Ve výpisu je zobrazen seznam požadavků daného uživatele. Podobně jako u historie požadavku se zde definuje vzor pro zobrazení jednotlivého požadavku a TaskPool tento vzor použije i pro zobrazení každého dalšího.

Obrázek 17.16. Příklad přehledu požadavků

Příklad přehledu požadavků

Patička

Patička je spodní část webové stránky přehledu tasků. V přehledu tasků se patička užívá zpravidla pouze k uzavření elementů </table>, </body> apod.

TaskPool údaje o přihlášeném uživateli ukládá do cookies prohlížeče. Dokud tedy okno prohlížeče není zavřeno, nedojde k odhlášení uživatele a při příštím přístupu k formuláři již nebude vyžadováno jméno a heslo. Odkaz na ruční odhlášení je možné vytvořit použitím zástupného řetězce <#hd_o​vervie​w_url>​&hd_lo​gout_b​utton.

Příklad

<a href="​<#hd_o​vervie​w_url>​&hd_lo​gout_b​utton">Odhl​ášení</a> - vytvoří odhlašovací tlačítko s labelem "Odhlášení".

POZN.: I na Helpdesku je možné využít trvalé přihlášení, více v následující podkapitole.

Karta Přihlášení

Na této kartě je možné nastavit, zda budou uživatelé do Helpdesku přistupovat bez přihlášení nebo po zadání loginu, tedy pomocí ověření. Jsou možné i obě varianty najednou. Pokud chceme přistupovat do Helpdesku ověřeně, musíme ověření nejprve nadefinovat, o tom v kapitole 16. Ověření.

Zopakujme, že přístup do Helpdesku pomocí ověření přináší několik výhod. První výhodou je automatické načtení osobních dat (jméno, e-mail, telefon apod.) při zadávání nového helpdeskového požadavku. Druhou největší výhodou je možnost přehledného sledování a vyřizování všech požadavků, které daný zákazník do systému zadal.

V horní části obrazovky máme na výběr jednotlivá ověření a také tzv. anonymní přístup, který slouží pro vstup bez loginu. U požadovaných ověření je třeba zaškrtnout příslušný checkbox a vyplnit pořadí. Doporučujeme mít pro každý pool (firmu) zvláštní ověření. Samozřejmě je možné mít jedno ověření pro všechny Helpdesky, toto řešení však nedoporučujeme.

Obrázek 17.17. Helpdesk: Přihlášení

Helpdesk: Přihlášení

Podle nastavení na obrázku bude možné do Helpdesku přistupovat jak bez přihlášení (anonymně), tak ověřeně. Do požadavků zadaných pod ověřením bude možné přistoupit opět pouze po ověření. Pokud zvolíme pole Ověření vyžadováno jako neaktivní, bez ověření se bude možné dostat do všech požadavků daného Helpdesku, včetně těch zadaných pod ověřením.

Pro kód přihlašovací stránky se můžeme řídit opět vzorovým textem. Zvýšenou pozornost však věnujme tomuto řádku:

<select name="hd_authentication"> <#hd_authentication_options> </select>

Pokud používáme v daném Helpdesku více ověření, pomocí tohoto selectoboxu při přihlašování vybereme konkrétní z nich. Pokud používáme pro daný Helpdesk pouze jedno ověření, tento selectbox není třeba zobrazovat. Je to však povinný element, proto ho nemůžeme zcela odebrat, ověření by se tím stalo nefunkčním. Můžeme ho skrýt tímto způsobem:

<select name="hd_authentication" style="display: none;">
<#hd_authentication_options></select>

Karta správa hesel

Zde konfigurujeme formuláře pro změnu hesla ověřeného zákazníka nebo pro obnovení zapomenutého hesla.

Změna hesla probíhá obvyklým schématem - zadáním aktuálního hesla, zadáním nového a potvrzením nového hesla. Opět je k dispozici vzorový kód.

Obrázek 17.18. Příklad změny hesla

Příklad změny hesla

Obnovení Zapomenutého hesla slouží pro uživatele, kteří již mají účet, ale zapomněli k němu heslo. Pro správnou funkci je potřeba nakonfigurovat webový formulář a oznamovací e-mail, ale také formulář změny hesla! Obnovení zapomenutého hesla totiž funguje na principu změny hesla. Po zadání uživatelského jména a e-mailové adresy z profilu přijde na danou adresu oznamovací e-mail. Tento e-mail musí obsahovat řetězec <#hd_changePassword_url>, který představuje URL na formulář pro změnu hesla k účtu uživatele.

Obrázek 17.19. Příklad formuláře zapomenutého hesla

Příklad formuláře zapomenutého hesla

Karta Registrace

V případě použití ověření má každý zákazník má svůj login. Každý login představuje jeden řádek v tabulce v databázi. Nový záznam v tabulce může provést buď správce databáze nebo sám zákazník pomocí formuláře pro registraci, který se nastavuje na této kartě. Pomocí tohoto formuláře si budou moci uživatelé sami registrovat svůj přístup do Helpdesku.

Obrázek 17.20. Příklad registrace

Příklad registrace

Odkaz na stránku s registrací použijeme ve formátu:

<a href="<#hd_createUser_url>">registrace</a>

Tento odkaz najdeme také v nápovědě zástupných řetězců v levé části obrazovky.

Karta POP3-LDAP/DB

Doporučujeme nejdříve přečíst kapitolu 14. POP3 přiřazení. Jednotlivé e-mailové adresy lze přiřadit kromě uživatelů TaskPoolu také konkrétním uživatelům Helpdesku. Tito uživatelé musí do Helpdesku přistupovat pomocí ověření. Pokud je určitá e-mailová adresa přiřazena konkrétnímu uživateli, při příchodu požadavku e-mailem jej systém vybere z POP3 schránky a převede na helpdeskový požadavek, jehož zadavatelem je uživatel, který má přiřazenou danou e-mailovou adresu. Původní e-mailová adresa, ze které požadavek přišel, je pak uložena v dynamickém poli tasku.

Uživatele lze přiřadit jak na určitou konkrétní adresu (např. adam.novak@taskpool.cz), tak i na skupinu adres (např. pouze @taskpool.cz). Přiřadit lze také jazykovou verzi.

Postup vytvoření přiřazení je následující:

  1. Předpokladem je funkční ověření (kapitola 16. Ověření).

  2. Jakmile máme uživatele, na kterého budeme moci adresu přiřadit, na kartě "POP3-LDAP" v konfiguraci Helpdesku můžeme zvolit možnost Přidat přiřazení.

    Obrázek 17.21. Helpdesk: POP3-LDAP

    Helpdesk: POP3-LDAP

  3. V nabídce zvolíme ID helpdeskového uživatele a adresu pro mapování. Adresou může být jak konkrétní adresa, tak celá doména. Zvolíme také jazykovou verzi.

    Obrázek 17.22. Helpdesk: POP3-LDAP

    Helpdesk: POP3-LDAP

Tlačítkem Mapovat všechny uživatele TaskPool automaticky namapuje všechny uživatele z dané databáze na e-maily, které mají uloženy v databázi.

Checkbox Mapovat všechny uživatele automaticky zajistí, že každý nově přidaný uživatel do databáze bude automaticky mapován.

E-mail Interface na Helpdesku

Doporučujeme nejdříve přečíst kapitolu 3.9. Karta E-mail Interface. Na Helpdesku je princip podobný jako v poolu bez Helpdesku. Rozdíl je v tom, že e-maily vybírané ze schránky se zakládají jako helpdeskové tasky. Navíc je tu možnost došlý e-mail strukturovat na více informací.

Obrázek 17.23. Helpdesk: E-mail Interface

Helpdesk: E-mail Interface

Strukturování e-mailu máme naznačeno na obrázku. V tomto případě řádek začínající řetězcem "Text:" se převede na popis tasku, řádek začínající "Vyprší:" se převede na deadline tasku apod.

Podle Unikátní hodnoty se hledá již existující helpdeskový požadavek v daném poolu, který obsahuje ve stejném poli totožný text (například Text: akce001). V případě shody se text došlého e-mailu připojí jako komentář právě k tomuto požadavku (pozor na přemazání Názvu tasku názvem nového e-mailu). V opačném případě TaskPool založí nový helpdeskový požadavek. Unikátní hodnota není povinný údaj.

Pokud je zatrženo pole Akceptovat všechny e-mailové adresy, za odesílatele budou považovány všechny e-mailové adresy, na které daný e-mail došel vč. adres, na které došly kopie. V případě, že toto pole nebude zatrženo, jako adresa odesílatele se bude považovat pouze adresa skutečného odesílatele e-mailu.

Možnost Ignorovat podle výrazu lze použít pro zahození došlých e-mailů, které splňují zadané parametry, například:

mail.from == email1@domena.cz or mail.from == email2@domena.cz (ignoruje e-maily od vypsaných adresátů)

mail.subject == text1 (ignoruje e-maily s výrazem "text1" v předmětu

mail.body == text2 (ignoruje e-maily s výrazem "text2" v těle)

Více informací o syntexi lze najít na stránkách výrobce: http://commons.apache.org/proper/commons-jexl/reference/syntax.html

V případě, že chceme Použít TLS ověření, je mimo zaškrtnutí toho políčka nutné do Javy importovat nástroj "Keytool" podle návodu na této adrese: https://docs.oracle.com/javase/8/docs/technotes/tools/#security

Kopírování Helpdesků

Kompletní konfiguraci libovolného Helpdesku můžeme kopírovat mezi jednotlivými pooly. V administraci v seznamu poolů stačí kliknout na tlačítko Kopírovat Helpdesk, a to u toho poolu jehož helpdeskovou konfiguraci chceme kopírovat. Po kliknutí se objeví okno, ve kterém vybereme pouze cílový pool, do kterého se má konfigurace zkopírovat.

Obrázek 17.24. Kopírování Helpdesku

Kopírování Helpdesku

Pokud cílový pool již obsahuje aktivní Helpdesk, objeví se dotaz na přepsání dosavadní konfigurace.

Kapitola 18. SLA

Funkce SLA (Service Level Agreement) rozšiřuje možnosti TaskPoolu o práci s více časy, než pouze s klasickou deadline a to přes definované pracovní dny, hodiny a svátky. Standardně se počítají tři časy: Reakční doba (ReactionTime) a Čas řešení (FixTime). Můžeme tak např. detailně rozplánovat řešení helpdeskových požadavků. Zákazník zadá helpdeskový požadavek a pomocí SLA můžeme přesně řídit, do kdy nejdéle musí řešitel na požadavek reagovat, v jakých časových intervalech musí probíhat komunikace a do kdy musí být požadavek vyřešen. Pro větší urgenci je možné nastavit např. eskalace týkající se daných časů apod.

SLA časy

SLA časy jsou definovány ve dnech nebo v hodinách.

RT (Reaction Time, Reakční doba)

  • Reakční doba je čas, do kterého musí být task převzat. Převzetí tasku je také jedinná akce, která zastaví počítání tohoto času. Zastavení počítání reakčního doby je ale možno řídit i manuálně zaškrtnutím pole pro splnění podmínky, více v následující podkapitole.

FT (Fix Time, Čas řešení)

  • Čas, do kterého musí být task dokončen.

Konfigurace SLA

Pro uvedení SLA do provozu je potřeba vytvořit SLA schéma a přiřadit dané schéma k poolu, ve kterém s ním chceme pracovat. Vytváření se provádí v administraci na záložce "SLA" přiřazení k poolu se provádí na kartě "SLA schémata" v editaci poolu (viz kapitola 3.7. Karta SLA schémata).

Obrázek 18.1. Konfigurace SLA časů

Konfigurace SLA časů

V konfiguraci SLA znamenají časy "Od" a "Do" dobu, kdy se počítá daný SLA čas. Je to vlastně pracovní doba, kdy se řeší dané tasky. Pro každou prioritu je možné nastavit vlastní časy. Dále je možné definovat svátky, které se zahrnují do nepracovních dní pro všechny priority, ty se nastavují na dolním konci konfiguračního formuláře. Podle nastavení na předchozím obrázku se bude pro task s prioritou "1" počítat SLA čas od pondělí do pátku vždy od 8:00 do 20:00, RT bude 4 hodiny a FT bude 8 hodin. To znamená, že task musí být převzat do 4 hodin a do 8 hodin musí být task vyřešen. Vše počítáno v pracovní době.

Pokud je task zadán v pracovní době, nic se nemění. Např. pokud zadáme task s prioritou 1 v pondělí v 8:00, tak musí být task převzat v 12:00 a v 16:00 musí být task vyřešen. Pokud je task zadán před pracovní dobou nebo v nepracovní den, výchozí čas se nastaví na začátek pracovní doby na nejbližší další (současný) pracovní den. Pokud tedy v tomto případě zadáme task v neděli ve 22:00, tak se jako začátek nastaví pondělí 8:00 a jednotlivé časy budou stejné, jako kdybychom zadali task v pondělí v 8:00. To vše za předpokladu, že toto pondělí není definováno jako svátek. Kdyby bylo, tak se jako začátek nastaví úterý 8:00. Mimo nastavenou pracovní dobu se časy neodečítají.

U každého schématu lze nastavit možnost, zda se po vrácení tasku k přepracování znovu zapne SLA a zda se při stavech Čeká na informaci a Nové podmínky SLA výpočet pozastaví.

SLA výpočet může být výpočetně náročná operace, proto pro optimalizaci výkonu serveru je možné nastavit periodu výpočtu (od 1 min. výše - výchozí hodnota je 5 min.)

POZN.: Pro každou prioritu musí být nastaven minimálně jeden pracovní den.

Uživatelský pohled

Zapnuté SLA poznáme odlišným zobrazením sloupce "Termín" na pracovišti. Zatímco klasický deadline zobrazuje pouze počet dní do vypršení a datum vypršení, SLA zobrazuje dva zmíněné časy.

Obrázek 18.2. Zobrazení bez aktivního SLA

Zobrazení bez aktivního SLA

Obrázek 18.3. Zobrazení s aktivním SLA

Zobrazení s aktivním SLA

Při zapnutém SLA značí "R" pro ReactionTime a "F" je FixTime.

Platí následující pravidla:

  • Po překročení limitu daný čas přejde do záporu a zčervená.

  • RT je při zadání tasku napsán černou barvou, při převzetí tasku zešedne a přestane se odečítat.

  • FT se přestane odečítat v momentě dokončení tasku.

Automatický vs. manuální FixTime

Rozlišujeme dva typy FT:

  1. Automatický – ten, který se tasku při založení tasku stanoví podle definovaného SLA schématu.

  2. Manuální – při editaci tasku můžeme zadat vlastní FT, např. při nepříznivém vývoji tasku. Nejprve je třeba upravit požadavek a v něm ručně upravit Termín (pokud na to má uživatel práva).

Tento manuální FT je možné změnit zpět na automatický. Opět musíme potvrdit dialog, že chceme upravit FT. Poté se pod kolonkou "Nové podmínky" zobrazí tlačítko "Spočítat dle SLA", které nastaví FT na původní hodnotu.

Změna SLA schématu

Pokud existují již zadané tasky podle některého SLA schématu a toto schéma se rozhodneme změnit, máme několik možností. Při ukládání editovaného SLA schématu se TaskPool zeptá na další postup:

Obrázek 18.4. Přepočet manuálních časů podle SLA

Přepočet manuálních časů podle SLA

Jednak máme možnost nastavit, zda chceme podle nového schématu přepočítat tasky, které mají nastaven automatický FT podle původního SLA schématu. Ohledně tasků, které mají manuální FT máme tři možnosti:

  1. Nic nepřepočítávat.

  2. U všech nastavit automatický FT podle nového SLA schématu.

  3. Můžeme nastavit datum zadání tasku a FT se přepočítá pouze u tasků zadaných po tomto datu.

Kapitola 19. Znalostní báze

Znalostní báze je místo pro uchování již vyřešených požadavků, popř. často kladených dotazů, různých návodů apod. Jeden příspěvek ve znalostní bázi představuje jeden task. Obsah znalostní báze může tvořit řešitelská strana TaskPoolu. Samotná znalostní báze je pak přístupná jak zvenčí (podobně jako Helpdesk), tak zevnitř. Na řešitelské straně je možné použít některý z tasků ve znalostní bázi jako odpověď zadavateli na jeho požadavek.

Z tasku se do znalostní báze ukládá vždy předmět tasku a jeho popis. Předmět slouží jako název dotazu, popis jako řešení. Ostatní hodnoty tasku je také možné zadat, ty se však ve znalostní bázi nezobrazují. Historie daného tasku se taktéž nevypisuje. Konfigurace probíhá v administraci na kartě "Znalostní báze".

Obrázek 19.1. Konfigurace znalostní báze

Konfigurace znalostní báze

Pole podmínka funguje podobně jako u filtrů a slouží k definici, které tasky do znalostní báze zahrnout. Typické podmínky jsou např. tyto:

  • task.poolId=5 - znalostní báze bude obsahovat všechny tasky z poolu s id=5

  • task.dynamicFields.zverejnit='on' - všechny tasky, které mají aktivní dynamické pole typu checkbox s identifikátorem 'zverejnit'

Podmínku lze uvést libovolnou, stejně jako ve filtrech/notifikacích/eskalacích, doporučujeme však mít pro znalostní bázi vyčleněn speciální pool. U dynamického pole v podmínce je třeba nastavit oprávnění pro zobrazení zadavateli.

Matice checkboxů určuje právo jednotlivých rolí pro použití předdefinovaných odpovědí ze znalostní báze při odpovědích na tasky. Oprávněným rolím se v povolených poolech nad polem pro komentář zobrazí tlačítko Odpověď, po jehož rozkliknutí se zobrazí seznam všech dotazů ve znalostní bázi a jedním klikem lze potom některý z nich vložit jako odpověď.

Obrázek 19.2. Použití znalostní báze v TaskPoolu

Použití znalostní báze v TaskPoolu

Odkaz na znalostní bázi přístupnou zvenčí najdeme na konfiguračním formuláři a zobrazí se až po uložení konfigurace. Layout konfigurujeme v jazyce XSL a je plně skinovatelný, podobně jako helpdeskové rozhraní. Odkaz na znalostní bázi je možné umístit např. do hlavičky stránky s Helpdeskem. Do záložek "Přehled tasků" a "Úprava tasku" se vkládají jednotlivé XSL kódy pro zobrazení dané stránky.

Podobně jako pro Helpdesk, tak i pro znalostní bázi jsou k dispozici vzorové kódy. Ty najdeme zde:

..\ROOT\WEB-INF\tools\KB\prehled.xsl

..\ROOT\WEB-INF\tools\KB\detail.xsl

Najdeme zde vzorové kódy pro přehled požadavků i pro detailní náhled, kódy stačí vložit do konfiguračního formuláře znalostní báze.

Zobrazení Znalostní báze je přístupné bez přihlášení do TaskPoolu i Helpdesku, může tedy sloužit buď samostaně nebo jako doplněk helpdeskového rozhraní.

Kapitola 20. External Database Manager

Modul External Database Manager (EDM) slouží pro pohodlnou správu externích databází. Můžeme tak z prostředí TaskPoolu spravovat např. databázi zákazníků, firemních zařízení apod., možnostem využití se meze nekladou. Ke zprovoznění EDM je potřeba instalační balíček, který vám pracovníci Comarr, spol s.r.o. na požádání rádi dodají. Modul je dále potřeba nakonfigurovat. Poté se oprávněným uživatelům zobrazí na pracovišti ikona, jejíž stisk je dostane přímo do EDM.

Obrázek 20.1. Ikona pro přístup do EDM

Ikona pro přístup do EDM

Uživatelský pohled

EDM je možné nakonfigurovat pouze nad jednou databází zároveň, počet tabulek omezen není. Zároveň lze použít více .xml souborů pro více EDM. Základní EDM vypadá zhruba takto:

Obrázek 20.2. External Database Manager

External Database Manager

V našem příkladu používáme dvě tabulky, jednu pro firmy a další pro jednotlivé kontakty. Každý kontakt náleží do jedné z firem.

V přehledu vidíme všechny záznamy v dané tabulce. Nový záznam vytvoříme kliknutím na tlačítko + Company, úpravu již vytvořeného záznamu vyvoláme kliknutím na libovolnou položku daného záznamu. Názvy tlačítek lze definovat v konfigurace EDM.

Konfigurace EDM

Nejprve je potřeba rozbalit zdrojový kód EDM do adresáře Tomcatu "vedle" TaskPoolu. Tedy pokud se soubory TaskPoolu nachází např. v adresáři ..\Tomcat 8.0\webapps\ROOT , soubory EDM rozbalíme do adresáře ..\Tomcat 8.0\webapps\ExternalDatabaseManager\ .

Dále je potřeba do složky ..\ROOT\logos\customer_1\ vytvořit podsložku ..\ROOT\logos\customer_1\externalDatabaseManager\ , do které umístíme konfigurační soubor EDM s názvem applicationXml.xml.

Podobně jako u konfigurace ověření a Helpdesk, i zde se nabízí možnost rychlého zprovoznění EDM pomocí vzorové konfigurace. Tu lze použít v případě, že jsme použili vzorovou databázi pro ověření (viz kapitola 16.3. Použití vzorové databáze. V tom případě stačí zkopírovat konfigurační soubor:

..\ROOT\WEB-INF\tools\edm\applicationXml.xml

do tohoto adresáře:

..\ROOT\logos\customer_1\externalDatabaseManager\

V konfiguračním souboru pak již nastavíme pouze přístup k databázi a oprávnění pro jednotlivé uživatele. Kompletní konfiguraci tohoto souboru je věnována následující podkapitola.

Soubor applicationXml.xml

Pro správnou funkci EDM je třeba mít správně nakonfigurován soubor applicationXml.xml.

<Application>
    <!-- název zobrazovaný v záhlaví stránky -->
    <Name>EDM</Name>
    <!-- verze zápisu, při každé změně v souboru je třeba verzi navýšit o 1,
         aby TaskPool poznal, že v souboru došlo ke změně -->
    <Version>1</Version>
    <!-- login uživatele, která má mít přístup do EDM -->
    <Access>
        <User>
            <Username>admin</Username>
        </User>
        <!-- volitelně lze umožnit přístup do EDM více uživatelům
             tímto způsobem -->
        <User>
            <Username>login2</Username>
        </User>
    </Access>
    <!-- URL pro připojení k databázi EDM, nikoliv db TaskPoolu!
         Příklad pro MySQL -->
    <Database>
        <URL>jdbc:mysql://localhost:3306/nazevDatabaze?
             characterEncoding=utf8</URL>
        <Username>login</Username>
        <Password>heslo</Password>
    </Database>
    <ManagerUrl>
        <!-- URL umístění EDM pro komunikace mezi EDM a TaskPoolem -->
        <CommunicationUrl>http://www.taskpool.net/ExternalDatabaseManager/
          </CommunicationUrl>
        <!-- URL umístění EDM pro webový prohlížeč -->
        <BrowserUrl>http://www.taskpool.net/ExternalDatabaseManager/
          </BrowserUrl>
        <!-- URL TaskPoolu -->
        <TaskPoolUrl>http://www.taskpool.net/</TaskPoolUrl>
		<!--  id ověření (pokud je vyplněno, není nutno výše definovat Database -->
	    <TaskPoolAuthId>2</TaskPoolAuthId>
    </ManagerUrl>

    <!-- Pokud jsme použili vzorovou databázi, zde je možné konfiguraci
         ukončit. V následující části konfigurujeme konkrétní tabulky
         a sloupečky v databázi. -->

    <Objects>
        <Object>
            <!-- název tabulky v databázi -->
            <Name>company</Name>
            <Legends>
                <!-- název, který se bude zobrazovat v přehledu tabulek -->
                <Overview>Companies</Overview>
                <!-- název, který se bude zobrazovat v detailním zobrazení
                     jednoho záznamu -->
                <Detail>Company</Detail>
            </Legends>
            <!-- popis, který se bude zobrazovat jako backreference
                 a reference, více níže -->
            <Label>{id} - {name}</Label>
            <!-- definice každého property odpovídá jednomu sloupečku
                 v tabulce -->
            <Properties>
                <Property>
                    <!-- název sloupce v databázi -->
                    <Name>id</Name>
                    <!-- název, který se bude zobrazovat v EDM -->
                    <Legend>ID</Legend>
                    <!-- pokud je true, hodnota se bude zobrazovat v seznamu
                         položek tabulky, pokud je false, bude se zobrazovat
                         pouze v detailním zobrazení jednotlivé položky -->
                    <ShowInOverview>true</ShowInOverview>
                    <!-- true pokud je hodnota generována automaticky a není
                         možné ji změnit, tento element je nepovinný -->
                    <Generated>true</Generated>
                </Property>
                <Property>
                    <Name>name</Name>
                    <Legend>Name</Legend>
                    <ShowInOverview>true</ShowInOverview>
                </Property>
            </Properties>
            <BackReferences>
                <BackReference>
                    <Name>contact</Name>
                    <Property>companyId</Property>
                    <Legend>Contacts</Legend>
                </BackReference>
            </BackReferences>
        </Object>

        <Object>
            <Name>contact</Name>
            <Legends>
                <Overview>Contacts</Overview>
                <Detail>Contact</Detail>
            </Legends>
            <Label>{id} - {firstname} {lastname}</Label>
            <Properties>
                <Property>
                    <Name>id</Name>
                    <Legend>ID</Legend>
                    <ShowInOverview>true</ShowInOverview>
                    <Generated>true</Generated>
                </Property>
                <Property>
                    <Name>username</Name>
                    <Legend>Username</Legend>
                    <ShowInOverview>true</ShowInOverview>
                </Property>
                <Property>
                    <Name>password</Name>
                    <Legend>Password</Legend>
                    <ShowInOverview>false</ShowInOverview>
                </Property>
                <Property>
                    <Name>firstname</Name>
                    <Legend>Firstname</Legend>
                    <ShowInOverview>true</ShowInOverview>
                </Property>
                <Property>
                    <Name>lastname</Name>
                    <Legend>Lastname</Legend>
                    <ShowInOverview>true</ShowInOverview>
                </Property>
                <Reference>
                    <Name>companyId</Name>
                    <Legend>Company</Legend>
                    <ShowInOverview>true</ShowInOverview>
                </Reference>
                <Property>
                    <Name>email</Name>
                    <Legend>Email</Legend>
                    <ShowInOverview>true</ShowInOverview>
                </Property>
                <Property>
                    <Name>phone</Name>
                    <Legend>Phone</Legend>
                    <ShowInOverview>true</ShowInOverview>
                </Property>
                <Property>
                    <Name>note</Name>
                    <Legend>Note</Legend>
                    <ShowInOverview>false</ShowInOverview>
                </Property>
                <Property>
                    <Name>isManager</Name>
                    <Legend>Manager</Legend>
                    <ShowInOverview>true</ShowInOverview>
                    <Html type="1">
                        <Options>
                            <Option value="1">Yes</Option>
                            <Option value="0">No</Option>
                        </Options>
                    </Html>
                </Property>
                <Property>
                    <Name>isActive</Name>
                    <Legend>Active</Legend>
                    <ShowInOverview>true</ShowInOverview>
                    <Html type="1">
                        <Options>
                            <Option value="1">Yes</Option>
                            <Option value="0">No</Option>
                        </Options>
                    </Html>
                </Property>
            </Properties>
            <BackReferences/>
        </Object>
    </Objects>
</Application>

Sloupec tabulky často zobrazuje cizí klíč jiné tabulky. Pokud chceme zobrazit hodnotu z této tabulky a ne jen ID hodnoty, použijeme místo <Property> element <Reference>.

<Object>
	<Name>lokalita</Name>
	<Legends>
		<Overview>Lokality</Overview>
		<Detail>Lokalita</Detail>
	</Legends>
	<Label>{id}- {nazev}</Label>
    <Properties>
        <Property>
            <Name>id</Name>
            <Legend>Lokalita</Legeng>
            <ShowInOverview>true</ShowInOverview>
        </Property>
</Object>

V případě, že se chceme odkazovat na předchozí záznam, použijeme element <Reference> následovně:

<Reference>
    <Name>lokalita</Name>
    <Legend>Lokalita</Legend>
</Reference>

Potom se bude místo hodnoty "ID" zobrazovat "ID - název". Dále při úpravě záznamu se bude v detailním zobrazení místo textového pole zobrazovat selectbox, který zobrazí hodnoty z tabulky "Lokalita". Musí být ale definované cizí klíče, tedy vytvořená vazba mezi tabulkami.

Dále si představme tabulku "contact" obsahující cizí klíče z tabulky "company". Jedna firma tedy může mít více přiřazených uživatelů. Pokud chceme v detailu hodnoty firmy zobrazovat všechny záznamy uživatelů, které obsahují cizí klíč (id_contact), použijeme element <Backreference>. Obsah elementu <Name> určuje název objektu, <Property> název property z objektu, který je již v EDM obsažen a <Legend> název zobrazovaný v EDM. Element <Backreference> se přidává za element <Properties>.

<Backreferences>
    <Backreference>
        <Name>contact</Name>
        <Property>id_contact</Property>
        <Legend>Uživatel</Legend>
    </Backreference>
    <Backreference>
        <!-- další záznam -->
    </Backreference>
</Backreferences>

Pokud chceme v přehledu zobrazit jinou hodnotu, než je uložená v databázi, použijeme vlastnost <Options>.

<Property>
	<Name>id</Name>
	<Legend>ID</Legend>
	<ShowInOverview>true</ShowInOverview>
	<Html type="1">
        <Options>
            <Option value="1">Hodnota 1</Option>
            <Option value="2">Hodnota 2</Option>
            <Option value="3">Hodnota 3</Option>
        </Options>
    </Html>
</Property>

Normálně by se v položce tabulky zobrazovala hodnota "ID", nyní se však bude zobrazovat Hodnota 1, Hodnota 2, Hodnota 3. V detailu záznamu se bude zobrazovat selectbox, namísto textového pole.

Od verze EDM 1.145 je možné sledovat přístupy a změny v databázi EDM pomocí logu. Ten se ukládá do ./WEB-INF/logs/.

Kapitola 21. Evidence nákladů

Evidence nákladů je modul pro sledování odpracovaných časů jednotlivých uživatelů. Umožňuje nadefinovat jednotlivé činnosti a skupiny činností, ke kterým pak budou uživatelé vykazovat odpracované časy. Konfiguraci tohoto modulu najdeme v administraci na kartě "Evidence nákladů".

Obrázek 21.1. Administrace: Evidence nákladů

Administrace: Evidence nákladů

Je možné vytvořit libovolný počet činností a ty pak přiřazovat do skupin činností. Nastavení práv pro zapisování do určité skupiny činností se provádí pro každou roli zvlášť a každá role může mít právo maximálně pro jednu skupinu činností. Nastavení práv je popsáno v kapitole 3.10. Karta Evidence nákladů. Např. servisní manažeři tak mohou vykazovat časy pouze v určité skupině činností a řešitelé zase v jiné. Pro jednotlivé činnosti ale neexistují žádná omezení, takže určitá činnost může být členem několika skupin činností zároveň. V našem příkladu máme dvě skupiny činností, a to "Customer support" a "Developement".

skupina činnostípřiřazené činnosti
Customer supportinstalace, konfigurace, školení, dokumentace
Developementanalýza, vývoj, testování, dokumentace

Vidíme, že činnost "dokumentace" je součástí skupiny činností "Customer support" i "Developement". Přiřazení činností do jednotlivých skupin probíhá podobně, jako např. přiřazení uživatelů do poolu. Po kliknutí na vytvořenou skupinu činností se zobrazí tento formulář:

Obrázek 21.2. Přiřazení jednotlivých činností do skupin činností

Přiřazení jednotlivých činností do skupin činností

Pomocí šipek můžeme označené činnosti přesouvat mezi přiřazenými a nepřiřazenými činnostmi dané skupiny činností.

Zamykání záznamů času

Zamčený záznam nemůže být editován žádným uživatelem. Právo zamykání má defaultně pouze administrátor, ale může ho přidělit i ostatním uživatelům pomocí tlačítka Upravit nastavení na kartě "Evidence nákladů". Zobrazí se tento formulář:

Obrázek 21.3. Obecné nastavení evidence nákladů

Obecné nastavení evidence nákladů

Pokud jsou záznamy zamčeny do 1.1.2019 jak vidíme na obrázku, lze upravovat pouze záznamy novější tohoto data, starší záznamy již nebude možné měnit.

Pro zamknutí stačí nastavit datum, do kterého budou záznamy zamčeny a nastavení uložit. Z tohoto místa je také možné záznamy času exportovat do externího souboru, více v následující podkapitole. Export bude popsán v následující podkapitole.

Exportování záznamů času

V TaskPoolu má každý uživatel možnost exportovat svoje záznamy času, postup je popsán v uživatelském manuálu v kapitole 3.6. Export záznamů času.

Vyúčtování

Funkce Vyúčtování nabízí rychlý a jednoduchý způsob, jak vybrat konkrétní záznamy času a exportovat je do externího souboru či připravit k tisku, např. jako podklad pro fakturu. Funkce není primárně tvořena přímo pro fakturaci, doporučujeme ji používat pro export záznamů času do jiných systémů popř. pro tvorbu dodacích listů. Výhodou této funkce je možnost účtování záznamů času z ještě nedokončených tasků.

POZN.: Právo pro tvorbu vyúčtování má každý uživatel, který má právo na zamykání záznamů času.

Kliknutím na tlačítko Vyúčtování v menu "Jiné akce" na pracovišti se dostaneme do obrazovky pro tvorbu a editaci jednotlivých vyúčtování. Doporučujeme tvořit pro každý projekt samostatné vyúčtování.

Obrázek 21.4. Seznam vyúčtování

Seznam vyúčtování

Formulář pro tvorbu nového vyúčtování provedeme pomocí tlačítka Nový v menu v levé části obrazovky. Kdykoliv vyúčtování některý z uživatelů edituje, v té chvíli se dané vyúčtování ostatním uživatelům uzamkne a aktuálně editující uživatel je zobrazen ve sloupečku "Zamčeno uživatelem". Po ukončení editace daným uživatelem tato informace zmizí. Křížek slouží k manuálnímu zrušení v případě, že editující uživatel z nějakého důvodu nedokončil editaci.

Obrázek 21.5. Zamknuté vyúčtování

Zamknuté vyúčtování

Samotná tvorba vyúčtování probíhá následovně:

Obrázek 21.6. Nové vyúčtování

Nové vyúčtování

Na úvodní obrazovce vyplnímě Číslo a Název vyúčtování (oba údaje lze dodatečně změnit). Po otevření vyúčtování začneme vybírat konkrétní záznamy času, které budou do vytvářeného vyúčtování zahrnuty.

V seznamu jsou defaultně nabízeny veškeré záznamy času z celé databáze, které má uživatel právo vidět. Pomocí filtrů v horní části obrazovky můžeme jejich výběr upřesnit. Poté stačí zatrhnout ty záznamy, které mají být v daném vyúčtování obsaženy. Výběr potvrdíme tlačítkem Uložit.

POZN.: Platí pravidlo, že každý záznam času může náležet pouze do jednoho vyúčtování. Z tohoto důvodu doporučujeme vytvořit alespoň jedno vyúčtování pro interní výkony, které se neúčtují zákazníkovi. Díky tomu nebudou překážet v seznamu záznamů při tvorbě dalšího vyúčtování pro zákazníka.

Obrázek 21.7. Tvorba vyúčtování

Tvorba vyúčtování

Dokud ponecháme dané vyúčtování otevřené, můžeme v něm nadále provádět změny. Po uzavření již není možné vyúčtování editovat. K dispozici je také třetí stav "Zrušeno". Ten použijeme tam, kde dané vyúčtování z nějakého důvodu ztratilo smysl. Výhodou přepnutí do tohoto stavu je fakt, že veškeré záznamy času v něm obsažené se rázem stanou volné pro ostatní vyúčtování.

POZOR! Zrušení vyúčtování je nevratná akce!

Každé vyúčtování můžeme exportovat pomocí tlačítka Tisk v přehledu vyúčtování. K dispozici je standardní šablona "Vyúčtování", která připraví záznamy pro tisk. Je možné použít i jiné šablony, např. pro zmíněný export do jiných systémů apod., problematika exportních šablon je popsána v administrátorském manuálu v kapitole 12. Šablony. Při použití standardní šablony dostaneme zhruba tento výsledek:

Obrázek 21.8. Tisková šablona vyúčtování

Tisková šablona vyúčtování

Pokud se v seznamu pro tisk zobrazuje více šablon, o školení k nim požádejte svého administrátora.

Kapitola 22. SMS modul

SMS je rozšiřující modul systému TaskPool, který umožňuje mimo posílání notifikačních e-mailů zasílat také SMS zprávy.

Pro zprovoznění modulu je třeba vytvořit účet a nabít kredit u služby https://smsbrana.cz/. Následně na tomto účtu Nastavení účtu / SMS Connect aktivovat.

Dále je třeba importovat knihovnu a konfigurační soubor (oba soubory jsou součástí instalačního balíčku WEB-INF/tools).

Knihovna modulu PluginSmsBrana.jar umístíme do složky ..\ROOT\WEB-INF\lib\

Konfigurační soubor PluginSmsBrana.properties SMS modulu do složky ..\ROOT\WEB-INF\ a upravit login a heslo z SMS Connect.

Po restartování Tomcatu (pro aktivaci SMS modulu) je třeba vytvořit dynamické pole typu "Textfield", které aktivujeme pro uživatele v záložce Dynamická pole uživatelů kliknutím na Použít .

Obrázek 22.1. Nastavení dynamického pole řešitelům

Nastavení dynamického pole řešitelům

U tohoto pole si každý uživatel ve svém profilu může vyplnit telefonní číslo pro zasílání SMS, v tomto případě u pole SMS číslo.

Obrázek 22.2. Doplnění čísla pro zasílané sms

Doplnění čísla pro zasílané sms

Dále je nutné SMS modul aktivovat v záložce Administrace / SMS a povolit dynamické pole pro zasílání SMS.

Obrázek 22.3. Aktivace SMS modulu

Aktivace SMS modulu

Na závěr je třeba vytvořit notifikaci, která bude sms zasílat podle zadaných podmínek.

Obrázek 22.4. Příklad konfigurace notifikace pro zasílání SMS

Příklad konfigurace notifikace pro zasílání SMS

Pole komu obsahuje ID řešitele a příznak .sms, například 254.sms. Lze také použít všechny role implementers.sms pro zaslání sms všem řešitelům.

Typ zprávy vyberte sms.

Kapitola 23. TaskPool instance

Záložka TaskPool instance slouží k provázání systému s dalšími instancemi. Například pokud Vy i Váš zákazník máte samostatnou instanci systému TaskPool, můžete je provázat a umožnit tak exportovat tasky mezi těmito dvěma a více instancemi.

Obrázek 23.1. Nastavení propojení instancí

Nastavení propojení instancí

U každého propojení je třeba specifikovat tyto parametry:

  • Název - libovolný název propojení

  • Identifikátor: unikátní označení propojení (např: prop01)

  • URL: je adresa, pod kterou přistupuje server, na kterém běží TaskPool, k cílové instanci (např.: https://demo.taskpool.net nebo 127.0.0.1:8084 apod.)

  • Klientské URL: je adresa, pod kterou ke vzdálené instanci přistupují klienti z prohlížeče (ve většině případů stejná jako URL výše)

  • Kód zákazníka, uživatel a heslo: přístupové údaje admina klientské instance

Zpřístupnění exportu a importu pro jednotlivé pooly se řídí nastavením workflow, viz 3.2 Karta Workflow.

Právo exportovat mají všichni řešitelé i servisní manažeři dle nastavení workflow danného poolu.

Kapitola 24. Stavy

Výchozí stavy tasků (Nový, Převzat, Dokončen ...) je možné v rámci této záložky měnit.

Obrázek 24.1. Nastavení vlastních názevů stavů a ikon

Nastavení vlastních názevů stavů a ikon

Volbou Změnit lze zadat vlastní název stavu a vložit přesný název ikony, kterou je třeba nejdříve nahrát mezi soubory (Administrace / Soubory).

Změna se promítne jak na Pracovišti, tak také v Zákaznickém rozhraní.

---------------------------------------

(c) Copyright 2020 ComArr, spol. s r.o.