Notification log

[acn-sbuad]

Description

A requirement of Notifications is to provide logs. Both for end user and system integrations. The logs must provide an overview of the activities that have been performed in relation to a specific notification and/or notification order.

Bør kunne slå opp på andre felter ifm varslingssenter etc /api/log?associatedWith=urn:dialogporten:dialog-id: Mulig modell:

• varslingsordreid
• innslagstype: sendeforsøk, bekreftetlevert
• assosiasjonsId
• userid
• mottaker av varslingsordre (orgnr/fnr)
• ressursid
• endepunktstype (sms, epost, push?, brevdue)
• endpunkt
• tidspunkt

In scope

No response

Out of scope

No response

Additional Information

No response

### Tasks
- [ ] Add assosiations property to notification order that can handle a list of type-value pairs
- [ ] Set up log table
- [ ] Set up API for accessing log
- [ ] Logic for populating log

[elsand]

Here's a model we've been sketching with in Dialogporten:

// GET varsling.altinn.no/api/v1/notification-log/?associatedWith=urn:altinn:dialogporten:dialog-id:{{some-dialog-guid-here}}
[
  {
     "entryType": "sendAttemptMade", // a new entry for "deliveryConfirmed"
     "timestamp": "2024-06-20T10:34:45.2353522",
     "notificationOrderId": "{{some-notification-order-guid}}",
     "resource": "urn:altinn:resource:ske_tredjepartsopplysninger_boligsameier",
     "resourceinstance": "{{some-dialog-guid-here}}",
     "party": "urn:altinn:organization:identifier-no:912345678",
     "associatedWith": [
       { "type": "urn:altinn:dialogporten:dialog-id", "id": "{{some-dialog-guid-here}}" }
       { "type": "urn:altinn:dialogporten:transmission-id", "id": "{{some-transmission-guid-here}}" }
     ],
     "endpointType": "email",
     "endpoint": "some@example.com",
     "endpointOwnerName": "Ola Nordmann"
  }
]

Having natural IDs here (ie. fnr/dnr) is probably a no-go as we probably cannot substantiate that the end-user has a need for secure identification of each of the alerted recipients (this will often eg. include the general manager etc). We might get away with using internal IDs here (eg. user IDs) but then arbeidsflate (or the other end-user systems) will have to look this up somehow at runtime. As this is a (non-mutable) log, I would expect the endpoint owner name to be resolved at write-time and stored in the database. We can (and should) store the identifiers as well, but resolving these 10 years later is sometimes hard (people change names, dnr->fnr merge/splits).

[SandGrainOne]

@elsand I would think the correct way to handle identifiers would be to find the current information. We shouldn't show the past name of a person or organization, but the current name.

[SandGrainOne]

@elsand Burde vi se litt på tilgangskontroll av disse loggene? Skal hvem som helst kunne gjøre oppslag på "tilfeldige" dialog id å få ut loggen assosiert med den?

[elsand]

@elsand I would think the correct way to handle identifiers would be to find the current information. We shouldn't show the past name of a person or organization, but the current name.

I disagree; in principle logs should be immutable and reflect the state of things when the log entry was created, and not the state at any arbitrary display time, which is in context of the event that log entry represents is irrelevant or even misleading. This also lets us avoid storing personal identifiers in the logs.

Burde vi se litt på tilgangskontroll av disse loggene? Skal hvem som helst kunne gjøre oppslag på "tilfeldige" dialog id å få ut loggen assosiert med den?

Yes, this should be authorized, so information about resource and party should be preserved so that a PDP can be consulted.