Skip to content

Allow customization of the 'response'/'child' query param names #1909

Description

@becky-gilbert

Summary

By default, we pass the response/child IDs as "response" and "child" in the URL query parameters for (1) external study links, and (2) exit URLs. We should keep this as the default but give researchers the option to change it to whatever they want.

Description

The fact that we don't allow customization of these parameter names is a problem because some sites and booking platforms enforce specific names or naming conventions for inbound query parameters. One example is youcanbookme (see the corresponding issue), which requires that parameter names be in all caps. Another is Google Forms, which allows you to pre-fill question responses using query parameters, but you have to use the parameter names that they provide (e.g. entry.264543955). Giving users the option to customize the response/child query parameter names would solve both of these problems.

Implementation

This would need to be another field or two on the study table, so it requires a DB migration. The field could be a dict with one or both mappings for custom name values (e.g. { response: "entry.264543955", child: "CHILD" } ). The default could be NULL/None (which means use the existing names), or it could be a dict that maps to the current/default values: { response: "response", child: "child" }. This field in the study edit/create form would not be part of the "monitored" group, which means that researchers can change these values during data collection without need re-approval.

We will also need to add the following tests for both external studies (study URL) and internal studies (exit URL):

  • Default parameter values at study creation
  • Custom parameter values at study creation: each one separately, and both
  • Changing the parameter values during study edit: custom to default and vice versa
  • Editing parameter values does not change study state (approved -> rejection)
  • Different character combinations that should be ok to use (alphanumeric characters etc.)
  • Handling/preventing malformed field values (e.g. not a dict, incorrect keys, non-string values, invalid characters)

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions