Change Details

In order to add support for tracking tools, we will need some code to verify that certain actions are valid, e.g., whether a user can add a certain tracking tool to an event. This code would run some basic validation, and then defer to each tool for more specific validation. For the P&E dashboard, this would involve calling the endpoints with the `dry_run` parameter (see task description of T302584). If this validation passes, the operation would be authorized, and when it's committed, we would only expect unpredictable runtime errors like network issues that are generally not caused by user actions (i.e., 5xx, not 4xx). Note that even before this validation runs, we should validate the value entered by the user in the registration form (or API endpoint) to make sure that it represents a known tracking tool. Said logic is already in place, and is not in scope for this task. The validation checks described here already assume that the user chose a valid and supported tracking tool. ===Acceptance criteria=== - The validation should run when any of these happen: -- Enabling an event registration -- Updating an event registration -- Disabling an event registration -- Changing the list of participants (add self, remove self, remove many, change visibility) - For the P&E dashboard, this should call the available endpoints with the `dry_run` parameter.

In order to add support for tracking tools, we will need some code to verify that certain actions are valid, e.g., whether a user can add a certain tracking tool to an event. This code would run some basic validation, and then defer to each tool for more specific validation. For the P&E dashboard, this would involve calling the endpoints with the `dry_run` parameter (see task description of T302584), but that's not in scope for this task, which is only aimed at writing the general logic. If the validation passes, the operation would be authorized, and when it's committed, we would only expect unpredictable runtime errors like network issues that are generally not caused by user actions (i.e., 5xx, not 4xx). Note that even before this validation runs, we should validate the value entered by the user in the registration form (or API endpoint) to make sure that it represents a known tracking tool. Said logic is already in place, and is not in scope for this task. The validation checks described here already assume that the user chose a valid and supported tracking tool. ===Acceptance criteria=== - The validation should run when any of these happen: -- Enabling an event registration -- Updating an event registration -- Disabling an event registration -- Changing the list of participants (add self, remove self, remove many, change visibility) - Out of scope: -- Anything user-facing -- A concrete implementation of the logic for the P&E dashboard

In order to add support for tracking tools, we will need some code to verify that certain actions are valid, e.g., whether a user can add a certain tracking tool to an event. This code would run some basic validation, and then defer to each tool for more specific validation. For the P&E dashboard, this would involve calling the endpoints with the `dry_run` parameter (see task description of T302584), but that's not in scope for this task, which is only aimed at writing the general logic. If thise validation passes, the operation would be authorized, and when it's committed, we would only expect unpredictable runtime errors like network issues that are generally not caused by user actions (i.e., 5xx, not 4xx). Note that even before this validation runs, we should validate the value entered by the user in the registration form (or API endpoint) to make sure that it represents a known tracking tool. Said logic is already in place, and is not in scope for this task. The validation checks described here already assume that the user chose a valid and supported tracking tool. ===Acceptance criteria=== - The validation should run when any of these happen: -- Enabling an event registration -- Updating an event registration -- Disabling an event registration -- Changing the list of participants (add self, remove self, remove many, change visibility) - Out of scope: -- Anything user-facing -- A concrete implementation of the logic for the P&E dashboard - For the P&E dashboard, this should call the available endpoints with the `dry_run` parameter.