[#2899] Integrate OpenKlantConfig and OpenKlant2Config

[pi-sigma]

No description provided.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 81.25000% with 9 lines in your changes missing coverage. Please review.

Project coverage is 94.12%. Comparing base (235d0f0) to head (35c4bed).
Report is 2 commits behind head on develop.

Files with missing lines	Patch %	Lines
src/open_inwoner/openklant/admin.py	71.42%	8 Missing ⚠️
src/open_inwoner/openklant/models.py	93.75%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1520      +/-   ##
===========================================
- Coverage    94.13%   94.12%   -0.02%     
===========================================
  Files         1064     1065       +1     
  Lines        39286    39319      +33     
===========================================
+ Hits         36982    37008      +26     
- Misses        2304     2311       +7     

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

[pi-sigma]

@swrichards Keeping the service field on the OpenKlant2Config non-nullable is problematic when attempting to update the config for the first time: the get_or_create in the admin's change_view raises an IntegrityError because no zgw service is provided. I worked around this by creating a default API service and displaying a message to the user that they should update the service. However, it might just be simpler to make the field nullable, as in the old OpenKlantConfig. Unless you can think of some other way around this?

[swrichards]

@swrichards Keeping the service field on the OpenKlant2Config non-nullable is problematic when attempting to update the config for the first time: the get_or_create in the admin's change_view raises an IntegrityError because no zgw service is provided. I worked around this by creating a default API service and displaying a message to the user that they should update the service. However, it might just be simpler to make the field nullable, as in the old OpenKlantConfig. Unless you can think of some other way around this?

@pi-sigma I am happy making the field nullable.

The general problem we have is that we want to know if the eSuite/OK2 service is correctly configured, and that does not play nice with SingletonModel as you say, because you have to be able to create it with sane defaults without user input. For now, I think we have to tackle this in our Service constructors: that is where we should fail loudly if:

1. OpenKlant2 is configured as the primary
2. But there is no service defined

Arguably we could also do this in the validation step for the global ok admin: if ok2 is selected there, you get a warning to first configure a service.

[swrichards]

I suspect we could solve this by using a combination of the @admin.display/readonly_fields attribute (docs): there will be no list page (because singleton), but the read only fields should still be display in the singleton detail page. Arguably less complex than tweaking the template.

[pi-sigma]

I played with @admin.display but couldn't get it to do what's needed without modifying the templates anyway. Also, compare:

• want to customize detail page -> customize template for detail page
• want to customize detail page -> use @admin.display to customize list page; although there is no list page, the strategy can still be used to change detail page indirectly

The first is less complex. Unless I'm missing something about the use of the decorator?