Extension icon

TYPO3 extension form_consent

:package: Packagist | :hatched_chick: TYPO3 extension repository | :floppy_disk: Repository | :bug: Issue tracker

---

An extension for TYPO3 CMS that adds double opt-in functionality to EXT:form. It allows the dynamic adaptation of the entire double opt-in process using various events. In addition, the extension integrates seamlessly into TYPO3, for example to delete expired consents in compliance with the GDPR.

rocket

Features

---

• Custom Consent form finisher for EXT:form

• Stores all submitted form data as JSON in database

• System-dependent hash-based validation system (using TYPO3’s HMAC functionality)

• Plugin to approve or dismiss a consent

• Possibility to invoke finishers on consent approval or dismissal

• Several events for better customization

• Scheduler garbage collection task for expired consents

• Dashboard widget for approved, non-approved and dismissed consents

• Compatible with TYPO3 10.4 and 11.5 LTS

fire

Installation

---

composer require eliashaeussler/typo3-form-consent

Alternatively, you can download the extension via the TYPO3 extension repository (TER).

Once installed, make sure to include the TypoScript setup at EXT:form_consent/Configuration/TypoScript in your root template.

zap

Usage

---

Finisher

A new finisher Consent is available in the backend form editor. It saves all submitted form data in the database and sends a corresponding mail to either approve or dismiss a given consent.

The last inserted consent is populated with the finisher variable provider. It can be accessed as {Consent.lastInsertedConsent} in the .form.yaml configuration.

Example:

finishers:
  -
    options:
      table: tx_myextension_domain_model_mymodel
      mode: insert
      databaseColumnMappings:
        consent:
          value: '{Consent.lastInsertedConsent.uid}'
    identifier: SaveToDatabase

Plugin

A plugin is required for approval or dismiss of the consent. The associated page containing the plugin must then be specified in the finisher settings.

open_file_folder

Configuration

---

TypoScript

The following TypoScript constants are available:

TypoScript constant	Description	Required	Default
**plugin.tx_formconsent .persistence.storagePid **	Default storage PID for new consents	–	0
**``plugin.tx_formconsent .view.templateRootPath``* *	Path to template root for consent mail and validation plugin	–	–
``plugin.tx_formconsent .view.partialRootPath``	Path to template partials for consent mail and validation plugin	–	–
``plugin.tx_formconsent .view.layoutRootPath``	Path to template layouts for consent mail and validation plugin	–	–

Finisher options

The following options are available to the Consent finisher:

finisher options are only applied to the appropriate form. They are merged with the default template paths configured via TypoScript.

Finisher option	Description	Required	Default
``subject``	Mail subject	–	Approve your conse nt
``recipientAddress` `	Recipient e-mail address	:white_chec k_mark:	–
``recipientName``	Recipient name	–	–
``senderAddress``	Sender e-mail address	–	System default sender e-mail address
``senderName``	Sender name	–	System default sender name
**``approvalPeriod``* *	Approval period	:white_chec k_mark:	86400 (1 day), 0 = unlimited
**showDismissLink **	Show dismiss link in consent mail	–	false
**confirmationPid **	Confirmation page (contains plugin)	:white_chec k_mark:	–
``storagePid``	Storage page	–	plugin.t x_formcons ent.persis tence.stor agePid
``templateRootPaths ``	Additional paths to template root	–	–
``partialRootPaths` `	Additional paths to template partials	–	–
**layoutRootPaths **	Additional paths to template layouts	–	–

Extension configuration

The following extension configuration options are available:

Configuration key	Description	Required	Default
``persistence.exclude dElements``	Form element types to be excluded from persistence (comma-separate d list)	–	Honeypo t

writing_hand

Customization

---

The lifecycle of the entire consent process can be influenced in several ways. This leads to high flexibility in customization while maintaining high stability of the core components.

Events

PSR-14 events can be used to modify different areas in the consent process. The following events are available:

• `ApproveConsentEvent <Classes/Event/ApproveConsentEvent.php>`__

• `DismissConsentEvent <Classes/Event/DismissConsentEvent.php>`__

• `GenerateHashEvent <Classes/Event/GenerateHashEvent.php>`__

• `ModifyConsentEvent <Classes/Event/ModifyConsentEvent.php>`__

• `ModifyConsentMailEvent <Classes/Event/ModifyConsentMailEvent.php>`__

Invoke finishers on consent approval or dismissal

After a user has given or revoked consent, it is often necessary to execute certain form finishers. For example, to send an admin email or redirect to a specific page.

To achieve this, after the user gives or revokes consent, the originally completed form is resubmitted. During this resubmission of the form, the selected finishers can now be overwritten using the isConsentApproved() or isConsentDismissed() conditions in a form variant.

Requirements

The following requirements must be met for the form to be resubmitted:

1. Form variant at the root level of the form must exist

2. Form variant must redefine the finishers used

3. Conditions isConsentApproved() or isConsentDismissed() must exist in the variant

Example

The following form variant is stored directly on the root level of the form definition (that is, your .form.yaml file). It specifies the form finishers to be executed in case of successful approval by the user.

variants:
  -
    identifier: post-consent-approval-variant-1
    condition: 'isConsentApproved()'
    finishers:
      -
        identifier: EmailToReceiver
        options:
          # ...
      -
        identifier: Redirect
        options:
          # ...

In this example, an admin email would be sent after the consent has been given and a redirect to the configured confirmation page would take place.

The same behavior can be achieved in case the user revokes his consent. The condition isConsentDismissed() must then be used instead.

construction

Migration

---

0.6.x → 0.7.0

Global form settings

Form settings for Frontend requests (plugin.tx_form) are no longer included globally.

• Make sure to add the static TypoScript setup at EXT:form_consent/Configuration/TypoScript to your root template.

0.3.x → 0.4.0

Generic consent state

The current state of form consents is now represented in a more generic way.

• Database field tx_formconsent_domain_model_consent.approved was renamed to tx_formconsent_domain_model_consent.state.

  • Upgrade wizard `formConsentMigrateConsentState <Classes/Updates/MigrateConsentStateUpgradeWizard.php>`__ needs to be executed.

• Database field tx_formconsent_domain_model_consent.approval_date was renamed to tx_formconsent_domain_model_consent.update_date.

  • Upgrade wizard `formConsentMigrateConsentState <Classes/Updates/MigrateConsentStateUpgradeWizard.php>`__ needs to be executed.

  • Note: The database column is now nullable.

• `$consent->setApproved() <Classes/Domain/Model/Consent.php>`__ does no longer accept any parameters.

  • Use $consent->setState() instead.

• `$consent->getApprovalDate() <Classes/Domain/Model/Consent.php>`__ was removed.

  • Use $consent->getUpdateDate() instead.

• `$consent->setApprovalDate() <Classes/Domain/Model/Consent.php>`__ was removed.

  • Use $consent->setUpdateDate() instead.

Post-consent dismissal finishers

Custom finishers can now be executed after consent was dismissed.

• Event listener was renamed.

  • Change references to `EliasHaeussler\Typo3FormConsent\Event\Listener\InvokeFinishersListener <Classes/Event/Listener/InvokeFinishersListener.php>`__.

  • Adapt your service configuration, if needed.

• Listener method was renamed.

  • Use onConsentApprove($event) instead of __invoke($event).

• Event listener identifier formConsentInvokeFinishersOnApproveListener changed.

  • Change references to formConsentInvokeFinishersOnConsentApproveListener.

0.2.x → 0.3.0

Post-consent approval finishers

Custom finishers can now be executed after consent was approved.

• Database field tx_formconsent_domain_model_consent.original_request_parameters was added.

  • Manual migration required.

  • Database field should contain an JSON-encoded string of the parsed body sent with the original form submit request.

• Database field tx_formconsent_domain_model_consent.original_content_element_uid was added.

  • Manual migration required.

  • Database field should contain the content element UID of the original form plugin.

• Post-approval finishers can now be defined as described above.

  • Manual migration required.

  • Create form variants and configure the post-approval finishers.

`Consent <Classes/Domain/Model/Consent.php>`__ model

Form values are now represented as an instance of `JsonType <Classes/Type/JsonType.php>`__.

• Method getDataArray() was removed.

  • Use getData()->toArray() instead.

• Return type of getData() was changed to JsonType|null.

  • If you need the JSON-encoded string, use json_encode($consent->getData()) instead.

• Parameter $data of setData() was changed to JsonType|null.

  • If you need to pass a JSON-encoded string, use $consent->setData(new JsonType($json)) instead.

  • If you need to pass a JSON-decoded array, use $consent->setData(JsonType::fromArray($array)) instead.

Codebase

• Minimum PHP version was raised to PHP 7.4.

  • Upgrade your codebase to support at least PHP 7.4.

• Several classes were marked as final.

  • If you still need to extend or override them, consider refactoring your code or submit an issue.

technologist

Contributing

---

Please have a look at `CONTRIBUTING.md <CONTRIBUTING.md>`__.

gem

Credits

---

Icons made by Google from www.flaticon.com.

star

License

---

This project is licensed under GNU General Public License 2.0 (or later).