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
We need to support user-driven actions to hide dialogs from the inbox (or any view)
Description
There are three distinct and mutually exclusive display states; "default", "bin" and "archive", that should have global effect, and should be fully user manageble for users with write access to the dialog. These states should also be possible for service owners to be set upon dialog creation, to support migration scenarios.
Implementation
The implementation should take into account the label concept described in #198, as this also controls the current display state. In particular, there should be a shared log for changing display state and eventually label (un)assignments.
We want to introduce a new aggregate, DialogEndUserContext, that lays the groundwork for these display states - implemented as "system labels" - and eventually user defined labels.
There should be a separate entity, eg. called "SystemLabel", which is a type table which all DialogEndUserContexts refers to. There should be three system labels; Default, Bin, Archive.
The log entity should be "LabelAssignmentLog" and should contain information about
the related system label (or, eventually, user label)
In order to change the display-state, the following EU endpoints should be made available
POST /enduser/dialogs/{dialogId}/labels
which should contain a body containing the requested system label, ie:
{"label": "systemlabel:bin"}
The user should have "write" access to the service resource referred to by the dialog for the dialog party, failing that should return 403 Forbidden
If authorized, requests should return a 204 No Content.
If the previous system labels was "default", and new system labels is either "bin" or "archive", a single "set" entry should be added with name set to the new state, ie either "systemlabel:bin" or "systemlabel:archive"
If the previous system labels was "bin" or "archive", and the new system labels is "default", a single "remove" entry should be added with the name set to the previous state, ie either "systemlabel:bin" or "systemlabel:archive"
If the previous system labels was "bin" and the new system labels is "archive", two log entries should be added with a action "remove" for name "systemlabel:bin" and action "set" for "systemlabel:archive"
If the previous system labels was "archive" and the new system labels is "bin", two log entries should be added with a action "remove" for name "systemlabel:archive" and action "set" for "systemlabel:bin"
If the new state matches the previous state, no log entries should be added
The endpoint should support optimistic concurrency checks with with If-Match, same as UpdateDialogCommand
Extension of Dialog DTOs
The dialog DTOs (for both search and details endpoints for both EU and SO) should be expanded to contain the enum for the current system labels
"systemLabel": "Default"
The search endpoint should be extended to take a parameter for systemLabel, ie "SystemLabel=bin" should return a list of dialogs with the supplied system labels.
Extension of CreateDialogCommand
Service providers should be allowed to set "systemLabel" in CreateDialogCommand. The label assignment log should reflect this and have the actor set to the service owner organization number
Automatic set of "Default" upon change
The dialog should have its system label automatically set to "Default" whenever the service owner updates the dialog. The assignment log should reflect this.
The content you are editing has changed. Please copy your edits and refresh the page.
## Description
* Added systemlabel (Bin/Archive) to hide dialogs
* Added post enpoints for endusers to change labels
* Added LabelAssignmentLogs
## Related Issue(s)
[#841](#841)
## Verification
- [x] **Your** code builds clean without any errors or warnings
- [x] Manual testing done (required)
- [ ] Relevant automated test added (if you find this hard, leave it and
we'll help out)
## Documentation
- [ ] Documentation is updated (either in `docs`-directory, Altinnpedia
or a separate linked PR in
[altinn-studio-docs.](https://github.com/Altinn/altinn-studio-docs), if
applicable)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced a new mutation for setting system labels, enhancing dialog
management capabilities.
- Added new API endpoints for retrieving and setting dialog labels,
improving user interaction with dialog states.
- Implemented logging for label assignments, allowing users to track
changes effectively.
- Enhanced search functionality to filter dialogs based on display
state.
- Added support for handling system labels through a structured command
and validation process.
- Introduced new data structures and interfaces for improved dialog
label assignment and error handling.
- **Bug Fixes**
- Enhanced validation for dialog labels to ensure correct formatting and
values.
- **Documentation**
- Updated schema and API documentation to reflect new features and
endpoints.
- **Chores**
- Modified project structure for better organization of dialog label
features.
- Added support for pre-release versions in the SDK configuration.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Amund Myrbostad <[email protected]>
Co-authored-by: Ole Jørgen Skogstad <[email protected]>
Co-authored-by: Magnus Sandgren <[email protected]>
Introduction
We need to support user-driven actions to hide dialogs from the inbox (or any view)
Description
There are three distinct and mutually exclusive display states; "default", "bin" and "archive", that should have global effect, and should be fully user manageble for users with write access to the dialog. These states should also be possible for service owners to be set upon dialog creation, to support migration scenarios.
Implementation
The implementation should take into account the label concept described in #198, as this also controls the current display state. In particular, there should be a shared log for changing display state and eventually label (un)assignments.
We want to introduce a new aggregate,
DialogEndUserContext
, that lays the groundwork for these display states - implemented as "system labels" - and eventually user defined labels.There should be a separate entity, eg. called "SystemLabel", which is a type table which all DialogEndUserContexts refers to. There should be three system labels; Default, Bin, Archive.
The log entity should be "LabelAssignmentLog" and should contain information about
The follow endpoints should be added:
GET /enduser/dialogs/{dialogId}/labellog
Should return a list of log entries:
In order to change the display-state, the following EU endpoints should be made available
POST /enduser/dialogs/{dialogId}/labels
which should contain a body containing the requested system label, ie:
Extension of Dialog DTOs
The dialog DTOs (for both search and details endpoints for both EU and SO) should be expanded to contain the enum for the current system labels
The search endpoint should be extended to take a parameter for systemLabel, ie "SystemLabel=bin" should return a list of dialogs with the supplied system labels.
Extension of CreateDialogCommand
Service providers should be allowed to set "systemLabel" in CreateDialogCommand. The label assignment log should reflect this and have the actor set to the service owner organization number
Automatic set of "Default" upon change
The dialog should have its system label automatically set to "Default" whenever the service owner updates the dialog. The assignment log should reflect this.
Tasks
Threat modelling
Acceptance criteria
TBW
The text was updated successfully, but these errors were encountered: