We need a status value that can be employed by service owners not able to explicitly set an aggregate status for the dialog, but still signal to frontends how the dialog should be considered.
(This issue was split from #752)
Description
We introduce a "Automatic" value to the DialogStatus enum. When set, the service owner has indicated that the aggregated status should be attempted to be derived automatically. Dialogporten will, based on rules below, dynamically set any of the above statuses for the end-user .
The following rules will should be applied (in order) to determine dialog status. This should be dynamically set in the enduser-DTOs (not serviceowner):
By default, the status should be dynamically mapped to "New"
If there are any transmissions where sender is endUser, the status should be dynamically mapped to "InProgress"
If there are any transmissions of type "Alert", the status should be dynamically mapped to "RequiresAttention"
If the activity log contains any "dialogClosed" activities, the status should be dynamically mapped to "Completed"
### Tasks
- [ ] Implementation tasks are added here
- [ ] Prepare documentation (if relevant - either update working document, or add a new file in `docs`)
- [ ] Add e2e-test (if relevant)
### Threat modelling
- [ ] Does this change introduce any potential security issues?
elsand
commented
2 weeks ago
Introduction
We need a status value that can be employed by service owners not able to explicitly set an aggregate status for the dialog, but still signal to frontends how the dialog should be considered.
(This issue was split from #752)
Description
We introduce a "Automatic" value to the DialogStatus enum. When set, the service owner has indicated that the aggregated status should be attempted to be derived automatically. Dialogporten will, based on rules below, dynamically set any of the above statuses for the end-user .
The following rules will should be applied (in order) to determine dialog status. This should be dynamically set in the enduser-DTOs (not serviceowner):
Acceptance criteria
GIVEN ... WHEN .... THEN ...
GIVEN ... WHEN .... THEN ...