feat(api): Self Service Portal APIs

[tharakadadigama20]

Added webhooks when registration is approved/ rejected and record search API to return records of all statuses

Ticket no: 2268 (sub task)
When an registration is approved or rejected (on correction as well), an webhook is being sent which consists of the trackingId and Status.
Sample webhook payload:

{
  "timestamp": "2025-01-08T05:36:26.790Z",
  "id": "7c473b3d-bd8e-4a54-8a9c-8644f7a205a8",
  "event": {
    "hub": {
      "topic": "BIRTH/validated"
    },
    "context": {
      "trackingId": "B0LCLL4",
      "status": "validated"
    }
  }
}

Additionally in the record search API, the declare, validated and rejected statuses registrations are also returned.

[github-actions]

Oops! Looks like you forgot to update the changelog. When updating CHANGELOG.md, please consider the following:

• Changelog is read by country implementors who might not always be familiar with all technical details of OpenCRVS. Keep language high-level, user friendly and avoid technical references to internals.
• Answer "What's new?", "Why was the change made?" and "Why should I care?" for each change.
• If it's a breaking change, include a migration guide answering "What do I need to do to upgrade?".

[rikukissa]

Is this filtering needed? We're making it possible for event type to be whatever value in the future so if these variables could be whatever, we'd support the new approach right away

[rikukissa]

If you want to keep this filtering, then do it on the route definition level, so instead of one catch-all

'/events/{eventType}/status/{statusType}'

you would do

/events/birth/status/approved'
/events/birth/status/rejected'

and so on.

[tharakadadigama20]

Yes, we can remove this. However, what will serve as the trigger point for the webhook?
Currently, it's set up like BIRTH_REGISTERED, DEATH_REGISTERED and so on.
How can we filter the webhook to ensure it only triggers for the desired events?

[rikukissa]

Is there a specific constraint that prevents us from calling /events/{eventType}/status/{statusType} with arbitrary event type and status type e.g. '/events/divorce/status/my-custom-status'? The hub.topic that gets sent could directly be divorce/my-custom-status in this case without us needing the hard coded triggers at all

export enum TRIGGERS {
  BIRTH_REGISTERED,
  DEATH_REGISTERED,
  BIRTH_CERTIFIED,
  DEATH_CERTIFIED,
  BIRTH_CORRECTED,
  DEATH_CORRECTED
}

This approach would support Events v2 right away.

cc @euanmillar

[tharakadadigama20]

Will try this.

[tharakadadigama20]

@rikukissa @euanmillar
When doing this, the webhook subscribe POST API also needs to be changed.
Currently, the hub.topic should be in TRIGGERS
I have removed that validation in this API also.
Changes are pushed.

[euanmillar]

@tharakadadigama20 this webhook for correction isnt dispatching for me

[tharakadadigama20]

I have updated it. Please check now.

[euanmillar]

@rikukissa no sure how best to brief on how the triggers should work for Events V2. If you have any time to technically design that then I can brief the team.

@tharakadadigama20 I am not getting any webhook dispatch where a Registration Agent has validated a declaration from a field agent. This is where we would expect that BIRTH_VALIDATED webhook to be invoked. The reject one is working well. Additionally I am not getting any BIRTH_CORRECTED webhook. Maybe you should take a look through the workflow microservice some more to debug where those webhooks should be invoked.