You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
The text was updated successfully, but these errors were encountered:
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.Checklist
The text was updated successfully, but these errors were encountered: