Contactvoorkeuren feature improvement

[JanBrek]

Thema / Theme

Contactgevens API

Omschrijving / Description

From Den Haag the request is to have more fine grained contact configuration.

(Pre-discussed with Joeri B)

Toegevoegde waarde / Added value

No response

Aanvullende opmerkingen / Additional context

No response

[joeribekker]

Jan presented this image as the desired UX for setting your messaging preferences:

There are 4 important aspects:

1. Every organisation (eventually) wants to manage their own possible messaging preferences (ie. some support Whatsapp, some only e-mail. Some have a newsletter, some have details about zaken)
2. Every organisation could use a different, or multiple, notify components that hook into these preferences to actually sent out the messages.
3. The preferences of a client (Klant) are stored and read by different components. A portal typically reads/writes data, a notify component typically only reads this data.
4. There needs to be mutual understanding of the possible messages and channels between the components (ie. portal and notify components).

Draft idea:

1. We introduce a new resource in Open Klant: MeldingType that holds the configurable messaging preferences (point 1, 2 and 4 above).

GET /api/v1/meldingtypen

[
{
  "categorieNaam": "Meldingen over uw zaken",
  "naam": "Besluiten",
  "code": "besluit",  # This code needs to come from the notify component.
  "mogelijkeKanaalCodes": [
    "post",  # These codes will be in the Referentielijsten API as possible channels.
    "email",
    "sms"
  ],
  "verplichteKanaalCodes": ["post"]
},
{
  "categorieNaam": "Meldingen over uw zaken",
  "naam": "Statuswijzigingen",
  "code": "status",
  "mogelijkeKanaalCodes": [
    "email",
    "sms"
  ],
  "verplichteKanaalCodes": ["email"]
},
{
  "categorieNaam": "Nieuwsberichten",
  "naam": "Updates van uw gemeente",
  "code": "nieuws",
  "mogelijkeKanaalCodes": [
    "email"
  ],
  "verplichteKanaalCodes": []
}
]

2. There will be a new attribute in the DigitaalAdres resource: meldingsvoorkeuren. This is an array that holds all the codes from the notify component.

{
  "verstrektDoorBetrokkene": {
    "uuid": "095be615-a8ad-4c33-8e9c-c7612fbf6c9f"
  },
  "verstrektDoorPartij": {
    "uuid": "095be615-a8ad-4c33-8e9c-c7612fbf6c9f"
  },
  "adres": "johndoe@example.com",
  "soortDigitaalAdres": "email",
  "omschrijving": "Persoonlijke e-mailadres",
  "meldingsvoorkeuren": [  # New :)
    "besluit",
    "status"
  ]
}

[joeribekker]

@JanBrek could you validate this? I denormalized category to make it simple. On client level, for UI purposes, you can simply group on the categorieNaam instead of having another resource for meldingsCategorieen or so.

[JanBrek]

@joeribekker Looks alright. I am just thinking how for example 'post' will be registered as its not a digitaalAdres but comes from BRP (or similar in case of KVK)