Pre-filling using URL parameters

[latin-panda]

Description

Support pre-filling form fields using URL parameters with XPath syntax, such as &d[/data/uuid]=foo, to match the functionality already available in Enketo. This feature would allow seamless pre-population of form fields (e.g., a text field named uuid) via URL query parameters.

For now, we will match the Enketo API:

• a d dictionary query parameter using bracket notation (e.g. d[/data/foo])
• each dictionary key is the full XPath path to the question to populate
• only element paths in the primary instance can be set this way

Defaults should replace any literal values in the primary instance and be set before any calculation, preload or setvalue actions are triggered. The odk-instance-first-load event should fire after.

Defaults should be ignored when an existing submission is loaded.

Form:

pre-fill using url parameter.xlsx

---

Checklist

• Does it need UI/UX design?
  • Yes. Describe the UI/UX requirements or attach a Figma link in the "Design" section.
  • No
• Does it need API design?
  • Yes. Specify the endpoints, methods, or data structures needed.
  • No
• Does it need design around state flow?
  • Yes. Outline the state flow requirements.
  • No
• Does it need a test plan?
  • Yes. Add the test plan as a comment in this task or attach the document.
  • No

---

User Stories

As a project manager I want to distribute a link to a form that autofills specific fields so that the user doesn't need to re-enter known information.

---

Design

• Figma: [Insert URL]
• Design Docs: [Insert URL]

---

Dependencies

---

Additional Notes

• Likely, Central needs to pass these parameters to Web Forms.
• Forum post describing the feature: How can I specify default values in a web form link?
• Forum post reporting the missing feature: Pre-filling using URL parameters does not work in ODK Web Forms

---

Related Issues

[garethbowen]

I'm struggling with the naming on this one, because a) it's not really documented anywhere so doesn't already have a name, and b) words like "default" and "parameter" are so overloaded as to be useless. Worse still, while "url parameters" is useful for the application itself, I think it makes sense for the vue component to ignore the URL and just take in a map of path -> value, so I suggest we have two names - one for the documentation and web application, and one for the vue component and engine.

So far I've come up with DefaultParameters for the app, and InstanceDefaults for the component.