search

Altinn / altinn-register

Altinn platform microservice for handling register data
0 stars 0 forks source link

BUG: MailingAddress contains post code and city in addition to being in their own properties #106

Closed mariannestor closed 6 months ago

mariannestor commented 1 year ago

Description of the bug

Unsure if this issue is a studio problem, but we have an app in production with the MailingAddress prefill binding from DSF (Folkeregisteret) - retrieved from https://altinncdn.no/schemas/json/prefill/prefill.schema.v1.json.

In production this binding gets the full address + postal code + postal city. Therefore, when we have a field for 1) Address, 2) Postal code and 3) Postal city, the postal code and postal city gets displayed twice. This requires excess work with cleaning of data afterwards, and we need it to be fixed.

image

But this issue wasn't discovered in test (see screenshot) because the data there shows MailingAddress as only streetname + housenumber and (if any) houseletter. So we are curious if this is a mistake that has been made during translation of the prefill? Or what prefill binding should we actually use for the case with 3 separate fields for address, postal code and postal city?

This was discovered in production with the DSF.MailingAddress, but it might be an issue for the Party.Person.MailingAddress as well.

Steps To Reproduce

  1. This is one of the apps it has happened on: https://altinn.studio/editor/krt/krt-1030a-1
  2. Under 1.5.1 Adresselinje 1 in test environment, the address looks okay, only streetname + housenumber + (if any) housletter, and postal code and postal city separately in their own fields.
  3. But in production the same app has streetname + housenumber (+ houseletter) + postal code + postal city. Retrieved in prefill.json file with DSF.MailingAddress.

Additional Information

No response

hflateland commented 1 year ago

We observe the same behavior using using the DSF.MailingAddress i production:

image

The prefill should match the fields avalible in the address component.

hflateland commented 1 year ago

Same error in TT02 using Tenor testdata.

image

SandGrainOne commented 1 year ago

Refinement 21.03.2023: We need to analyse this issue more. Follow the call chain and mapping between different models to see if we can retrieve the "streetaddress" as a separate property. Investigate how most of the address information is stored in the database.

It's currently SblBridge that performs a join of address lines. This is to support international addresses and other non-streetaddresses, but this is now broken for normal street addresses after the integration with the modern "DSF".

EddieSTAF commented 7 months ago

Is there any plan for fixing this issue?

SandGrainOne commented 7 months ago

We didn't, but we're looking into making room for this now in February.

SandGrainOne commented 6 months ago

Problem might have started with the integration of the new freg. Talk to the people who made the changes. One suggested solution is to do a search and replace for PostalCode and PostalPlace with blank after the join.

SandGrainOne commented 6 months ago

A fix for this has been merged and made a part of the 24.4 release of Altinn 2.

acn-sbuad commented 6 months ago

Verified in AT22.