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

Support correlation-id #636

Open
9 tasks
olebhansen opened this issue Oct 28, 2024 · 0 comments
Open
9 tasks

Support correlation-id #636

olebhansen opened this issue Oct 28, 2024 · 0 comments

Comments

@olebhansen
Copy link

olebhansen commented Oct 28, 2024

Description

Add support for Correlation-id/"assosiasjons-id", so orders and messages can be linked to Dialogporten and/or other systems. The actual linking is out-of-scope, as the client/other system will have to do the integration.

The use is so e.g. one can query the Notification-API with a dilouge-id as key, and get all notification for that diaouge/dialouge-element (depending on how the correlation is associated).

One use-case is that a user in "arbeidsflate" can drill down in a dialouge, and see if/how a notification was sent for a particular dialouge/transmission.

Additional information

See comment #551 (comment)

Tasks

See sub-issues

Acceptance criteria:

It is possible to associate notifications with a Dialogporten-dialouge/item, so that this Dialogporten-ID can be used as key for querying the notification API (for current features - there are future changes for a log to improve getting information on the sequence of events, who was notified etc. see #551 ). It is out of scope to improve on the current data-structures beyond #640 to query for individual notifications by id.

Things to discuss

  • Future issues if notification is to push events (e.g. to populate Dialogporten with the presence of notifications)... do we need strongly typed keys? Defer this to another structure/problem NOT to be extended from this feature. Introduce a strongly typed validation.
  • Other wanted/un-wanted uses, e.g. if implementing as an un-typed list of key-values (that cold cover known feature-requests for tagging a notification as 1st, 2nd, etc.)
  • Performance considerations and ability to have efficient indexing/searches

Checklist

Threat modelling

  • Possible security issues discussed
  • Needs TM

Documentation

  • Do we need to update documentation in altinn docs?
  • Do we need Internal documentation (confluence)?

Testing

  • External tests
  • Should new functionality be Regression tested?
  • Should new functionality be included in Usecase tests?

Acceptance criteria quality

  • Does the issue have defined acceptance criteria?
  • Discussions completed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant