Contrib.social

Provide an API for prepopuating data on Webform submission forms

Open on Drupal.org →
Created on 18 January 2024, 8 months ago
Updated 8 August 2024, about 1 month ago

Problem/Motivation

In my pursuit of dynamically prepopulating data on Webform submission forms, I sought a solution that allowed site builders to configure a "mapping source" through the user interface, aiming for a seamless and consistent experience. I aimed to steer clear of hardcoding and circumventing challenges through extensive form alterations. During my exploration, I encountered the Webform Pre-populate → module, which adeptly articulates the drawbacks of the otherwise useful query-based prepopulate feature:

Passing values as plain URL parameters are disclosing information in some cases:

  • When they are passed over http
  • Values can be stored in the server logs
  • Values can be stored in analytics tools (e.g. Google Analytics)

Since GDPR, deleting these data could be something hard to tackle.

Steps to reproduce

Consider rendering a single instance of a Webform submission form on /node/[nid]/foo and dynamically prepopulating data on this form from the Node object obtained from the route parameter. This could be achieved by leveraging tokens. Imagine extending this logic to work universally, enabling the specification of Node dependencies for the feature responsible for prepopulating data on a given Webform type.

Proposed resolution

To address these challenges, I propose the introduction of a new event that enables contrib modules to prepopulate data on Webform submissions from diverse sources, extending beyond query request parameters. This new API would empower modules to make context-based decisions on the source of data prepopulation. Given that a Webform submission form may be rendered in various contexts, such as blocks, this approach allows for flexibility and adaptability.

As a bonus, the new API would allow passing PII data around in query parameters because contrib/custom modules could encrypt and decrypt query parameter values when needed.

Remaining tasks

User interface changes

API changes

A new event gets introduced.

Data model changes

✨ Feature request
Status

Active

Version

6.2

Component

Code

Created by

🇭🇺Hungary mxr576 Hungary

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @mxr576
  • Merge request !396Introduce PrepopulateDataOnWebformSubscriptionEvent → (Open) created by mxr576
  • Open in Jenkins → Open on Drupal.org →
    Core: 10.1.4 + Environment: PHP 8.2 & MySQL 8
    last update 8 months ago
    536 pass
  • Pipeline finished with Success
    8 months ago
    Total: 1829s
    #79392
  • Status changed to Needs review 8 months ago
  • Comment 8 months ago →
    🇭🇺Hungary mxr576 Hungary
  • Comment 8 months ago →
    🇭🇺Hungary mxr576 Hungary
  • Status changed to Closed: won't fix 5 months ago
  • Comment 5 months ago →
    🇺🇸United States jrockowitz Brooklyn, NY

    I am very hesitant to support or implement any new APIs. I think this type of API needs to be provided by a contributed module

  • Status changed to Active about 2 months ago
  • Comment about 2 months ago →
    🇭🇺Hungary mxr576 Hungary

    I have seen your answer Jacob, my first and most important question: Do you have a practical suggestion for how a contrib/custom code could add this functionality? Because based on my proposed change it would be only possible by overriding and subclassing \Drupal\webform\WebformSubmissionForm which I would avoid due to multiple potential maintenance traps in the road ahead...

    I am very hesitant to support or implement any new APIs.

    The other question is why are you...? This project is still active and growing, DX should become better as well, not just the site builder experience. Actually, with this new API we can potentially serve multiple personas.

  • Pipeline finished with Success
    about 2 months ago
    #232019
  • Comment about 2 months ago →
    🇭🇺Hungary mxr576 Hungary

    Because based on my proposed change it would be only possible by overriding and subclassing \Drupal\webform\WebformSubmissionForm which I would avoid due to multiple potential maintenance traps in the road ahead...

    I also checked what calls \Drupal\webform\WebformSubmissionForm::prepopulateData() and it is \Drupal\webform\WebformSubmissionForm::buildForm() so we are not closer with that either... unless we try to add this feature via a form alter which is meh...

  • Comment about 1 month ago →
    🇺🇸United States ChristophWeber

    Just stumbling over this...
    I think such an API would be powerful and belongs into webform itself, not a separate module. @jrockowitz I fully understand your hesitance to add new APIs, that makes total sense, but this one would add quite a few new opportunities to webform that justify the exception.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024