Accept id on attachments, actions when creating dialogs

[elsand]

Introduction

In order to be able to idempotently handle changes to attachment lists (on both dialog and transmissions) and api/gui actions, we need to be able to support user supplied attachment ids.

Description

The Altinn 3 integration aims to idempotently map any instance to a corresponding dialog, including all attachments and actions. As the list of attachments/actions is mutable, we need to be able to determine whether or not a given attachment/action to a instance is new, updated or deleted compared to the list of attatchments/actions on the dialog. We can dervice a UUIDv7 from the instance attachment id/action urls/other unique data, and thus achieve idempotency. The update command support supplying ids, but as of now the create command does not. This issue describes expanding createdialogcommand to accept ids on the attachments and action sub entities.

See also Slack discussion, notably:

Si at en TE henter en dialog med 5 GuiActions og skal til å gjøre endringer på den siste GuiActionen i lista via patch. I mellomtiden har det blitt lagt til en GuiAction. Dersom id var bestemt av DP ville den garangtert bli lagt bakerst i GuiAction lista og dermed ikke påvirket den kommende patchen. Men dersom vi åpner opp for brukerdefinerte ider kan den nye GuiAction bli lagt til på et vilkårlig sted i dialogens GuiAction liste. Dette vil påvirke patchen som targeter elementet på index, og ikke på id. Redningen her er at patch brukes sammen med if-match header.

Implementation

In addition to adding Id to the create command DTOs, EnsureNoExistingUserDefinedIds needs to be expanded.

Tasks

Preview Give feedback

1. Add id to DTOs
2. Update validations
3. Update unit/integration tests
4. Add e2e-test (if relevant)

Threat modelling

Preview Give feedback

1. Does this change introduce any potential security issues? No

Acceptance criteria

GIVEN a create dialog command contains one or more attachments or actions with user-defined IDs
WHEN the command is processed
THEN the new attachments or actions must be persisted with the provided IDs, ensuring no duplicates exist across the dialog

GIVEN a create dialog command that does not specify an ID for an attachment or an action
WHEN the command is processed
THEN the system must generate and persist a unique ID for that attachment or action

GIVEN a create dialog command or update dialog command with user-defined IDs
WHEN any ID provided conflicts with an already existing user-defined ID in the same dialog
THEN the command must fail with a clear error message indicating the conflict