Optional AddressNL component gives "required" error message

[robinmolen]

Partly closes #4699

Changes

The postcode and houseNumber fields didn't change their 'required' state depending on the addressNL component required state. This resulted in optional addressNL components requiring a postcode and houseNumber.

This PR sets the required and allow_blank field values of the postcode and houseNumber fields depending on the required state of the overarching addressNL component.

Checklist

Check off the items that are completed or not relevant.

• Impact on features

  • Checked copying a form
  • Checked import/export of a form
  • Config checks in the configuration overview admin page
  • Problem detection in the admin email digest is handled

• Release management

  • I have labelled the PR as "needs-backport" accordingly

• I have updated the translations assets (you do NOT need to provide translations)

  • Ran ./bin/makemessages_js.sh
  • Ran ./bin/compilemessages_js.sh

• Dockerfile/scripts

  • Updated the Dockerfile with the necessary scripts from the ./bin folder

• Commit hygiene

  • Commit messages refer to the relevant Github issue
  • Commit messages explain the "why" of change, not the how

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.67%. Comparing base (1658eca) to head (37ba8f1).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #5042   +/-   ##
=======================================
  Coverage   96.67%   96.67%           
=======================================
  Files         765      765           
  Lines       26131    26140    +9     
  Branches     3407     3409    +2     
=======================================
+ Hits        25262    25271    +9     
  Misses        606      606           
  Partials      263      263           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[vaszig]

Similar approach with mine in #5022. So I guess we can close this in favor of the other one which handles everything related in one place.

We prefer dealing with the translations during the release preparation (avoiding conflicts in the PRs as well)

[robinmolen]

Similar approach with mine in #5022. So I guess we can close this in favor of the other one which handles everything related in one place.

We prefer dealing with the translations during the release preparation (avoiding conflicts in the PRs as well)

Yeah agreed, i'm closing this PR (and deleting the branch)

Check, I'll keep that in mind