Support supplying organization number as actor for label sets via SO

[elsand]

Introduction

Legacy systems (not utilizing systemusers) in Altinn 2 can process correspondence, ie. place them in archive in A2. This cannot currently be mirrored to Dialogporten.

Description

There is currently no way for the correspondence integration to utilize serviceowner/dialogs/{dialogId}/endusercontext/systemlabels in this context, as supplying EndUserId is required which only supports types of NorwegianPersonIdentifier or SystemUserIdentifier.

In order to support this legacy scenario, we need a method for supplying arbitrary actor information available to only admin-integrations.

Implementation

SetSystemLabelCommandHandler and BulkSetSystemLabelCommandHandler are extended to allow for an arbitrary actor to be supplied as part of the request body, available for only admin-integrations (ie. having digdir:dialogporten.serviceprovider.admin scope). This replaces the requirement to supply EndUserId. No authorization is performed, as this is the responsibility of the calling integration having admin privileges.

Supplying EndUserId and arbitrary actor is mutually exclusive, which must be handled in the validator.

Concurrency handling via revisions/if-match/etag should work as before and not be changed in any way.

Suggested DTO changes:

// SetSystemLabelCommandHandler
{
  "addLabels": [
    "Archive"
  ],
  "performedBy": {
      "actorType": "PartyRepresentative",
      "actorId": "urn:altinn:organization:identifier-no:912345678"
   }
}

// BulkSetSystemLabelCommandHandler
{
  "dialogs": [
    {
      "dialogId": "0197ee86-a1fd-71c4-9762-5339e51c3e68",
      "endUserContextRevision": "32e72de4-ade5-41c9-942f-821745eabf54"
    }
  ],
  "addLabels": [
    "Archive"
  ],
  "performedBy": {
      "actorType": "PartyRepresentative",
      "actorId": "urn:altinn:organization:identifier-no:912345678"
   }
}

Normal actor validation should be made (valid PartyIdentifier, actorName can be supplied xor actorId)

Tasks

• Change validators for SetSystemLabelCommandHandler and BulkSetSystemLabelCommandHandler
• Update DTOs
• Prepare documentation
• Add integration tests

Threat Modelling

• I have considered potential security risks (if risks were found, please list them below)
• This does not authorize the provided actor against the supplied dialog(s). This is acceptable, because 1) this is only allowed for admin-integrations, which for all practical purposes are internal and 2) the supplied actor is not grantedany access to the dialog or notifications

Acceptance criteria

GIVEN an admin-integration calling SetSystemLabel for a dialog
WHEN it sends a request with addLabels set, EndUserId omitted, and a performedBy object containing a valid PartyIdentifier (via actorId xor actorName)
THEN the request succeeds, the labels are added, and the performedBy actor is stored as part of the change metadata

GIVEN an admin-integration calling BulkSetSystemLabel for one or more dialogs
WHEN it sends a request with dialogs, addLabels, and a performedBy object containing a valid PartyIdentifier (via actorId xor actorName)
THEN the request succeeds, the labels are added, and the performedBy actor is stored for each updated dialog

GIVEN a request to SetSystemLabel or BulkSetSystemLabel
WHEN both EndUserId and performedBy are supplied
THEN the request is rejected with a validation error indicating they are mutually exclusive

GIVEN a request using SetSystemLabel or BulkSetSystemLabel
WHEN performedBy.actorId is not a valid PartyIdentifier, or both actorId and actorName are provided, or neither is provided
THEN the request is rejected with a validation error describing the invalid or conflicting actor information

GIVEN a non-admin integration calling SetSystemLabel or BulkSetSystemLabel
WHEN it supplies a performedBy object
THEN the request is rejected with an authorization error stating that performedBy is only allowed for admin-integrations

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

✅ Successfully generated implementation plan.

💡 Use @coderabbitai <feedback> to replan

Examples

• Example 1
• Example 2

_{You can configure auto-planning by selecting labels in the issue_enrichment configuration.}

🔗 Similar Issues

Related Issues

• Bulk endpoint for SystemLabels #2301

👤 Suggested Assignees

• oskogstad

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord or schedule a call!

[coderabbitai]

Implementation Plan

Approach

Enable admin-integrations to supply arbitrary actor information (organization numbers, etc.) when setting system labels on dialogs, allowing legacy Altinn 2 systems to mirror correspondence operations to Dialogporten without requiring EndUserId.

Observations

The codebase uses a CQRS pattern with MediatR for command handling, FastEndpoints for HTTP endpoints, and FluentValidation for request validation. SetSystemLabel and BulkSetSystemLabel commands exist in both ServiceOwner and EndUser contexts, but this ticket focuses on the ServiceOwner context where EndUserId is currently mandatory. The domain model already supports arbitrary actors via the Actor/ActorName entities and LabelAssignmentLog for change tracking. Admin integrations are identified by the digdir:dialogporten.serviceprovider.admin scope, with runtime checks available via IUserResourceRegistry.IsCurrentUserServiceOwnerAdmin().

Assumptions

Assumption 1: DTO Definition Location

Options Considered:

• Define PerformedByDto only in Application layer and reference it from WebApi
• Define separate DTOs in each layer with mapping
• Define in WebApi layer only

Chosen Option: Define PerformedByDto only in Application layer and reference it from WebApi

Rationale: This follows the existing pattern where BulkSetSystemLabelDto is shared, promotes consistency, and avoids duplication. The DTO is simple enough that layer separation adds unnecessary complexity.

Assumption 2: Validation Approach for Admin-Only Restriction

Options Considered:

• Check admin scope in validators using injected IUserResourceRegistry
• Check admin scope in handlers before processing
• Use authorization policies at the endpoint level

Chosen Option: Check admin scope in validators using injected IUserResourceRegistry

Rationale: This follows existing patterns where validators use injected services, provides clear declarative validation rules, and ensures validation failures are returned consistently as validation errors rather than authorization errors mid-processing.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Plan

Phase 1: Core DTO and Validation Infrastructure

Establish the data structure for performedBy and implement all validation rules including mutual exclusivity with EndUserId, admin-only enforcement, and actor information validation.

Task 1: Define PerformedByDto

Create the shared DTO structure that will be used across commands and requests to represent arbitrary actor information.

• Create PerformedByDto class in src/Digdir.Domain.Dialogporten.Application/Common/Actors/ directory
• Add properties: ActorType (enum referencing ActorType.Values), ActorId (nullable string), ActorName (nullable string)
• Use nullable reference types to support the xor constraint validation

Task 2: Add PerformedBy to Application Commands

Extend the ServiceOwner context commands to accept the new performedBy parameter.

• Add PerformedByDto? PerformedBy { get; set; } property to SetSystemLabelCommand in src/Digdir.Domain.Dialogporten.Application/Features/V1/ServiceOwner/EndUserContext/Commands/SetSystemLabels/SetSystemLabelCommand.cs
• Add PerformedByDto? PerformedBy { get; set; } property to BulkSetSystemLabelCommand in src/Digdir.Domain.Dialogporten.Application/Features/V1/ServiceOwner/EndUserContext/Commands/BulkSetSystemLabels/BulkSetSystemLabelCommand.cs
• Document that PerformedBy and EndUserId are mutually exclusive

Task 3: Create PerformedByValidator

Implement validation logic for the performedBy object itself, reusing existing actor validation patterns.

• Create PerformedByValidator in src/Digdir.Domain.Dialogporten.Application/Common/Actors/ directory
• Implement actorId xor actorName constraint validation (exactly one must be provided)
• Validate actorId is a valid PartyIdentifier when present using existing IsValidPartyIdentifier() extension
• Reference existing ActorValidator patterns for consistency
• Add appropriate error messages for each validation scenario

Task 4: Update SetSystemLabelCommandValidator

Extend the existing validator to enforce the new business rules around performedBy usage.

• Inject IUserResourceRegistry into the validator in src/Digdir.Domain.Dialogporten.Application/Features/V1/ServiceOwner/EndUserContext/Commands/SetSystemLabels/SetSystemLabelCommandValidator.cs
• Add validation rule: EndUserId and PerformedBy cannot both be present (mutual exclusivity)
• Add validation rule: When PerformedBy is present, caller must be admin using _userResourceRegistry.IsCurrentUserServiceOwnerAdmin()
• Add validation rule: When PerformedBy is present, apply PerformedByValidator using SetValidator()
• Update existing EndUserId.NotEmpty() rule to only apply when PerformedBy is null (at least one must be present)
• Add appropriate error messages describing each constraint

Task 5: Update BulkSetSystemLabelCommandValidator

Apply the same validation rules as Task 1.4 to the bulk operation validator.

• Make identical changes to src/Digdir.Domain.Dialogporten.Application/Features/V1/ServiceOwner/EndUserContext/Commands/BulkSetSystemLabels/BulkSetSystemLabelCommandValidator.cs
• Ensure validation logic matches SetSystemLabelCommandValidator for consistency

🤖 Prompt for AI agents

Establish the data structure for performedBy with all validation rules. This
includes mutual exclusivity with EndUserId, admin-only enforcement, and actor
information validation.

Create PerformedByDto in Application/Common/Actors/ with ActorType enum, ActorId
(nullable string), and ActorName (nullable string).

Add PerformedByDto? PerformedBy property to both SetSystemLabelCommand and
BulkSetSystemLabelCommand. Document mutual exclusivity with EndUserId.

Create PerformedByValidator implementing actorId xor actorName constraint,
validate actorId as valid PartyIdentifier when present, and add appropriate
error messages.

Update both SetSystemLabelCommandValidator and
BulkSetSystemLabelCommandValidator:
- Inject IUserResourceRegistry
- Add mutual exclusivity rule for EndUserId and PerformedBy
- Add admin check when PerformedBy is present using
IsCurrentUserServiceOwnerAdmin()
- Apply PerformedByValidator using SetValidator()
- Update EndUserId.NotEmpty() rule to only apply when PerformedBy is null
- Add clear error messages for each constraint

Phase 2: Handler Implementation

Update command handlers to create Actor objects from performedBy and use them when creating label assignment logs.

Task 1: Update SetSystemLabelCommandHandler

Modify the handler to support actor creation from either EndUserId or performedBy.

• In src/Digdir.Domain.Dialogporten.Application/Features/V1/ServiceOwner/EndUserContext/Commands/SetSystemLabels/SetSystemLabelCommandHandler.cs, add actor creation logic before calling UpdateSystemLabels()
• Create helper method to build Actor: if PerformedBy is present, construct LabelAssignmentLogActor with ActorType from PerformedBy.ActorType and ActorName entity from PerformedBy.ActorId/ActorName
• If EndUserId is present, use existing actor creation flow (current behavior)
• Pass the created actor to the UpdateSystemLabels() method on DialogEndUserContext
• Ensure no changes to concurrency handling (revision/if-match logic)

Task 2: Update BulkSetSystemLabelCommandHandler

Apply the same actor creation logic to the bulk operation handler.

• Make equivalent changes in src/Digdir.Domain.Dialogporten.Application/Features/V1/ServiceOwner/EndUserContext/Commands/BulkSetSystemLabels/BulkSetSystemLabelCommandHandler.cs
• Extract actor creation into a shared helper method if both handlers can reuse it
• Apply actor to each dialog's UpdateSystemLabels() call in the bulk operation
• Maintain existing batch processing logic unchanged

🤖 Prompt for AI agents

Update command handlers to create Actor objects from either EndUserId or
performedBy and use them in label assignment logs.

In SetSystemLabelCommandHandler, add actor creation logic before calling
UpdateSystemLabels():
- Create helper method to build Actor: if PerformedBy is present, construct
LabelAssignmentLogActor with ActorType from PerformedBy.ActorType and ActorName
entity from PerformedBy.ActorId/ActorName
- If EndUserId is present, use existing actor creation flow
- Pass the created actor to UpdateSystemLabels()
- Maintain existing concurrency handling

Apply the same logic to BulkSetSystemLabelCommandHandler:
- Extract actor creation into a shared helper method if reusable
- Apply actor to each dialog's UpdateSystemLabels() call
- Maintain existing batch processing logic

Phase 3: WebApi Integration

Expose the performedBy field through HTTP endpoints by updating request DTOs and endpoint mapping.

Task 1: Update WebApi Request DTOs

Add performedBy to the request structures that map to the updated commands.

• Add PerformedByDto? PerformedBy { get; set; } property to SetDialogSystemLabelRequest in src/Digdir.Domain.Dialogporten.WebApi/Endpoints/V1/ServiceOwner/EndUserContext/SetDialogSystemLabelsEndpoint.cs
• Add PerformedByDto? PerformedBy { get; set; } property to BulkSetDialogSystemLabelsRequest in src/Digdir.Domain.Dialogporten.WebApi/Endpoints/V1/ServiceOwner/EndUserContext/BulkSetDialogSystemLabelsEndpoint.cs
• Mark as [FromBody] if needed based on existing patterns
• Add XML documentation describing the admin-only usage

Task 2: Update Endpoint Mapping

Map the new request property to command properties in the endpoint handlers.

• In SetDialogSystemLabelsEndpoint's ExecuteAsync method, add PerformedBy = req.PerformedBy to the command construction
• In BulkSetDialogSystemLabelsEndpoint's ExecuteAsync method, add PerformedBy = req.PerformedBy to the command construction
• Follow existing direct assignment patterns shown in the exploration results

🤖 Prompt for AI agents

Expose the performedBy field through HTTP endpoints by updating request DTOs and
mapping.

Add PerformedByDto? PerformedBy property to SetDialogSystemLabelRequest and
BulkSetDialogSystemLabelsRequest:
- Mark with [FromBody] if needed based on existing patterns
- Add XML documentation describing admin-only usage

Update endpoint mapping in ExecuteAsync methods:
- Add PerformedBy = req.PerformedBy to command construction in both
SetDialogSystemLabelsEndpoint and BulkSetDialogSystemLabelsEndpoint
- Follow existing direct assignment patterns

Phase 4: Integration Tests

Add comprehensive test coverage for all acceptance criteria scenarios across both operations.

Task 1: Add SetSystemLabel Test Scenarios

Create tests covering all validation and authorization scenarios for single label operations.

• In tests/Digdir.Domain.Dialogporten.Application.Integration.Tests/Features/V1/ServiceOwner/SystemLabels/Commands/SetSystemLabelTests.cs, add test cases:
  • Admin with valid performedBy succeeds and labels are applied
  • Non-admin with performedBy returns Forbidden
  • Request with both EndUserId and performedBy returns validation error
  • Invalid actorId (not a valid PartyIdentifier) returns validation error
  • Both actorId and actorName present returns validation error
  • Neither actorId nor actorName present returns validation error
• Use existing FlowBuilder patterns: .CreateSimpleDialog() → .SetSystemLabelServiceOwner() → .ExecuteAndAssert()
• Mock admin scope by injecting IUser with the admin scope using CreateUserWithScope(AuthorizationScope.ServiceOwnerAdminScope)

Task 2: Add BulkSetSystemLabel Test Scenarios

Apply the same test scenarios to bulk operations.

• In tests/Digdir.Domain.Dialogporten.Application.Integration.Tests/Features/V1/ServiceOwner/SystemLabels/Commands/BulkSetSystemLabelTests.cs, add equivalent test cases
• Use .BulkSetSystemLabelServiceOwner() flow builder method
• Test both single and multiple dialogs in bulk operations with performedBy
• Verify validation errors are returned for all dialogs when validation fails

Task 3: Verify Actor Storage in Change Metadata

Ensure that performedBy actor information is correctly persisted in the audit trail.

• Add tests that query LabelAssignmentLog after successful label operations
• Verify PerformedBy.ActorType matches the supplied value
• Verify PerformedBy.ActorNameEntity.ActorId or Name matches the supplied actorId/actorName
• Assert that the actor information is stored for each dialog in bulk operations
• Confirm existing EndUserId flow still works correctly (no regression)

🤖 Prompt for AI agents

Add comprehensive integration tests for all validation and authorization
scenarios.

In SetSystemLabelTests.cs, add test cases:
- Admin with valid performedBy succeeds
- Non-admin with performedBy returns Forbidden
- Both EndUserId and performedBy returns validation error
- Invalid actorId returns validation error
- Both actorId and actorName present returns validation error
- Neither actorId nor actorName present returns validation error
Use FlowBuilder patterns: CreateSimpleDialog() → SetSystemLabelServiceOwner() →
ExecuteAndAssert()
Mock admin scope using
CreateUserWithScope(AuthorizationScope.ServiceOwnerAdminScope)

In BulkSetSystemLabelTests.cs, add equivalent test cases using
BulkSetSystemLabelServiceOwner(). Test both single and multiple dialogs with
performedBy.

Add tests verifying actor storage in LabelAssignmentLog:
- Query LabelAssignmentLog after successful operations
- Verify ActorType, ActorId/Name match supplied values
- Confirm existing EndUserId flow still works (no regression)

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Establish the data structure for performedBy with all validation rules. This
includes mutual exclusivity with EndUserId, admin-only enforcement, and actor
information validation.

Create PerformedByDto in Application/Common/Actors/ with ActorType enum, ActorId
(nullable string), and ActorName (nullable string).

Add PerformedByDto? PerformedBy property to both SetSystemLabelCommand and
BulkSetSystemLabelCommand. Document mutual exclusivity with EndUserId.

Create PerformedByValidator implementing actorId xor actorName constraint,
validate actorId as valid PartyIdentifier when present, and add appropriate
error messages.

Update both SetSystemLabelCommandValidator and
BulkSetSystemLabelCommandValidator:
- Inject IUserResourceRegistry
- Add mutual exclusivity rule for EndUserId and PerformedBy
- Add admin check when PerformedBy is present using
IsCurrentUserServiceOwnerAdmin()
- Apply PerformedByValidator using SetValidator()
- Update EndUserId.NotEmpty() rule to only apply when PerformedBy is null
- Add clear error messages for each constraint
===============================================================================

Task: 2

Update command handlers to create Actor objects from either EndUserId or
performedBy and use them in label assignment logs.

In SetSystemLabelCommandHandler, add actor creation logic before calling
UpdateSystemLabels():
- Create helper method to build Actor: if PerformedBy is present, construct
LabelAssignmentLogActor with ActorType from PerformedBy.ActorType and ActorName
entity from PerformedBy.ActorId/ActorName
- If EndUserId is present, use existing actor creation flow
- Pass the created actor to UpdateSystemLabels()
- Maintain existing concurrency handling

Apply the same logic to BulkSetSystemLabelCommandHandler:
- Extract actor creation into a shared helper method if reusable
- Apply actor to each dialog's UpdateSystemLabels() call
- Maintain existing batch processing logic
===============================================================================

Task: 3

Expose the performedBy field through HTTP endpoints by updating request DTOs and
mapping.

Add PerformedByDto? PerformedBy property to SetDialogSystemLabelRequest and
BulkSetDialogSystemLabelsRequest:
- Mark with [FromBody] if needed based on existing patterns
- Add XML documentation describing admin-only usage

Update endpoint mapping in ExecuteAsync methods:
- Add PerformedBy = req.PerformedBy to command construction in both
SetDialogSystemLabelsEndpoint and BulkSetDialogSystemLabelsEndpoint
- Follow existing direct assignment patterns
===============================================================================

Task: 4

Add comprehensive integration tests for all validation and authorization
scenarios.

In SetSystemLabelTests.cs, add test cases:
- Admin with valid performedBy succeeds
- Non-admin with performedBy returns Forbidden
- Both EndUserId and performedBy returns validation error
- Invalid actorId returns validation error
- Both actorId and actorName present returns validation error
- Neither actorId nor actorName present returns validation error
Use FlowBuilder patterns: CreateSimpleDialog() → SetSystemLabelServiceOwner() →
ExecuteAndAssert()
Mock admin scope using
CreateUserWithScope(AuthorizationScope.ServiceOwnerAdminScope)

In BulkSetSystemLabelTests.cs, add equivalent test cases using
BulkSetSystemLabelServiceOwner(). Test both single and multiple dialogs with
performedBy.

Add tests verifying actor storage in LabelAssignmentLog:
- Query LabelAssignmentLog after successful operations
- Verify ActorType, ActorId/Name match supplied values
- Confirm existing EndUserId flow still works (no regression)

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- @coderabbitai You can skip phase 3. Add a simple unit test case for phase 2.
- @coderabbitai For assumption 1 go ahead with option 3 and replan.

💬 Have feedback or questions? Drop into our discord or schedule a call!