There is the event_log application with the Subscription model.
Define Entry type forms.response.created and emit it in createSurveyResponse
Add survey_filter to Subscription and survey to Entry
However: The whole event log application could use some rethinking. It follows the sparse table model that has been found problematic in Programme V1.
In forms, add a separate Subscription model with foreign keys to Survey and User.
NOTE: CBAC check needs to be done when notifying subscribers. If subscriptions are left around but the user no longer has access, notifications must not be sent. This may be easier with approach 2.
UI for either:
Add a toggle button in the survey editor saying Subscribe to response notifications or similar
GraphQL mutations to un/subscribe that create and remove Subscriptions
Implementation options:
event_log
application with theSubscription
model.Entry
typeforms.response.created
and emit it increateSurveyResponse
survey_filter
toSubscription
andsurvey
toEntry
forms
, add a separateSubscription
model with foreign keys toSurvey
andUser
.NOTE: CBAC check needs to be done when notifying subscribers. If subscriptions are left around but the user no longer has access, notifications must not be sent. This may be easier with approach 2.
UI for either:
Subscription
s