Støtte for å kunne embedde dialogelementer i arbeidsflate/SBS-er (front channel embeds)

[elsand]

Introduksjon

Det bygges støtte for å indikere at dialogelementer refererer innhold som arbeidsflate (rettere sagt nettlesere som benytter arbeidsflate) og sluttbrukersystemer embedder direkte.

Beskrivelse

Meldinger og andre tjenestetyper vil ha behov for at innhold tilgjengeliggjøres sluttbrukere direkte i arbeidsflate. Dialogporten skal i hovedsak ikke inneholde annet enn metadata, og noen typer innhold er sensitive i natur og er ikke ønskelig å ha kopier av på Digdirs servere i public cloud.

Gjennom å gjøre det mulig for sluttbrukersystemene (nettlesere, mht arbeidsflate) kan laste dette innholdet direkte, oppnås bedre informasjonssikkerhet og kopiering av data unngås.

Dette vil være avhengig av dialogtoken (se #330) som sikkerhetsmekanisme.

Implementasjon

Dialogelementer utvides med en property som indikerer for arbeidsflate at den skal embeddes, se eksempel her.

Kan bare brukes på "gui" actions. Hvis frontChannelEmbed er satt til true, må også contentType settes. I første omgang skal vi kun støtte "text/markdown" som verdi her.

Notater for hvordan dette må implementeres i arbeidsflate (ikke relevant for dialogporten)

Sluttbrukersystemet (statisk del i nettleseren) vil laste dette (i første omgang markdown) med Fetch API (med dialogtoken i Authorization: Bearer-header), endepunkt må støtte CORS protokoll med pre-flight check), og vise dette direkte i detaljvisning. Det kan være flere front-channel embeds, enten innenfor et og samme dialogelement eller på tvers av flere dialogelementer. Innenfor samme dialogelement vil statisk del av arbeidsflate typisk rendre disse etter hverandre med en eller annen visuell separator.

Hvis flere dialogelementer inneholder frontChannelEmbeds, vil GUI måtte bestemme hvem av disse som er relevant å vise. En mulig logikk her vil være å vise den som er referert til av det nyeste aktivitetshistorikk-innslaget, og vise evt. øvrige kollapset (kan lene seg på "displayName"). Hvis ingen er referert til av aktivitetshistorikk-innslag, vis kun den sistei lista.

Frontend må her gjøre en clientside parsing/rendring av markdownen, og rendre denne. Her må det antagelig gjøres begrensninger for å unngå layout-utfordringer (f.eks. brede tabeller)

Oppgaver

Preview Give feedback

1. Utvide dialogeelement-model med frontChannelEmbed property
2. Utvide validering
3. Update REST schema

[elsand]

Fra refinement:

• Vi dropper HTML til fordel for (et subset av) CommonMark

[TheKnarf]

I møtet ble det diskutert å støtte et custom json format og/eller markdown.

Markdown har for en tid siden standardisert seg som CommonMark (og på et tidspunkt "forket" GitHub den for å definere Github Flavored CommonMark):

https://commonmark.org/
https://github.github.com/gfm/

Nå finnes det en del standardiserte biblioteker for å parse og rendere CommonMark (de fleste støtter også Github Flavored CommonMark).

I frontend verden har man stort sett standardisert på bibliotekene remark og rehype:

• https://github.com/remarkjs/remark
• https://github.com/rehypejs/rehype

Hvor disse to fungerer sammen, remark parser Markdown / CommonMark og rehype konverterer den til Html.