Allow form URL-parameter to safely influence to which email address a submission is sent to #4650

joeribekker · 2024-09-12T10:55:14Z

Thema / Theme

Backend

Omschrijving / Description

Reference: Taiga DB-52

A form-link contains a URL-param that holds an ID (example: myform?destEmailID=78d6f1ab331
The form variabele destEmailID is used to retrieve the name and actual email address via service fetch
The form shows only the name belonging to destEmailID
The submission is sent to the email address belonging to destEmailID

2 tasks are identified to make this scenario possible.

Allow specific URL-parameters to be set as (form) variabele (ie. mark variabele as settable via URL-param)
Allow sending the registration email to be sent to a variabele (being an email address ofcourse)

Added value / Toegevoegde waarde

Allow mailing a predefined list of people via a form without exposing their email address.

Aanvullende opmerkingen / Additional context

No response

The text was updated successfully, but these errors were encountered:

joeribekker · 2024-09-12T14:46:06Z

Estimated on 4 weeks

Either the `to_emails` or the `to_email_from_variable` fields should used when registering the email backend plugin. When a variable is selected, the resulting email address will be used for mailings. When the variable doesn't contain an email address, the `to_emails` will be used as fallback.

The variable chosen in the email registration (`to_email_from_variable`) will now actually be used for the mailing. `to_emails` is used as fallback, in case that the variable doesn't return a valid email address. The variable will also be used for the payment status update mailing. If `payment_emails` is defined, these will be used as recipients. Otherwise it will use `to_email_from_variable`, and as a last resort the `to_emails`

Either the `to_emails` or the `to_email_from_variable` fields should used when registering the email backend plugin. When a variable is selected, the resulting email address will be used for mailings. When the variable doesn't contain an email address, the `to_emails` will be used as fallback.

The variable chosen in the email registration (`to_email_from_variable`) will now actually be used for the mailing. `to_emails` is used as fallback, in case that the variable doesn't return a valid email address. The variable will also be used for the payment status update mailing. If `payment_emails` is defined, these will be used as recipients. Otherwise it will use `to_email_from_variable`, and as a last resort the `to_emails`

Either the `to_emails` or the `to_email_from_variable` fields should used when registering the email backend plugin. When a variable is selected, the resulting email address will be used for mailings. When the variable doesn't contain an email address, the `to_emails` will be used as fallback.

The variable chosen in the email registration (`to_email_from_variable`) will now actually be used for the mailing. `to_emails` is used as fallback, in case that the variable doesn't return a valid email address. The variable will also be used for the payment status update mailing. If `payment_emails` is defined, these will be used as recipients. Otherwise it will use `to_email_from_variable`, and as a last resort the `to_emails`

sergei-maertens · 2024-12-27T08:24:31Z

Allow specific URL-parameters to be set as (form) variabele (ie. mark variabele as settable via URL-param)

How are you going to avoid clashes with reserved URL parameter names, like we have _start and initial_data_reference, time, submission_uuid, product, of-auth-problem, _digid-message, _eherkenning-message, _eidas-message & code? Those are currently in use, but I'm more worried about developers being limited to adding own/internal query parameters for application logic because it may affect forms/break their auto-populate if they happen to shadow a form variable like that, and those will be situations that will be cryptic to debug/reproduce.

I also see a problem that you cannot reliably make it work for all types of form variabels - how do you plan to initialize a repeating group (list of) item(s) from a query parameter? Or a nested object? Those are not simple primitive datastructures that are easily string-encoded in a query parameter.

If we're going to have to write code to implement this feature, can't we instead build on top of existing constructs we already have and buy more time to properly design a prepopulate-via-the-client feature? I mean relying on the initial_data_reference here.

* Added fieldsets to group related options together * Use a shorter form field label and describe the behaviour in the help text * Filter down the available variables to compatible data types (only strings and arrays can produce valid values) * Updated stories to provide some available variables in the context * Mark toEmails configuration field as required, since it always is * Clean up the formik hook/props usage * Ensure that the 'empty' value is normalized when calling the onChange behaviour to normalize formik data types to what the backend expects

Simplified tests by removing indirection and only set up the test data that is actually required by the test. This also uses some more ergonomic factory utilities rather than hand-wiring everything. Now new tests should have better examples to follow.

The test module is aimed at the generic registration mechanism and just 'happens' to use the email plugin. We do not need to repeat all the various cases/failure modes that are already covered by the plugin unit tests.

* Added fieldsets to group related options together * Use a shorter form field label and describe the behaviour in the help text * Filter down the available variables to compatible data types (only strings and arrays can produce valid values) * Updated stories to provide some available variables in the context * Mark toEmails configuration field as required, since it always is * Clean up the formik hook/props usage * Ensure that the 'empty' value is normalized when calling the onChange behaviour to normalize formik data types to what the backend expects

With product prefill, the premise is that the product data is personal and likely contains sensitive/private data that gives only the person with a particular BSN access. This requires the person to authenticate and then their BSN is compared with some property in the retrieved object. However, there may be 'public' data used to prefill some variables, either user defined or even form variables. Multiple people can use those objects, even without authenticating in the first place. You can now flag a prefill to not require this kind of ownership check.

* Added fieldsets to group related options together * Use a shorter form field label and describe the behaviour in the help text * Filter down the available variables to compatible data types (only strings and arrays can produce valid values) * Updated stories to provide some available variables in the context * Mark toEmails configuration field as required, since it always is * Clean up the formik hook/props usage * Ensure that the 'empty' value is normalized when calling the onChange behaviour to normalize formik data types to what the backend expects

With product prefill, the premise is that the product data is personal and likely contains sensitive/private data that gives only the person with a particular BSN access. This requires the person to authenticate and then their BSN is compared with some property in the retrieved object. However, there may be 'public' data used to prefill some variables, either user defined or even form variables. Multiple people can use those objects, even without authenticating in the first place. You can now flag a prefill to not require this kind of ownership check.

* Added tests for configuration validation * Added tests for runtime behaviour

* Added fieldsets to group related options together * Use a shorter form field label and describe the behaviour in the help text * Filter down the available variables to compatible data types (only strings and arrays can produce valid values) * Updated stories to provide some available variables in the context * Mark toEmails configuration field as required, since it always is * Clean up the formik hook/props usage * Ensure that the 'empty' value is normalized when calling the onChange behaviour to normalize formik data types to what the backend expects

With product prefill, the premise is that the product data is personal and likely contains sensitive/private data that gives only the person with a particular BSN access. This requires the person to authenticate and then their BSN is compared with some property in the retrieved object. However, there may be 'public' data used to prefill some variables, either user defined or even form variables. Multiple people can use those objects, even without authenticating in the first place. You can now flag a prefill to not require this kind of ownership check.

* Added tests for configuration validation * Added tests for runtime behaviour

With product prefill, the premise is that the product data is personal and likely contains sensitive/private data that gives only the person with a particular BSN access. This requires the person to authenticate and then their BSN is compared with some property in the retrieved object. However, there may be 'public' data used to prefill some variables, either user defined or even form variables. Multiple people can use those objects, even without authenticating in the first place. You can now flag a prefill to not require this kind of ownership check.

* Added tests for configuration validation * Added tests for runtime behaviour

Some class names and stylesheets were missing for the inline radio choices, causing the page to look janky.

When an initial data reference is present, a registration plugin must implement the ownership check.

…rence Prefilling some information/variables from the Objects API in combination with email registration is a valid use case, as requested in issue #4650 to keep email addresses private. The ownership check method must be implemented if a submission with non-empty initial_data_reference is being processed - there isn't actually anything to check since registration always sends a new email and there is no inherent update mechanism, so there's also no inherent object ownership.

joeribekker added epic Large theme and/or meta issue triage Issue needs to be validated. Remove this label if the issue considered valid. enhancement waiting for approval An estimate was made but the stakeholder still needs to approve it. labels Sep 12, 2024

joeribekker added the owner: den-bosch label Sep 12, 2024

joeribekker removed the triage Issue needs to be validated. Remove this label if the issue considered valid. label Sep 23, 2024

joeribekker added approved and removed waiting for approval An estimate was made but the stakeholder still needs to approve it. labels Nov 14, 2024

joeribekker added this to Development Dec 2, 2024

github-project-automation bot moved this to Todo in Development Dec 2, 2024

joeribekker assigned robinmolen, stevenbal and vaszig and unassigned robinmolen Dec 20, 2024

robinmolen self-assigned this Dec 23, 2024

robinmolen moved this from Todo to In Progress in Development Dec 23, 2024

joeribekker removed the epic Large theme and/or meta issue label Dec 23, 2024

robinmolen mentioned this issue Dec 24, 2024

Dynamic email registration recipients using variables #4971

Merged

10 tasks

robinmolen added a commit that referenced this issue Dec 24, 2024

🌐 [#4650] Updated translations

6d96cbc

sergei-maertens mentioned this issue Dec 27, 2024

Prepare release 3.0 #4920

Closed

38 tasks

sergei-maertens assigned sergei-maertens and unassigned stevenbal Dec 30, 2024

sergei-maertens added a commit that referenced this issue Dec 30, 2024

🌐 [#4650] Update Dutch translations

459549e

sergei-maertens added a commit that referenced this issue Dec 30, 2024

🌐 [#4650] Update Dutch translations

82f87db

sergei-maertens added a commit that referenced this issue Dec 30, 2024

✨ [#4650] Add option to skip ownership checks to options UI

98c981f

sergei-maertens added this to the Release 3.0 milestone Dec 30, 2024

sergei-maertens moved this from In Progress to Implemented in Development Dec 30, 2024

sergei-maertens added a commit that referenced this issue Dec 31, 2024

🌐 [#4650] Update Dutch translations

71b4c80

sergei-maertens added a commit that referenced this issue Dec 31, 2024

✨ [#4650] Add option to skip ownership checks to options UI

34647c5

sergei-maertens added a commit that referenced this issue Dec 31, 2024

✅ [#4650] Add tests for optional ownership check

b1f2801

* Added tests for configuration validation * Added tests for runtime behaviour

sergei-maertens added a commit that referenced this issue Dec 31, 2024

🌐 [#4650] Update Dutch translations

5db5b84

sergei-maertens added a commit that referenced this issue Dec 31, 2024

✨ [#4650] Add option to skip ownership checks to options UI

b46fa3e

sergei-maertens added a commit that referenced this issue Dec 31, 2024

✅ [#4650] Add tests for optional ownership check

fa86b04

* Added tests for configuration validation * Added tests for runtime behaviour

sergei-maertens added a commit that referenced this issue Dec 31, 2024

🌐 [#4650] Update Dutch translations

bb61f29

sergei-maertens added a commit that referenced this issue Dec 31, 2024

✨ [#4650] Add option to skip ownership checks to options UI

671145c

sergei-maertens added a commit that referenced this issue Dec 31, 2024

✅ [#4650] Add tests for optional ownership check

b8d142b

* Added tests for configuration validation * Added tests for runtime behaviour

sergei-maertens closed this as completed in #4971 Dec 31, 2024

github-project-automation bot moved this from Implemented to Done in Development Dec 31, 2024

sergei-maertens added a commit that referenced this issue Dec 31, 2024

🐛 [#4650] Fix styling of registrator screen

f8d2746

Some class names and stylesheets were missing for the inline radio choices, causing the page to look janky.

sergei-maertens added a commit that referenced this issue Dec 31, 2024

🧪 [#4650] Add regression test for failing pre-registration

cce0642

When an initial data reference is present, a registration plugin must implement the ownership check.

sergei-maertens mentioned this issue Dec 31, 2024

Fix bugs in email registraton + objects API prefill combination #4977

Merged

10 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow form URL-parameter to safely influence to which email address a submission is sent to #4650

Allow form URL-parameter to safely influence to which email address a submission is sent to #4650

joeribekker commented Sep 12, 2024 •

edited

Loading

joeribekker commented Sep 12, 2024

sergei-maertens commented Dec 27, 2024

Allow form URL-parameter to safely influence to which email address a submission is sent to #4650

Allow form URL-parameter to safely influence to which email address a submission is sent to #4650

Comments

joeribekker commented Sep 12, 2024 • edited Loading

Thema / Theme

Omschrijving / Description

Added value / Toegevoegde waarde

Aanvullende opmerkingen / Additional context

joeribekker commented Sep 12, 2024

sergei-maertens commented Dec 27, 2024

joeribekker commented Sep 12, 2024 •

edited

Loading