Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Opprette templates for varsling #100

Closed
Tracked by #25 ...
RagnarFatland-Avanade opened this issue Jun 4, 2024 · 7 comments
Closed
Tracked by #25 ...

Opprette templates for varsling #100

RagnarFatland-Avanade opened this issue Jun 4, 2024 · 7 comments
Assignees
Labels
kind/feature-request New feature or request product/meldingstjenesten Issues related to Altinn Correspondence

Comments

@RagnarFatland-Avanade
Copy link
Collaborator

RagnarFatland-Avanade commented Jun 4, 2024

Det etableres ett sett faste templates for E-post og SMS varsler som skal sendes via Altinn Notification.

Templates består av en predefinert standardtekst, og støtte for inntil 1 TextToken per tekst-felt og samme standard-makroer som benyttes av Notification, detaljert her: Altinn/altinn-notifications#545
TextTokens kan inneholde makroer.

I tillegg vurder å legge til egne makroer som gir mening for Correspondence:

  • SendersName??

En Template består av:

  • EmailSubject
  • EmailBody
  • SMSBody
  • ReminderEmailSubject
  • ReminderEmailBody
  • ReminderSMSBody

Dersom ingen texttokens er angitt benyttes tom streng som replace-verdi.
I denne kontekst bør kanskje texttoken-felt være en gitt, navngitt liste ala "EmailSubjectTextToken" istedenfor en nummerert liste som angitt under??

Correspondence tar ansvar for å fylle ut TextTokens før vi sender videre til Notification, mens Notification fyller ut makroene.

Forslag til templates; bør diskuteres ytterligere;

Template 1: TextTokenOnly
Denne dekker det mest generiske tilfellet, der avsender sender hele meldingsteksten som TextToken.
(Tilsvarer den mest brukte enkelt-template i Altinn 2).
EmailSubject: {0}
EmailBody: {1}
SMSBody: {2}
ReminderEmailSubject: {3}
ReminderEmailBody: {4}
ReminderSMSBody: {5}

Template 2: GenericPersonMessage
For varslinger for meldinger til en konkret innbygger/person.
EmailSubject: "Du har mottatt en melding i Altinn {0}"
EmailBody: "Hei $recipientName$, du har mottatt en ny melding i Altinn fra $SendersName$. {1} Logg deg inn i Altinn Innboks for å se denne meldingen."
SMSBody: "Hei $recipientName$, du har mottatt en ny melding i Altinn fra $SendersName$. {2} Logg deg inn i Altinn Innboks for å se denne meldingen."
ReminderEmailSubject: "Påminnelse - du har mottatt en melding i Altinn {3}"
ReminderEmailBody: "Hei $recipientName$, dette er en påminnelse om at du har mottatt en ny melding i Altinn fra $SendersName$. {4} Logg deg inn i Altinn Innboks for å se denne meldingen."
ReminderSMSBody: "Hei $recipientName$, dette er en påminnelse om at du har mottatt en ny melding i Altinn fra $SendersName$. {5} Logg deg inn i Altinn Innboks for å se denne meldingen."

Template 3: GenericOrgMessage
For varslinger for meldinger til en organisasjon.
Lik template 2.

TODO

@RagnarFatland-Avanade
Copy link
Collaborator Author

Se også https://digdir.slack.com/archives/C033JFF2NNN/p1721134297017779 som gjelder avklaring rundt å opprette varsel på vegne av andre.

@CWO79 og @leogasnier har dere gode innspill på språkbruk i template?

@Andreass2
Copy link
Collaborator

Templates lager i databasen for å raskt/enkelt kunne gjøre endringer uten å gjøre en ny release.
Vi legger inn 1 rad per språk med samme grunnlag som over.

@Andreass2 Andreass2 moved this from Refinement to Ready for dev in Altinn melding og formidling Sep 16, 2024
@Andreass2
Copy link
Collaborator

Andreass2 commented Sep 18, 2024

I templatene våre, ønsker vi at TE skal velge avsendingstidspunkter selv eller skal vi sette at varsel sendes ved publisering, og revarsel i forhold til lovverk(1 uke etter om jeg husker riktig)? @leogasnier

@leogasnier
Copy link

vet om scenarier v. masseutsendelser (typisk) hvor det kan være hensiktsmessig å sette divergerende varslingstidspunkt ift publisering (feks. når publisering skjer kl 00:00). Mener vi i Altinn 2 har definert varslingsvindu fra kl 07:00-20:00ish men usikker på om varsling i A3 har noe slikt.
Kunne en tilnærming være at vi feks. setter defaultverdi ut fra publiseringstidspunkt + en time eller noe slikt, men tillater at tjenesteeier selv setter varslingstidspunkt senere.
Altså en mekanisme hvor vi ikke begrenser de som har et aktivt forhold til dette samtidig som alle andre ikke trenger å forholde seg til det? @RagnarFatland-Avanade - hva tenker du gitt erfaringer fra A2? @Andreass2 - TODO: sjekk om varsling har definert noe tidsvindu for utsending, da det muligvis tar ned behovet noe.

@Andreass2
Copy link
Collaborator

Andreass2 commented Sep 18, 2024

Det ser ut til at epost ikke har noe spesifikt utsendingsvindu, men sms har ett utsendingsvindu fra kl 09 til kl 17

@Andreass2
Copy link
Collaborator

Det kan være litt vanskelig å håndtere den divergerende varslingslogikken på publiseringstidspunkt. Men jeg vil tro at 1 time etter publiseringstidspunkt skal være nok til å unngå varsling før publisering.

Alternativt kunne man opprettet varsling på publiseringstidspunkt, men da vil det igjen være vanskeligere å gi tidlig tilbakemelding om at det ikke eksisterer kontaktinformasjon om mottaker eller om mottaker er reservert for varsling.

@Andreass2
Copy link
Collaborator

Foreslår at for TE, så har template 2 og 3 samme verdi, slik at en masseutsendelse kan sendes til både bedrifter og privatpersoner i samme meldingsbestilling.

I systemet vårt(og selvfølgelig dokumentasjon) justeres teksten basert på om mottaker er bedrift eller privatperson

@github-project-automation github-project-automation bot moved this from 👀 In review to ✅ Done in Altinn melding og formidling Sep 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature-request New feature or request product/meldingstjenesten Issues related to Altinn Correspondence
Projects
Status: ✅ Done
Development

No branches or pull requests

4 participants