Päevik ja kliendiportaal

Peatükk on kahes osas: I, päevik (avalik objektipäevik, mida loevad kõik kolm publikut) ja II, kliendiportaal (sisselogitud kliendi vaade).

---

I OSA: PÄEVIK

5.1 Mis päevik on ja kellele ta paistab

Iga objekti süsteem (hooldusgraafiku rida) peab oma päevikut: kronoloogilist sissekannete logi selle süsteemi kohta. Päevik on süsteemipõhine: kolme süsteemiga objektil on kolm päevikut, mille vahel valitakse objekti avalehel.

Päeviku põhilubadus, mida tasub kliendile öelda otse ja uhkusega: objekti päevik on loetav koodiga. Objektil on 6-kohaline kood (QR-kleebisel), ja igaüks, kes koodi hoiab (elanik, majahaldur, ülevaataja), näeb süsteemi sissekandeid: kuupäeva, tüüpi, teksti, autorit, ja valmis aktide PDF-e. Sisselogimist ei nõuta. See ongi toode: hoolduspäevik, mis ripub «maja seinal», mitte sahtlis. Otsingumootoritele leht end ei näita.

Sama leht teenindab kolme publikut korraga, igaüks näeb oma kihti:

• Personal (tehnik/admin): kõik, pluss mustandid, aktide olekud, aktide koostamine ja parandamine, graafikuinfo, plokk «Objekti info» (ligipääs, seadmete asukohad, eripärad, kontakt) ja iga seadme juures nupp «Dokumentatsioon».
• Klient (portaalikonto, seotud selle objektiga): sissekanded + «Järgmine hooldus» märgisega «Tulekul» / «Hilinenud».
• Võõras koodiga: sissekanded ja valmis aktide kehtiv versioon; ei midagi muud.

Mida võõras ei näe (kõik on serveripoolselt ära lõigatud, mitte lihtsalt peidetud): akti mustandeid ja elutsükli seisu; aktide varasemaid PDF-i versioone; seadmete sisemärkusi; objekti infot (ligipääs, koodid, eripärad); väljakutsete lahenduslahtreid; graafiku kommertsvälju (intervall, hind, lepingunumber); allkirjade tooreid andmeid; personali tööriistu (need ei jõua isegi brauserisse). Müümata moodulid vastavad 404-ga enne igasugust päringut: uudishimulik proovija ei erista «pole paigaldatud» ja «pole olemas». Lehti ei saa ka pommitada: ühelt IP-aadressilt on lubatud kuni 60 avamist minutis (sisse logitud personalile piirangut pole), üle selle ütleb leht «Liiga palju päringuid».

5.2 Uksed päevikusse

• QR-kleebis seadmel/kilbil → avab objekti valikulehe (süsteemide nimekiri) → süsteem → päevik.
• Koodi käsitsi sisestamine: avaleht «Sisesta objekti kood kleebiselt», sisestusväli näidisega «nt. K4T2AP». Kood on kuus tähemärki («Kood peab olema 6 tähemärki»); vale kood on piiratud sagedusega («Liiga palju päringuid. Proovi hiljem uuesti.») ja korduv pommitamine blokeerib IP automaatselt.
• Personalile: nupp «Ava päevik» objekti kaardil, objektide nimekirjas ja pileti lehel.

Valikulehe ainus põhinupp on «Teata probleemist», päevikulehel on üleskutse «Kas midagi juhtus? Andke teada!»; mõlemad viivad rikketeate vormile (5.6).

5.3 Sissekanne: anatoomia ja tüübid

Kinnine rida: kellaaeg · tüübimärgis · teksti esimene rida · autor. Klõps avab: täisaeg sekunditega, täistekst, autor ja tema klass (Tehnik / Klient / Admin / Süsteem), akti puhul lingipaar «Vaata akti (PDF) →» / «Lae alla», sissekande ID, ja personalile nupp «Muuda».

Tüüpe on viis ja need on püsivad: hooldus · remont · väljakutse · teade · tehniku märkus. Kolm kihti, mida mitte segamini ajada:

1. Koodid: muutumatud, süsteemi selgroog.
2. Sildid: Sõnastikes saab tüübi kuvatavat nime ümber nimetada (nt «märkus» → «vaatlus»); kood jääb samaks.
3. Vaikimisi tüüp allika kaupa: Seadetes määratakse, mis tüübiga iga automaatne kirjutaja kirjutab (näiteks elaniku teade ja tehniku märkus). Akti kande tüüp tuleb malli enda «Päevik» plokist (ptk 5, Aktid), eraldi tavalise ja väljakutse kande jaoks; mall ilma selle plokita päevikusse ei kirjuta.

5.4 Kes kirjutab päevikusse

Kirjutaja	Mis tekib
Aktid	PDF-i koostamisel automaatne kanne akti kuupäevaga, autoriks akti allkirjastanud tehnik; parandusega koostatud uus PDF uuendab kannet; ainult siis, kui malli «Päevik» plokk on sisse lülitatud. Kanne tekib ainult siis, kui aktil on objekt ja seade (või objektil üks seade)
Elaniku rikketeade (QR, ilma loginita)	kanne tüübiga «teade», autoriklass Klient
Tehniku märkus	käsitsi kanne (5.5)
Hoolduse peatamine ja jätkamine (Hooldusgraafik → Peata / Jätka)	admini kanne, autoriklass Admin; dokumenteerib tsükli käsitsi liigutamise

Hooldusgraafik: koht, kus tsükleid päriselt liigutatakse. Kõigi objektide hooldustsüklid on ühes tabelis: Süsteem · Intervall · Järgmine hooldus · Pilet, ja neli olekut loenduritega: Hilinenud, Tähtaeg käes, Eelseisev, Peatatud. Erinevalt töölaua kaardist ei peideta siin hilinenud tsüklit, millel on juba avatud pilet: just see paar (hilinenud tsükkel ja kaua lahtine pilet) on selle lehe mõte.

Kaks nuppu ja kaks lauset, mida tasub sõna-sõnalt teada:

• «Peata»: «Objekti „{objekt}” hooldus peatatakse: järgmise hoolduse kuupäev kustutatakse ja cron ei loo sellele süsteemile enam piletit. Juba avatud piletid jäävad alles.» Peatamine on kuupäeva kustutamine; «Jätka» paneb selle tagasi.
• Intervalli muutmine ei nihuta praegust tähtaega: «Intervalli muutmine ei nihuta praegust tähtaega. Uus intervall rakendub siis, kui cron järgmise tsükli edasi lükkab.» See on kõige sagedasem «miks kuupäev ei muutunud»: kui tähtaeg peab kohe liikuma, muuda järgmise hoolduse kuupäeva, mitte intervalli.

Akti kanne kannab akti dokumendikuupäeva, mitte salvestamise hetke: tagantjärele vormistatud akt annab tagantjärele kande, ja see on õige: päevik räägib tööst, mitte klaviatuurist. Graafikukanne seevastu kannab tegevuse hetke: ta räägib sellest, millal keegi tsüklit liigutas.

5.5 Tehniku märkus: mitmepäevase töö jälg

Nupp päevikus avab tekstivälja (kuni ~2000 märki) → «Salvesta märkust». Kanne on iseseisev, aktiga sidumata, tüübiga «märkus».

Kasutusjuhis, mis väärib väljaütlemist: märkus on mõeldud jälje jätmiseks siis, kui akti veel ei tee, näiteks mitu päeva kestval tööl «täna vahetatud andurid 3. korrusel, homme jätkame». Ja kuna päevik on avalik ning portaalis nähtav, on märkus kliendile suunatud tekst: kirjuta nii, nagu loeks majahaldur, sest ta loebki. Sisemine kommentaar käib väljakutse lahenduslahtrisse, seadme sisemärkustesse või objekti infosse («Lisa märkus»): need on personalipoolsed ega leki kunagi välja.

5.6 Elaniku rikketeade (QR, ilma loginita)

Vorm: seade (üks → näidatakse tekstina; mitu → valik; null → palve helistada), nimi (vabatahtlik), kontakt (vabatahtlik), sõnum (kohustuslik, pikkusepiir seadistatav Seadetes, vaikimisi ~2000). Robotilõks püüab spämmi vaikselt; sagedus on piiratud (5 teadet tunnis IP kohta).

Mis tekib: alati päevikukanne («teade», autor sisestatud nimi või «Anonüümne»), ka piletiplokita paigaldusel; kui avalduste plokk on müüdud, lisaks avalduste rida saabuvate hulka + teavitus avalduste haldajatele; ja Telegram-teade admini kanalisse. Esitaja näeb tänukaarti «Aitäh! Teie teade on saadetud. Võtame teiega esimesel võimalusel ühendust.».

5.7 Sissekannete muutmine

• Teksti ja tüüpi muudab admin igal kandel; tehnik ainult oma akti kandel, akti muutmise akna jooksul (säte «Akti muutmise aken (tundi)», vaikimisi 12, tehnikupõhiselt muudetav). Akti kande parandamise asemel paranda pigem akti ennast («Paranda akti»): uus PDF kirjutab kande niikuinii üle.
• Kuupäeva muudab admin, või tehnik backdate-õigusega.
• Autorit muudab ainult admin (valik aktiivsete tehnikute seast + «Muu (vaba tekst)»).
• Aktita kanded (teade, märkus, graafikukanne) on muutmiseks admini-ainsad.
• Iga muutus auditeeritakse (enne/pärast).

Kustutamist ei ole: päevik on ajalugu.

5.8 Piirid, mida operaator peaks teadma

Lehele laetakse süsteemi 500 uusimat kannet; vanem ajalugu on baasis alles, aga lehel ei kuvata. Tehniku muutmisaken: akti muutmise aken (vaikimisi 12 h, ainult oma akt). 15 minutit ei ole muutmisaken, vaid loomise aken: kaks vajutust selle sees avavad sama mustandi. Admini 30 päeva on lagi sellele, kui kaua päevik talle muutmisnuppu joonistab, mitte piirang sellele, mida ta salvestada tohib. PDF-e serveeritakse avalikult akti 12-kohalise koodi järgi, ainult kehtiv versioon: turvamudel on kood + sageduspiir + audit, mitte sisselogimine. Koodi mitteteadja ei arva seda ära, ja proovija blokeeritakse.

---

II OSA: KLIENDIPORTAAL

5.9 Mis portaal on

Kliendiportaal (/client) on sisselogitud kliendi vaade oma objektidele: aktid (sh allkirjastamine), süsteemid, viimased päevikukanded, rikkest teatamine. Portaal on päevikuploki osa: ilma päevikuta portaali pole, sest portaal ongi objektivaade.

Kliendi ekraanil kannab portaal pealkirja «Juhtimispaneel». Selles juhendis nimetame teda kliendiportaaliks, sest see ütleb töötajale, millest jutt on; klient ise näeb ainult sõna «Juhtimispaneel».

Keel. Portaali ekraanid järgivad kliendi valitud keelt (eesti, vene, inglise). Dokumendid on alati eesti keeles: aktid ja PDF-id, akti allkirjastamise leht ja kõik kliendile saadetavad e-kirjad.

Neli asja, mida portaalis ei ole ja mille kohta klient varem või hiljem küsib: piletivaadet ei ole: klient ei näe, et töö on tellitud, ta näeb alles akti, mis lõpuks ilmub; teavituste kella ei ole: portaalis pole teavituste nimekirja, tegemist vajav on alati kaardil «Allkirjastamata aktid»; e-kirjade eelistusi ei ole: klient saab selle, mida aktivoog saadab (push’i saab ise välja lülitada); ja ligipääs käib kontakt-objekti kaupa, ettevõttetasandi «kogu firma objektid» õigust ei ole. Kui klient küsib «miks ma ei näe seda maja», on vastus alati sama: ta ei ole selle objekti kontaktide hulgas.

Portaali väljalülitamine ei võta klientidelt allkirjastamist: aktikirjad lähevad siis meili-lingi voole: klient avab akti lingiga ja allkirjastab sealsamas, kontot vajamata.

5.10 Kliendikonto

Kliendikonto = kasutaja rolliga «klient», seotud Registri kliendikirjega. Ulatus on rangelt lihtne: klient näeb täpselt neid objekte, millega ta on Registris kontaktina seotud, ei rohkem, ei vähem. Sidumine käib objekti kaardi kontaktide plokist.

Konto deaktiveerimine (kliendikirje mitteaktiivseks või arhiivi) lööb sisse järgmisel lehevahetusel: ka juba sisse logitud sessioon põrkub blokeeringule.

Tähele: kui tehniku-rolliga kasutajale on külge pandud kliendikirje, on see aruandlusseos, mitte portaalipääs: selline kasutaja portaali ei satu.

Kontode loomine

Kaks teed, mõlemad Registrist:

• Ükshaaval: kliendi kaardil «Loo portaali kasutaja» (vajab õigust «Kasutajate haldus»); parool genereeritakse ja näidatakse üks kord.
• Hulgi: nupp «Loo kliendikontod»: dialoog pakub sobilikud kliendid (aktiivsed, e-postiga, kontota; duplikaat-e-postiga read on märgitud ja «Vali kõik» jätab nad välja, käsitsi saab siiski valida). Linnuke «Saada tervituskiri» otsustab, kas kiri läheb kohe. Iga rida õnnestub või keeldub nimepidi; tühja valikuga midagi ei saadeta: «kõigile» nuppu ei eksisteeri põhimõtteliselt.

Tervituskiri ja parool

Kiri kannab parooli seadmise linki (kehtib 7 päeva; igal saatmisel värske): klient seab parooli ise, talle ei anta kunagi valmisparooli. Kirja teksti saab Seadetes üle kirjutada ({{link}} paigutub malli järgi, URL tuleb alati süsteemist); jalus kannab firma rekvisiite ja logo. Ebaõnnestunud saatmine jätab konto alles ja kliendi «saatmata» nimekirja: «Saada tervituskiri saatmata klientidele» laseb hiljem valikuliselt uuesti saata.

Konto loomise hetkel tembeldatakse kliendile «Teavituste algus»: sellest päevast algavad tema meiliteavitused (5.13); varasemat paberiajalugu ei teavitata. Kuupäev on kliendi kaardil admini poolt muudetav («Muuda teavituste algust»). Kui ühelgi objekti kontaktil seda kuupäeva pole, ei saadeta selle objekti aktide kohta üldse kirju.

5.11 Portaali avaleht

• 0 objekti → «Teile pole määratud objekte / Võtke ühendust haldusettevõttega».
• 1 objekt → kohe objektivaade.
• Mitu → «Tere, {nimi}!», objektikaartide võrk: aadress, süsteemimärgised, «Viimane akt» + Vaata (PDF) / Lae alla, «Järgmine hooldus» (kuu täpsusega), «Vaata objekti →».

Objektivaates: allkirjastamata aktide kaart (5.12) → süsteemikaardid («Süsteem» + seadmed; «Viimane akt» Vaata/Lae alla või «PDF ei ole valmis») → «Viimased sissekanded» (3 uusimat üle kogu objekti) → «Vaata täielikku ajalugu» (viib avalikule päevikulehele: klient kõnnib sama päevikut, mida elanik, oma kihiga) → rikkest teatamise vorm. Parandatud aktil näeb klient ka «Eelmine versioon» linki: talle on avatud kõik oma objekti aktide versioonid.

Kliendi teade portaalist (kirjeldus vähemalt 10 märki) loob avalduse firmale (otsekanal, staatusega töövoos), erinevalt QR-teatest, mis on elaniku hääl päevikus.

Nüüd saab klient soovi korral mõlemat. Portaali teatevormil on linnuke «Jäta kanne ka objekti päevikusse» ja selle kõrval valik «Millise seadme kohta?». See on ainus asi, mis portaali vormil avalikust vormist rohkem on: elanik kirjutab alati päevikusse, klient valib ise, kas tema teade jääb ka majale nähtavaks või läheb ainult firmale.

5.12 Aktide allkirjastamine portaalis

«Allkirjastamata aktid»: merevaigukarva kaart, portaali ainus «tee midagi» koht; ilmub ainult siis, kui on, mida teha. Kuni 30 päeva vanused aktid on lahtiselt, vanemad kokkuvolditud reas «Vanemad allkirjastamata aktid ({count})».

Portaal näitab kliendi kogu allkirjastamata seisu, ka akte, mis on vanemad tema konto loomisest. See on teadlik: aktid on süsteemis olemas ja allkirjastatavad; «Teavituste algus» vaigistab ainult teavitused (kliendile ei saadeta kirju paberiaja backlogist), mitte vaadet. Kui firma kasutab vaikivat vastuvõttu, seisab aktil «Loetud vastuvõetuks {kuupäev}», aga allkirjastada saab seda ikkagi.

Rida «Allkirjasta» → akti allkirjastamise leht (alati eesti keeles): andmed, PDF otse lehel, vorm: «Ees- ja perekonnanimi» (eeltäidetud), «Tellija märkused» (kui mall seda lubab), allkirjaväli vihjega «Soovitame allkirjastada telefonis, sõrmega on mugavam.». Parandatud aktil on märge «parandatud {kuupäev}», paranduse põhjus ja link eelmisele versioonile. Klient allkirjastab täpselt seda versiooni, mida ta näeb; kui akti vahepeal parandati, palub leht uuesti vaadata. Akti, mille parandus on pooleli, allkirjastada ei saa («Akt ei ole allkirjastamiseks valmis»). Allkirjastamine teeb PDF-ist uue versiooni allkirjaga; juba allkirjastatud akt näitab «Akt on allkirjastatud» + «Ava PDF».

5.13 Teavitused kliendile

Klient saab kaht liiki teavitust, mõlemad aktide kohta:

• Uus akt: akt on vormistatud tema objektil;
• Akt ootab allkirja: iganädalane meeldetuletus.

Kanalid: meil (esimene teade + nädalane kordus; algab «Teavituste algusest»; PDF manuses; alati eesti keeles) ja push telefoni/brauserisse (sisse-välja lülitatav portaali Seadetes). Kiri läheb objekti peamisele kontaktile, ja ainult aktide kohta, millel on seade. Meeldetuletused lõpevad, kui klient allkirjastab või akt loetakse vaikivalt vastuvõetuks.

Lisaks võib klient saada kirja «Akt on parandatud»: kui firma parandas akti pärast seda, kui klient oli sellest juba teate saanud. Kirjas on põhjus ja öeldakse, milline versioon kehtib.

Push kannab lukustusekraanile ainult üldsildi ja arvu, mitte kunagi objekti nime, aadressi ega sisu: lukustusekraan on kõige laiem publik, mida rakendus omab, ja detailid on portaalis, kus sessioon otsustab, kes mida näeb.

5.14 Kliendi Seaded

Neli kaarti: Profiil (nimi: kliendi ainus «kirjutav» väli väljaspool allkirja ja teateid; nimi läheb akti «Täitis» reale, seepärast on ise parandatav) · Kaheastmeline autentimine · Eelistused (keel, teema) · Push-teavitused (kaks lülitit: «Uus akt» ja «Akt ootab allkirja»). Rohkem klient ei kirjuta kuhugi: objektid, seadmed, aktide sisu, kontaktid ja graafik on kõik lugemiseks.

5.15 Piirid (portaal)

Viimaseid sissekandeid 3 objekti kohta; täisajalugu päevikulehel (kuni 500). Teate kirjeldus 10 kuni 2000 märki. Tervituslink 7 päeva. Allkirjastamata «värske» aken 30 päeva. Avalikud päevikulehed 60 avamist minutis IP kohta. Portaalil eraldi sessioonipikkust pole: kehtib rakenduse üldine.