[#2782+#2780] Disable first name editing for DigiD user with BRP

[pi-sigma]

Users should not be able to edit their first name in OIP if the Hall Centraal API is configured to pull data from BRP

Taiga: https://taiga.maykinmedia.nl/project/open-inwoner/issue/2782 and https://taiga.maykinmedia.nl/project/open-inwoner/issue/2780

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.89%. Comparing base (2835a28) to head (27c047f).

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #1414   +/-   ##
========================================
  Coverage    94.89%   94.89%           
========================================
  Files         1046     1046           
  Lines        38610    38612    +2     
========================================
+ Hits         36638    36640    +2     
  Misses        1972     1972           

Flag	Coverage Δ
	94.89% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

[pi-sigma]

@alextreme

There was indeed a mistake in our form + template. However, our logic is generally based on assumptions that are a bit at odds with the description in the Taiga issue:

• Our code displays/hides certain things based on whether data has been retrieved from BRP. We check for the field is_prepopulated on the user model, which is set by update_brp_data_in_db. As you can see from the second, the field is only set to True if the API request is successful. Otherwise, the fields remains False (the default) and we will still show first_name in the profile edit.

  open-inwoner/src/open_inwoner/accounts/models.py

  Line 499 in 2835a28

  def is_digid_user_with_brp(self) -> bool:

  open-inwoner/src/open_inwoner/haalcentraal/utils.py

  Line 31 in 2835a28

  def update_brp_data_in_db(user, initial=True):

• The taiga issue(s) state that first_name should be gone as soon as the API service is configured, irrespective of whether data has been requested or if the request was successful.

The latter would require a few more changes.