fix: use allowedPartyTypes to filter valid parties

[mikaelrss]

Description

Our form at Digital gravferdsmelding has suddenly startet displaying this error message locally, and it seems like this started in version 4.4.0.

I think the issue was introduced in this PR but I am not quite sure if this is a bug in the app frontend or if our app is providing incorrect data.

The issue occurs because when the frontend is reducing valid parties it filters each party on a condition partyTypeFilters[party.partyTypeName] from line 38 in partyProviderUtils. The issue with this is that partyTypeFilters is an object that is contructed in this util function like this:

const partyTypeFilters = {
  [PartyType.Organisation]: partyTypesAllowed.organisation,
  [PartyType.SubUnit]: partyTypesAllowed.subUnit,
  [PartyType.Person]: partyTypesAllowed.person,
  [PartyType.BankruptcyEstate]: partyTypesAllowed.bankruptcyEstate,
};

Where PartyType looks like this:

export enum PartyType {
  Person = 1,
  Organisation = 2,
  SelfIdentified = 3,
  SubUnit = 4,
  BankruptcyEstate = 5,
}

This, in my case, evaluates to a filter like this:

const partyTypeFilters = {
  2: false,
  4: false,
  1: true,
  5: false,
};

However, party.partyTypeName is not an int representing one of these values, but rather a string "person", which means that line 38 will always evaluate to false for every party, even though that party should be valid.

So I am wondering if the partyTypeName should actually be the string "person", and there is a bug in the code, or are we doing something incorrectly in our form that makes the /parties-endpoint return incorrect data?

EDIT: I see that the cypress tests are all failing, and that the types for IParty suggest that partyTypeName should in fact be PartyTypes (enum integer value). Can someone confirm if this is correct? 😅

Verification/QA

• Manual functionality testing
  • I have tested these changes manually
  • Creator of the original issue (or service owner) has been contacted for manual testing (or will be contacted when released in alpha)
  • No testing done/necessary
• Automated tests
  • Unit test(s) have been added/updated
  • Cypress E2E test(s) have been added/updated
  • No automatic tests are needed here (no functional changes/additions)
  • I want someone to help me make some tests
• UU/WCAG (follow these guidelines until we have our own)
  • I have tested with a screen reader/keyboard navigation/automated wcag validator
  • No testing done/necessary (no DOM/visual changes)
  • I want someone to help me perform accessibility testing
• User documentation @ altinn-studio-docs
  • Has been added/updated
  • No functionality has been changed/added, so no documentation is needed
  • I will do that later/have created an issue
• Support in Altinn Studio
  • Issue(s) created for support in Studio
  • This change/feature does not require any changes to Altinn Studio
• Sprint board
  • The original issue (or this PR itself) has been added to the Team Apps project and to the current sprint board
  • I don't have permissions to do that, please help me out
• Labels
  • I have added a kind/* label to this PR for proper release notes grouping
  • I don't have permissions to add labels, please help me out

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[HauklandJ]

Closing this PR as further investigation shows the issue is not with the frontend, but rather not enforcing enum serialization policy in the backend, see 729.