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 assosiation id  property to notification order
- [ ] 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).