3. PREDSTAVITEV KONKRETNEGA PODJETJA S POSNETKOM PROCESOV IN PODATKOV
4.3.6 Varnost
Varnost je v aplikaciji eden pomembnejših faktorjev. Ko govorimo o varnosti, s tem mislimo na uporabnike in njihove dostope do posameznih komponent, modulov in podatkov v aplikaciji. Varnost preprečuje, da bi neavtorizirani uporabniki dostopali do podatkov, do katerih nimajo dostopa.
Slika 58: Gnezdenje RadTreeView v RadComboBox
V spletni aplikaciji za vodenje sestankov za varnost uporabljamo uporabnike in avtorizacije. Vsak uporabnik mora imeti za prijavo uporabniško ime in geslo. Uporabniki so enaki kot tisti, ki se uporabljajo za prijavo v Pantheon. Gesla pa so različna. Pantheon gesel nima shranjenih v podatkovni zbirki, ampak za prijavo uporabljajo kar SQL uporabnike. To pomeni, da se za dostop do podatkovne zbirke uporablja isti uporabnik, kot za dostop do Pantheona. V naši aplikaciji bi lahko uporabili isto metodo, vendar Pantheon gesla za dostop do podatkovne zbirke kodira s posebnim ključem, do katerega iz naše aplikacije nimamo dostopa. Pantheon pa ima za potrebe vertikalnih aplikacij pripravljeno polje v podatkovni zbirki, kjer se hrani geslo za prijavo uporabnika v vertikalne aplikacije. S tem dosegajo višjo varnost Pantheon aplikacije, saj v primeru razkritja gesla za dostop
Gregor Praprotnik: Razvoj rešitve za vodenje sestankov stran 57
do vertikalne aplikacije napadalec še vedno ne more dostopati do Pantheona. V spletni aplikaciji za vodenje sestankov se za hranjenje gesla posluţujemo omenjenega polja.
Avtorizacije in povezave med uporabniki in avtorizacijami shranjujemo v isto tabelo kot Pantheon. Več o strukturi podatkovne zbirke za potrebe varnosti smo si ogledali ţe v točki 4.2.2 (Podatkovna zbirka). Avtorizacije se uporabnikom dodeljujejo dinamično ob določenih akcijah (nov sestanek) brez posebnega vmesnika. Preko Pantheona pa je uporabnike mogoče dodajati v posamezne vloge tudi direktno.
Vloge oziroma avtorizacije so shranjene v posebni strukturi: OIC_COM (avtorizacije se nanašajo na COM aplikacijo),
_App_Admin (skrbnik), _App_User (uporabnik), _[MeetingID] (ID sestanka),
_* (naziv avtorizacije).
Uporaba takšne strukture nam omogoča večjo preglednost vlog po nivojih (nadrejeni in podrejeni). OIC_COM_App_Admin in OIC_COM_App_User sta osnovni avtorizaciji, ki uporabnikom omogočata vstop v spletno aplikacijo. Vloge OIC_COM_[MeetingID]_[Avtorizacija] pa uporabnikom natančneje določajo dostop in obliko dostopa do posameznih podatkov. V nadaljevanju si bomo podrobneje ogledali posamezne vloge.
Preverjanje avtorizacije v spletni aplikaciji za vodenje sestankov izvajamo v dveh nivojih. Prvi nivo se preverja preko sitemap.xml datoteke. Na tem nivoju se preverja zgolj uporabnikov dostop do posameznega vmesnika in prikaz menija. Tabela 7 navaja vloge, ki se preverjajo na tem nivoju. Uporabnik mora biti v eni od navedenih vlog, da se sploh lahko prijavi v aplikacijo.
Tabela 7: Avtorizacije na nivoju sitemap.xml
Avtorizacija Opis
User Uporabnik.
Dostop do strani, ki omogočajo delo z sestanki.
Admin Administrator.
Poleg dostopa, ki ga ima User ima Admin še dostop do nastavitev. Admin ima polni dostop do vseh podatkov, ne glede na omejitve na niţjem nivoju preverjanja.
Natančnejše preverjanje dostopa do posameznih podatkov izvajamo preko programske logike na posameznem vmesniku. Uporabniku se te vloge dodeljujejo dinamično. Ob kreiranju novega sestanka se ustvarijo nove vloge, ki veljajo samo na tem sestanku. Ko je uporabnik dodan med člane sestanka, se mu s tem dodeli tudi pripadajoča vloga. Enako vloge dodajamo za poročevalce na točki dnevnega reda in nosilce sklepov. Tabela 8 prikazuje vloge, ki obstajajo na tem nivoju.
Gregor Praprotnik: Razvoj rešitve za vodenje sestankov stran 58 Tabela 8: Avtorizacije na nivoju sestanka
Avtorizacija Opis
Leader Vodja sestanka.
Polni dostop na nivoju enega sestanka.
Member Član sestanka
Samo bralni dostop za vse podatke sestanka (brez urejanja). Dostop da stanja lastne udeležbe na sestanku.
Dotstop do stanja lastne potrditve zapisnika, če se potrditve od člana zahteva.
Dostop do gradiva sestanka. Gradiva ne more brisati, lahko ga le dodaja.
Nima dostopa do vpogleda v poročila izvajalcev opravil.
Agenda Item Leader Odgovorni za posamezno točko dnevnega reda
Dostop do podatkov točke dnevnega reda. Dostop do podatkov sklepov točke dnevnega reda. Dotop do poročil nosilcev sklepa.
Task Leader Odgovorni nosilec posameznega opravila
Dostop do poročil nosilcev tega sklepa.
Zaradi enostavnejše in preglednejše uporabe avtorizacij s strani programerja smo za osnovne CRUD metode sestavili ovoj (wrapper). Metode, ki jih ovoj vsebuje, omogočajo hitrejše delo z avtorizacijami. Programerju načeloma nikoli ni potrebno klicati CRUD metod, ampak do njih vedno dostopa preko ovoja. Tabela 9 prikazuje nekatere metode, ki jih vsebuje ovoj.
Z izvedbo varnosti smo ţeleli zagotoviti fleksibilnost in v največji meri uporabiti Pantheon strukturo. Uporabnikov ni potrebno ustvarjati na novo, saj so ustvarjeni ţe za uporabo Pantheona. Z avtorizacijami pa smo omogočili, da se posameznim uporabnikom preko Pantheona enostavno lahko omogoči dostop do posameznih podatkov ne glede na dejansko vlogo, ki jo ima uporabnik na sestanku.
4.3.7 Konfiguracija
MS .Net Framework za konfiguracijo spletnih aplikacij in spletnih strani uporablja konfiguracijsko datoteko web.config. V bistvu je to XML datoteka, ki omogoča nastavljanje različnih funkcij od načina avtentikacije, beleţenja dnevnika, povezave na podatkovno zbriko do uvaţanja knjiţnic in nastavljanja obravnave napak.
Aplikacija za vodenje sestankov temelji na .Net ogrodju, zato prav tako uporablja web.config konfiguracijsko datoteko. V tej datoteki shranjujemo razne nastavitve, ki so splošne za vse namestitve in uporabnike. Shranjujemo pa tudi nekaj nastavitev, ki so specifične za posameznega uporabnika. To so nastavitve povezave na podatkovno zbirko, nastavitve poštnega streţnika in licenčni podatki. Zaradi teh nastavitev se je pojavil problem nadgradnje web.config datoteke v prihodnjih različicah aplikacije. V kolikor so nastavitve shranjene v web.config datoteki in nova različica aplikacije vsebuje tudi novo web.config datoteko, bo stara
Gregor Praprotnik: Razvoj rešitve za vodenje sestankov stran 59
datoteka prepisana z novo, s tem pa se bodo prepisale tudi shranjene nastavitve. Uporabnik bi lahko ponovno vnesel podatke, vendar to predstavlja slabo uporabniško izkušnjo.
Tabela 9: Metode, ki jih vsebuje ovoj za CRUD metode, povezane z avtorizacijami
Akcija Funkcija Dejanje
Nov sestanek MeetingRoleInit() Inicializacija avtorizacij za sestanek.
Metoda kreira nove vloge za sestanek.
Izbris sestanka DeleteMeeting RoleTree()
Izbris vseh vlog sestanka. Ob brisanju sestanka izbrišemo tudi pripadajoče vloge.
Nova vloga uporabnika na sestanku
AddMeetingUserRole() Dodelitev vloge uporabniku za podani sestanek.
Izbris vloge uporabnika na sestanku
DeleteMeeting UserRole()
Odstranitev uporabnikove vloge.
Nova agenda AgendaRoleInit() Inicializacija avtorizacij za točko dnevnega reda.
Metoda kreira nove vloge za točko dnevnega reda.
Izbris agende DeleteAgenda RoleTree()
Izbris vseh vlog točke dnevnega reda.
Ob brisanju točke dnevnega reda izbrišemo tudi pripadajoče vloge.
Nova vloga uporabnika na agendi
AddAgendaUserRole() Dodelitev vloge uporabniku. Izbris vloge uporabnika na
agendi
DeleteAgenda UserRole()
Odstranitev uporabnikove vloge.
Seznam vlog uporabnika na sestanku
ListMeetingUserRole() Naloţi seznam vlog uporabnika za sestanek. Preverjanje vloge IsInRole() Preverjanje uporabnikovega
dostopa.
Za rešitev tega problema smo uporabili ločene konfiguracijske datoteke, na katere se navezuje osnovna web.config datoteka. Ločenih konfiguracijskih datotek pri nadgradnji nikoli ne nadomestimo, medtem ko nadomeščanje web.config datoteke ne povzroča izgube nastavitev.
Gregor Praprotnik: Razvoj rešitve za vodenje sestankov stran 60
Na sliki 59 je prikazan primer web.config datoteke, ki vsebuje nastavitev povezave na podatkovno zbirko.
Vsebino connectionStrings oznak lahko prenesemo v zunanjo datoteko. Na mestu, kjer v sliki 59 navajamo podatke za povezavo, pa navedemo lokacijo zunanje datoteke, kakor je prikazano na sliki 60.
Slika 59: Nastavite povezave na podatkovno zbirko v web.config
Slika 60: Navajanje lokacije zunanje konfiguracijske datoteke
V ločenih konfiguracijskih datotekah lahko uporabimo samo po en odsek. Za vsak odsek moramo ustvariti svojo ločeno konfiguracijsko datoteko. V naši aplikaciji smo tako ustvarili tri zunanje konfiguracijske datoteke:
connectionString.config, mailSettings.config in appSettings.config.
4.3.8 Licenciranje
Piratstvo ni samo trn v peti filmske industrije ampak tudi programske. V tej točki si bomo pogledali, na kakšen način skušamo zmanjšati nelegalno kopiranje in nameščanje piratske verzije aplikacije za vodenje sestankov.
Popolnoma preprečiti nelegalno uporabo je skoraj nemogoče, vsaj če ţelimo ohraniti dobro uporabniško izkušnjo pri uporabi aplikacije. Verjamemo lahko, da tudi način preverjanja pristnosti aplikacije za vodenje sestankov ni popoln. Namen preverjanja je nelegalno kopiranje vsaj oteţiti, če ţe ne ravno preprečiti.
Pristnost kopije preverjamo z uporabo licenčnega ključa. Le ta je 60-mestni niz črk in številk, ki ga prejmemo ob nakupi aplikacije. Licenčni ključ je unikaten in je generiran za vsak nakup oziroma namestitev posebej. Aplikacija ob namestitvi od nas zahteva, da vnesemo licenčni ključ. Brez licenčnega ključa aplikacije ni mogoče uporabljati.
Za preverjanje veljavnosti licenčnega ključa se aplikacija za vodenje sestankov poveţe na spletni servis avtorja aplikacije, ki preveri ali je ključ veljaven. Shema je prikazana na sliki 61. Application host server je streţnik, na katerega nameščamo aplikacijo za vodenje sestankov. Preko interneta se vzpostavi povezava s streţnikom, ki gostuje »Licencing Service« oziroma spletni servis, ki preverja pristnost.
Spletni servis prejme licenčni ključ, za katerega preveri, ali je bil v preteklosti generiran in ali je ţe v uporabi. V kolikor ugotovi, da obstaja in da še ni bil uporabljen, odgovori, da je ključ pristen, v nasprotnem primeru odgovori, da ni pristen.
Gregor Praprotnik: Razvoj rešitve za vodenje sestankov stran 61
Internet
Licencing Service Application host
server
Slika 61: Shema preverjanja licenčnega ključa
V kolikor aplikacija pri aktivaciji prejme odgovor, da je ključ pristen, generira MachineKey (ključ računalnika). MachineKey je generiran na podlagi licenčnega ključa in MachineID (identifikacija računalnika), ki je sestavljen iz nekaterih podatkov o strojni opremi računalnika. MachineKey in licenčni ključ se zabeleţita v aplikacijo. S tem je aplikacija aktivirana in dopušča normalno uporabo.
Za preprečevanje kopiranja aplikacije, ko je ta ţe aktivirana, je vgrajen še dodaten mehanizem. Aplikacija ves čas generira MachineKey in ga primerja s shranjenim MachineKey, ki je bil generiran ob aktivaciji. V kolikor aplikacija ugotovi, da se ključa ne ujemata, se zablokira in zahteva vnos licenčnega ključa. V primeru, da bi aktivirano aplikacijo prestavili na drug računalnik, bi se spremenil MachineID, kar bi povzročilo spremembo MachineKeya in s tem blokado uporabe.
4.3.9 Kopiranje podatkov
Za enostavnejšo uporabo in hitrejše delo s sestanki aplikacija na nekaterih vmesnikih omogoča prenašanje podatkov. S prenašanjem podatkov dejansko mislimo na kopiranje zapisov v podatkovni zbirki. Eden od vmesnikov, ki omogoča prenos, je kreiranje sestanka iz predloge, ki je prikazan na sliki 62.
Kreiranje sestanka iz predloge omogoča nekaj nastavljanja o tem, kaj ţelimo prenesti preden pričnemo z dejanskim kopiranjem. Za kreiranje novega sestanka iz predloge moramo slediti naslednjim korakom:
Naloţimo podatke za izbrano predlogo.
V podatkih spremenimo parameter, s katerim označimimo, da je zapis predloga sestanka. Podatke shranimo v podatkovno zbirko kot nov zapis.
Izvedemo inicializacijo vlog za nov sestanek.
Uporabnika, ki je trenutno prijavljen in ustvarja nov sestanek, dodamo med člane sestanka kot vodjo.
Temu uporabniku dodelimo tudi ustrezne vloge.
Naslednje korake izvedemo samo, če smo izbrali, prenos članov: Naloţimo vse člane izbrane predloge.
Vse zapise shranimo v podatkovno zbirko za nov sestanek in pri tem pazimo, da noben od teh članov ni dodan kot vodja.
Vsem uporabnikom dodelimo tudi ustrezne vloge.
Naslednje korake izvedemo samo, če smo izbrali naj se prenesejo prejemniki: Naloţimo vse prejemnike izbrane predloge.
V kolikor nismo izbrali tudi prenosa članov, naloţimo vse člane in prejemnike. V nasprotnem primeru naloţimo le prejemnike.
Gregor Praprotnik: Razvoj rešitve za vodenje sestankov stran 62
Vse zapise shranimo v podatkovno zbirko za nov sestanek. V kolikor nismo prenesli članov, vse zapise shranimo kot prejemnike, sicer pa te lasnosti ne spreminjamo. Paziti moramo, da nihče ni prenešen kot vodja.
Vsem prejemnikom dodamo ustrezno vlogo.
Naslednje korake izvedemo samo, če smo izbrali prenos dnevnega reda: Naloţimo vse točke dnevnega reda za izbrano predlogo.
Zapise shranimo v podatkovno zbirko za nov sestanek. Pri tem moramo paziti na parent – child (nadrejen – podrejen) relacije med posameznimi točkami dnevnega reda. Pri zapisovanju podrejene točke dnevnega reda moramo vedeti, katera je nadrejena točka dnevnega reda na novem sestanku, kar pomeni, da moramo najprej zapisati nadrejene in potem podrejene zapise.
Za vsako točko dnevnega reda inicializiramo vloge.
Poročevalcu na točki dnevnega reda dodamo ustrezno vlogo.
Slika 62: Vmesnik za kreiranje sestanka iz predloge
Celotno kopiranje podatkov mora biti izvedeno v transakciji, da se izognemo nepopolnim kopijam v primeru napake ali okvare.
Drug vmesnik, ki omogoča kopiranje podatkov, je vmesnik za prenos sklepov iz drugega sestanka. Tudi ta vmesnik omogoča izbor nekaterih nastavitev, preden pričnemo s kopiranjem. Brez izbora nastavitev na trenutni sestanek prenesemo cel dnevni red vključno s sklepi iz izbranega sestanka. Z izborom naj se prenesejo samo nedokončani sklepi, prenesemo celoten dnevni red, a le nedokončane sklepe. Če izberemo te, naj za prenešene sklepe ustvari novo točko dnevnega reda, ne bomo prenašali dnevnega reda, ampak bomo vse sklepe izbranega sestanka prenesli v novo ustvarjeno točko dnevnega reda. V primeru, da izberemo obe moţnosti, naj se prenesejo samo nedokončani sklepi in naj se ustvari nova točka
Gregor Praprotnik: Razvoj rešitve za vodenje sestankov stran 63
dnevnega reda, nedokončane sklepe izbranega sestanka pa prenesemo v novo točko dnevnega reda.
Z besedami je teţko in nepregledno natančneje opisati postopek prenosa, zato je na sliki 63 podana shema, ki točneje definira posamezne korake prenosa.
Prenesi agendo / taske
OnlyUncompleted CreateNew
Naloţi le točke dnevnega reda, ki imajo
nedokončane taske (ParendID = null) yes no Vzemi zapis iz dobljenega seznama in shrani posamezen AgendaID za novi MeetingID (in ParentID
če obstaja)
Ali je trenutni zapis komu parent? yes
Naloţi le točke dnevnega reda, ki imajo
nedokončane taske (ParentID = stari
AgendaID)
Ali je v seznamu še kakšen neobdelan zapis? yes no Prenos končan no yes
Ustvari nov AgendaID za novi MeetingID Naloţi le nedokončane taske za (stari) AgendaID Vzemi zapis iz dobljenega sezanama in
naredi relacijo na novi AgendaID za posamezen TaskID
Ali je v seznamu še kakšen neobdelan task zapis?
yes
no
Naloţi vse nedokončane taske za stari MeetingID
Naredi relacijo za novi AgendaID in obstoječi
TaskID
Ali je v seznamu še kakšen neobdelan task zapis?
yes
no
CreateNew
Naloţi vse točke dnevnega reda za stari MeetingID. (ParendID = null) no Vzemi zapis iz dobljenega seznama in shrani posamezen AgendaID za novi MeetingID (in ParentID
če obstaja)
Ali je trenutni zapis Agenda komu
parent?
yes
Naloţi vse točke dnevnega reda (ParentID = stari AgendaID)
Ali je v seznamu še kakšen neobdelan
zapis?
no
ne
yes Ustvari nov AgendaID za novi MeetingID
Naloţi vse taske za (stari) AgendaID
Vzemi zapis iz dobljenega sezanama in
naredi relacijo na novi AgendaID za posamezen TaskID
Ali je v seznamu še kakšen neobdelan task zapis?
yes
ne
Naloţi vse taske za stari MeetingID
Naredi relacijo za novi AgendaID in obstoječi
TaskID
Ali je v seznamu še kakšen neobdelan task zapis? yes no no no
Slika 63: Postopek prenosa sklepov
4.3.10 Prenos datotek
Na sestankih ali za izvajanje sklepov sestanka večkrat potrebujemo določene dokumente ali druge vrste datotek. V ta namen modul File omogoča prenos datotek na streţnik. Datoteke so lahko povezane s posameznim sestankom na splošno, ali pa so omejene na posamezen sklep. Na kakšen način shranjujemo datoteke, smo ţe povedali v točki 4.2.5 (Komponente aplikacije).
Za prenos datotek uporabljamo »popup« okno, kakor je prikazano na sliki 64. Uporabnik lahko izbere večje število datotek za prenos in se odloči, kaj naj aplikacija stori v primeru konflikta z obstoječimi datotekami na streţniku.
Za prenos bi lahko uporabljali klasično HTML kontrolo za prenos datotek (upload), vendar HTML kontrola omogoča zelo malo fleksibilnosti. Namesto HTML kontrole uporabljamo Telerik RAD upload kontrolo. RAD upload kontrola razširja osnovne funkcionalnosti HTML kontrole. Omogoča nam enostavno nastavljanje preobleke (skina), število datotek za sočasni prenos, največjo velikost datoteke, dovoljene končnice datotek, prepisovanje obstoječih datotek ipd. Največjo dovoljeno velikost in dovoljene končnice nastavljamo preko globalne datoteke z viri
Gregor Praprotnik: Razvoj rešitve za vodenje sestankov stran 64
(GlobalResourceFile). Na ta način lahko na enem mestu spremenimo delovanje po celi aplikaciji brez pononovega prevajanja aplikacije.
Slika 65 prikazuje primer RAD upload kontrole.
Slika 64: Vmesnik za prenos datotek
Slika 65: Primer RAD upload kontrole za prenos datotek na strežnik
4.4
Testiranje
Testiranje programa je vsaka aktivnost, katere namen je oceniti parameter ali sposobnost sistema, in ugotoviti ujemanje z ţeljenimi rezultati. Testiranje je ključno za kvaliteto programske opreme, široko se uporablja med programerji in testerji, verndar še vedno ostaja umetnost. Teţavnost testiranja izhaja iz kompleksnosti programa. Nikoli ne moremo popolnoma pretestirati programa z zahtevnejšo kompleksnostjo. Namen testiranja ni le odpravljanje napak. Lahko je tudi zagotavljanje kvalitete, preverjanja in validacije ali ocenjevanja zanesljivosti. Testiranje ustreznosti in testiranje zanesljivosti sta dve veliki področji testiranja. Testiranje programske opreme je razmerje med proračunom, časom in kvaliteto (www.ece.cmu.edu, 2008).
Gregor Praprotnik: Razvoj rešitve za vodenje sestankov stran 65
Kompleksnost aplikacije za vodenje sestankov zahteva izvajanje testov, ki so v naprej načrtovani in pripravljeni. Primarni namen testiranja je ugotoviti skladnost rešitve z zahtevami. Napake so lahko omejene samo na nepravilno obnašanje aplikacije ob določenem vhodu, lahko pa se odraţajo v napačni izvedbi celotnega procesa. S testiranjem skušamo napake v čim večji meri odpraviti. Zaradi kompleksnoti aplikacije napak v celoti ni mogoče odkriti in razrešiti. Potrebno je odkriti takšne, ki bi lahko kritično vplivale na delovanje aplikacije.
Testiranje poteka od začetka razvoja do namestitve aplikacije v produkcijo in še dlje. Med razvojem je vsak razvijalec odgovoren, da izvaja teste nad svojo kodo in s tem preverja ustreznost delovanja. S tem programer izvaja tako imenovano »black-box« testiranje. Pri »black-box« testiranju je pozornost usmerjena v funkcionalnost posameznega modula ne glede na strukturo celotne aplikacije. Pri programiranju programer običajno ne pozna dovolj dobro celotne slike aplikacije, zato je njegovo testiranje omejeno na področja, ki jih pozna.
Ţe v fazi razvoja moramo izvajati testiranje aplikacije kot celote. To imenujemo »white-box« testiranje. V nasprotju z »black-box« testiranjem smo pri »white-box« testiranju pozorni tudi na strukturo aplikacije in tok podatkov. Pripraviti moramo plane za testiranje glede na implementacijo aplikacije. Testni scenariji izvirajo iz strukture programa.
V razvoju aplikacijo lahko testiramo in odpravljamo napake, saj poznamo struktkuro aplikacije, razumemo delovanje, tok podatkov in lahko predvidevamo, kje se lahko pojavijo napake. Pogosto pa je predobro poznavanje delovanja aplikacije največja teţava pri testiranju. V kolikor smo aplikacijo načrtovali ali pisali kodo, natančno vemo, kako jo uporabljati. Zato se dogaja, da nikoli ne pridemo do določenih stanj, ki nastopijo ob drugačni ali celo nepravilni uporabi. Da odkrijemo tudi takšne napake, aplikacijo v testiranje predamo končnim uporabnikom. Ti o delovanju in strukturi aplikacije ne vedo nič, niti jim to ni potrebno vedeti. Preden aplikacijo lahko ponudimo v testiranje končnim uporabnikom, mora doseči dovolj stabilno stanje, da jo lahko povprečen uporabnik normalno upravlja.
V ta namen smo pri razvoju aplikacije za vodenje sestankov v projektu predvideli tudi beta različico aplikacije in testiranje beta različice. Prva beta različica je namenjena samo interni uporabi. Aplikacija je v fazi interne beta različice dovolj stabilna za izvajanje vseh ključnih funkcij. Interno beta različico testiramo v sodelovanju s podjetjem DataLab, d.d., ki aplikacijo nekaj časa uporablja pri izvajanju sestankov in poroča o teţavah in predlogih.
Z odpravo kritičnih napak, ki so bile odkrite v fazi interne bete, je aplikacija