[#2723] Support multiple backends for Notifications API #1378
Conversation
a55e8de to
4f7894c
Compare
4f7894c to
3b0dc38
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #1378 +/- ##
===========================================
- Coverage 94.96% 94.94% -0.03%
===========================================
Files 1032 1043 +11
Lines 37949 38290 +341
===========================================
+ Hits 36039 36353 +314
- Misses 1910 1937 +27 ☔ View full report in Codecov by Sentry. |
3b0dc38 to
99027dc
Compare
bd94d65 to
351e2aa
Compare
src/open_inwoner/conf/base.py
Outdated
| # tasks from showing up in the admin when OIP is run with | ||
| # Docker; this needs to be fixed this in the library eventually; | ||
| # for now we load it after all our apps. | ||
| "notifications_api_common", | ||
| ] |
There was a problem hiding this comment.
Further to my other comments: I think this needs to stay in for the moment. We really only want this to be removed once we're positive the migration has been completed.
We should check in with @sergei-maertens -- he once mentioned they had a similar issue in open form, and the solution involved using the checks framework to ensure users upgrade via a certain path (e.g., you cannot go from 1.x to 1.z without first going through 1.y). With something like that, we could enforce that the migration is run before the users upgrade to a version that drops the package.
There was a problem hiding this comment.
This is the implementation: https://github.com/open-formulieren/open-forms/blob/a4cfd74aa47a547c7a36055daf8611af128b7bba/src/openforms/upgrades/upgrade_paths.py#L78
Next week is Open Forms off-week - I could use that time to extract this code into a re-usable django-app/package that you could then use in OIP for these kind of migrations. Would that be acceptable?
| from rest_framework import status | ||
| from rest_framework.response import Response | ||
| from rest_framework.views import APIView | ||
| from zgw_consumers.api_models.base import factory | ||
|
|
||
| from notifications.api.serializers import NotificatieSerializer | ||
| from open_inwoner.configurations.models import SiteConfiguration | ||
| from open_inwoner.openzaak.api_models import Notification | ||
| from open_inwoner.openzaak.auth import get_valid_subscription_from_request |
There was a problem hiding this comment.
This still has references to notifications_api_common, and is I think where the logic for going from a singleton to many configs would also have to be handled.
There was a problem hiding this comment.
Checked: the only lingering references to notifications_api_common are in INSTALLED_APPS, the data migration and the associated test.
I am not sure we need special logic in the NotificationsWebhookBaseView to handle different backends (in the way we need special logic to handle differen ZGW backends). We need to be able to register webhooks with different backends, but this is now possible. When a request comes in at the NotificationsWebhookBaseView, we determine the subscription from the request, create a notification from the data and pass it on to the notification handler.
91a1034 to
1278f77
Compare
1278f77 to
025b761
Compare
Taiga: https://taiga.maykinmedia.nl/project/open-inwoner/task/2723
Related: https://taiga.maykinmedia.nl/project/open-inwoner/task/2700
Note: the
notificaties.test.openzaakbackend does not set an auth header when sending test notifications for newly created subscriptions, which can lead to false positive error logs when testing webhooks (cf. https://sentry.maykinmedia.nl/organizations/maykin-media/issues/363204/?project=284)