feat: Add optional EndUserId param to ServiceOwner Get Dialog details API

[knuhau]

Description

Add optional EndUserId param to ServiceOwner Get Dialog details API

Related Issue(s)

• Utvide tjensteier-detalj-API med parameter for sluttbrukers fnr #386

Verification

• Your code builds clean without any errors or warnings
• 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., if applicable)

[knuhau]

Opprinnelig ønsket implementasjon av innslag i SeenLog i følge issue #386:

Gjøre innslag i seen-liste som dekoreres med at det er utført av tjenesteeiers orgnr samt clientid fra token

Denne specen ble vel lagt inn mens SeenLog fremdeles var en string, så det lar seg vel neppe gjøres slik lenger.

Slik det er implementert nå blir innslag i Seenlog seende ut som følger, der Actor inneholder sluttbrukerens detaljer, mens EndUserType blir ServiceOwnerOnBehalfOfPerson og IsViaServiceOwner = true. Usikker på om det blir som ønsket:

[MagnusSandgren]

Ta kontakt om det er noe spørsmål om reviewen :)

[MagnusSandgren]

Burde vi ta vare på hvilken service owner som jobber på vegne av brukeren når ServiceOwnerOnBehalfOfPerson er valgt, eller er det alltid implisitt at det er tjenesteeieren som eier dialogen? @elsand

[elsand]

Burde vi ta vare på hvilken service owner som jobber på vegne av brukeren når ServiceOwnerOnBehalfOfPerson er valgt, eller er det alltid implisitt at det er tjenesteeieren som eier dialogen? @elsand

I første omgang ja.

Men det vil kunne bli scenarioer hvor det er andre aktører (orgnr) som har integrert med Dialogporten på vegne av tjenesteeieren, og "impersonater" tjenesteeieren gjennom en delegering av serviceprovider-scopet. I de tilfellene har Maskinporten-tokenet et ekstra claim, "supplier_org", som inneholder den autentiserte parten (mens "consumer_org" alltid vil være tjenesteeieren). Så for full paranoia kunne vi ha logget consumer_org, supplier_org og client_id (sistnevnte for å kunne ha sporbarhet ifm #40, som gjør det interessant å kunne skille på systemer innad hos en tjenesteeier), da vil vi ha god informasjon om hvem som faktisk gjorde en ServiceOwnerOnBehalfOfPerson.

Tenker vi kan avvente med dette inntil videre. Uansett ikke informasjon som vi vil komme til å eksponere i DTO-ene, så det kan vi innføre når som helst i fremtiden.

[sonarqubecloud]

Quality Gate failed

Failed conditions
15.9% Duplication on New Code (required ≤ 3%)

See analysis details on SonarCloud