Improve FormBuilder handling of non logged in flows
We've been working with a few clients on forms that should be available to the outside world / logged out users and want to suggest some improvements to Form Builder to cater to these scenarios.
They revolve around a couple of workflows.
- Require email confirmation to view a form.
- Require email confirmation to process a form
We plan on adding an 'Anonymous users' setting to the FormBuilder settings to support this. It will be a select that allows people to choose between the above two options.
Require email confirmation to view a form
We're using this to make a 'Communication preferences' form available to non logged in users 'on demand'.
When a non logged in user visits https://example.org/civicrm/communication-preferences, they will see an email field and a message along the lines of "Enter your email below and if your email exists in our system we will send you a link to the 'Communication preferences' page".
We only send an email if the email already exists in CiviCRM. If it does not, we silently ignore it. Clicking on the checksum link will authenticate them and send them back to the same form.
This is similar in nature to the traditional checksum workflow.
Require email confirmation to process a form
We're using this, for example, to provide 'double opt in' functionality to newsletter sign up forms. And also to get users to confirm any changes to their email address.
It probably make sense to make this option configurable so it can be set
- for just logged out users
- for logged out users and logged in users if the email has changed
We think we can implement this by adding an early event listener that logs the submission, sends an email to the user asking them to confirm their email address (using the email submitted in the form) and stops the event propagation before any entities are updated.
If and when the person confirms their email by clicking a link in the email we restart the processing by dispatching the event again with the submitted data and update entities as necessary.
More thoughts
Both these measures act as a form of spam protection. Unlike the current double opt in which creates a contact before the email is confirmed (with a pending subscription), in the Require email confirmation to process a form flow, no contact is created until the email is confirmed. This should result in less spam contacts ending up in CiviCRM.
Require email confirmation to process a form probably won't play nicely with file attachments out of the box (and we think that is OK for a v1).
Not sure if Require email confirmation to process a form would make sense on a form that is doing financial transactions but we're treating that as out of scope for now (seems fine since you can't use form builder to process transactions right now any way!)
Require email confirmation to process a form is a subset of a wider workflow which is require confirmation to process a form, e.g. confirmation from staff that an update to a member profile is acceptable before being published on a website.
If we're lucky, we might be able to implement all of this an an extension but at the same time, it feels quite core and would be up for adding it to core if preferred.
Your thoughts and feedback how we can improve this proposal and any potential issues very welcome!