DRB-IT / blacktiger-controller

The HTML/JavaScript/CSS client for blacktiger
0 stars 0 forks source link

Ryd historik ryder også aktive lytteres data #209

Closed xToMMeRx closed 9 years ago

xToMMeRx commented 9 years ago

Når man trykker på "Ryd historik" nulstilles både antal "opkald" og "minutter" på aktive lyttere (altså dem som endnu ikke står i historikken).

Den skal selvfølgelig kun nulstille data i historikken og aldrig "live data"

michaelkrog commented 9 years ago

Jeg har lige tilladt mig at flytte den til næste release. Det betyder namlig at jeg kan nå at lave et release i dag, som du evt. kan lægge op i test og prøve af.

michaelkrog commented 9 years ago

@xToMMeRx Grunden til at "live" data også nulstilles er antal opkald og minutter hives fra historikken. Uden historik ingen info om tidligere opkald og deres længde.

Det vi kan gøre er at vi ved tryk på "Ryd historik" kun sletter dem der ikke er aktive lyttere. Lyder det fornuftigt?

xToMMeRx commented 9 years ago

Jeg har lige drøftet det med Peter.

Vi er enige om at "Ryd historik" knappen ikke må kunne have impact på live listen på nogen måde. Kan man ikke lave 2 buffere I systemet, én til de data de bliver vist I historikken, og én inde bag ved som blot holder styr på historiske data?

På den måde kan "Ryd historik" knappen godt ryde de data der bliver vist på websiden under Historik sektionen, men det vil ikke slette de historiske data, så live kald stadig har data-grundlaget for de informationer der skal præsenteres.

Alternativt skal "Ryd historik" knappen ryde alle historik data på nær historik på kald som endnu ikke er afsluttede. Så hvis jeg er 10 min inde i mit 3. opkald så siden viser "Opkald: 3" og x antal minutter samlet for de 3 kald, og jeg så trykker "Ryd historik" så nulstiller "Opkald" til 1 og minutter ned til 10 min, men jeg bliver stående under aktive kald.

Reelt skal Ryd Historik knappen have samme funktionalitet som hvis man lukker og åbner browseren. Altså hvor historik forsvinder, men alle aktive kald bliver stående (blot uden historik). Når man åbner browseren fra ny er der jo heller ingen historik, men den viser alligevel kald som allerede er igang og startede før browseren blev åbnet.

michaelkrog commented 9 years ago

Hej @paf og @xToMMeRx

Kort beskrivelse af historikkens nuværende struktur På oversigten over møderummet har vi aktive kald og historik. Begge lister bruger en service der hedder HistorySvc hvorfra der kan trækkes info om tidligere opkald – aktive som inaktive. Aktive opkald henter info fra HistorySvc for at vide hvor mange gange en aktiv lytter har ringet og hvor længe. Historik henter også info fra HistorySvc, men kun om de opkald der ikke er aktive.

Hvilken løsning? Begge de løsninger I nævner er en mulighed. Den første(med et ekstra sæt historikdata) vil tage længst tid at lave. Den anden er mere korrekt og tager lidt kortere tid vil jeg vurdere.

Den første Jeg synes den første vil give et lidt forkert billede. Hvis man med eksemplet du nævner(10. minut inde i 3. opkald) ryder historik, så vil der fortsat stå at han har lavet 3 opkald og x antal minutter samlet. Men når han så lægger på, vil historikken ikke stemme overens med dette, da den er blevet tømt for data. De 2 lister bør, synes jeg, baseres på samme data for at de 2 listers informationer ikke kommer ud af sync.

Den anden I denne løsning kan de 2 lister baseres på samme data. Ved tryk på "Ryd historik" fjernes al historik UNDTAGEN data for de aktive kald. Så ved samme eksempel igen(10. minut inde i 3. opkald) ville info om de 2 første opkald blive fjernet, men det 3. aktive opkald vil blive bibeholdt i datagrundlag for historikken.

Det vil stemme overens med hvad der sker når man åbner en frisk browser. Den får info fra serveren om aktive opkald samt hvornår de startede og ud fra det oprettes der aktive opkald i datagrundlaget for historikken.

Jeg vil anbefale at vi går efter løsning nummer 2. Er det ok med jer?

xToMMeRx commented 9 years ago

Hej Michael

Jeg er enig med dig I at løsning nummer to giver det mest retvisende billede, og hvis det samtidigt er den nemmeste at lave så synes jeg det er den du skal gå videre med :-)

michaelkrog commented 9 years ago

Oprettet som issue i blacktigerjs. https://github.com/DRB-IT/blacktigerjs/issues/13