Avklaring: Revurdere bruk av MarkAsUnread

[RagnarFatland-Avanade]

Funksjonalitet for "MarkAsUnread" ble innført i #106
Denne er implementert ala slik det var i Altinn 2, men vi bør revurdere om det er rette måte i ny løsning.

Bakgrunn:
I Altinn 2 kunne meldinger bli markert som Lest (Status = Read) som følge av:

1. GetCorrespondence i SOAP API
2. GetMessages med markAsRead=true
3. I Portalen når sluttbruker åpner meldingen.

Dette kunne blant annet medføre at elementer ble markert som Read, uten faktisk å være det, noe som kan forstyrre prosessene for henting og bruk av meldingene.
For eksempel med blandet bruk mellom SBS og Portal, eller dersom SBS laster ned melding flere ganger.

For å løse dette har vi innført "Fetched" som en hendelse vi logger ved Get, istedenfor Read.
Fetched skal ikke medføre en endring i CorrespondenceStatus, og endrer derfor ikke i søk.

MarkAsUnRead
Et vanlig brukscenario for en portalbruker er å kunne markere en melding som "ulest", f.eks. ved fordeling av oppgaver internt i en organisasjon.

I A2: et eget flagg bool "markedUnread"=true, istedenfor å endre correspondence status, samt at det logges til EventHistory, og som kun er lov å sette dette dersom elementet ikke er Archived eller Confirmed.

I A3 har vi implementert dette med API-operasjonen "MarkUnread", samt et tilsvarende "Bool MarkedUnread"
Elementet blir kun MarkedUnread=true dersom det ikke er er PurgedByRecipient eller PurgedByAltinn og har fått statusen "Read".

Er dette riktig måte å gjennomføre det på?
Burde kanskje MarkedUnread kun være noe som visningskomponent / arbeidsflate skal forholde seg til?
Er det alternative måter å gjøre dette på istedenfor å ha et get "MarkedUnread"-flagg?

[elsand]

Jeg mener "marker som ulest" er noe vi ikke bør videreføre.

"Marker som ulest" ble innført forholdsvis seint i Altinn 2 (20.11) fordi det viste seg at det var en del innboks-integrasjoner som bygde logikk rundt om et element var markert som "lest" eller ikke, som da portalbrukere uforvarende forstyrret da de åpnet ting de hadde tilgang til. Det som skisseres her med en separat status for "Fetched" vil i så måte løse akkurat det problemet mye bedre. Brukertester Arbeidsflate har gjennomført har også avdekket at "marker som ulest" brukes i delte innbokser som en klønete måte å indikere overfor andre at "denne åpnet jeg ved et uhell, jeg vil ikke ha noe med den å gjøre". Dette behovet mener jeg også vi bør kunne løse generisk i Dialogporten / AF på et bedre vis, gjennom f.eks. labels og mekanismer for brukerstyrt tildeling ("assigned to")

For øvrig - Dialogporten fører en "seen-log" for hver gang i dialog lastes (ikke i listevisning, men lasting enkelt-dialog), som inneholder tidspunkt og informasjon om hvem som så den. Denne er personlig; en dialog vil kunne bli "ses" av flere personer, og en gitt dialog vil bli vist som "usett" i arbeidsflate hvis ikke den innloggede brukeren selv har sett den tidligere. Hvem andre som har sett en gitt dialog vil vises i listevisning. Denne loggen er uforanderlig (append only), og nye innslag gjøre per person per endring av dialogen (så i praksis vil arbeidsflate vise en dialog som du har sett tidligere, men som siden er blitt endret på en eller annen måte som "usett")

Siden Dialogporten ikke sitter på payload, har vi bevisst unngått begrept "lest" - siden vi ikke har noen forutsetning for å vite om det vesentlige knyttet til en dialog faktisk er "lest". Derimot legger vi opp til at tjenestetilbyderen selv kan legge inn i aktivitetshistorikken for dialogen et oppslag når man vurderer at payloaden er blitt "lest" av noen. Dette vil være en "sterkere" indikasjon, som også vil kunne brukes i vilkårssjekken som Notification kan gjøre for å sjekke om det skal sendes revarsler. For correspondence sin del tenker jeg det er naturlig å legge inn et slikt innslag idet correspondence-status blir satt til "Read".

[leogasnier]

GUI: det funksjonelle behovet er jo at en sluttbruker (eks. daglig leder) som åpner et element pva. en virksomhet, kan sette dette til "ulest" slik at den som skal følge opp elementet ser at det er noe nytt.. - vi bør verifisere at dette er løsbart med dialog->arbeidsflate?!
SBS: løser seg selv m A3 melding.