ECA Patch Releases Change User Context and Access Handling

Three ECA patch releases issued on 7 September 2026 change how automated workflows resolve user context and combine access decisions. Versions 3.1.7, 3.0.15 and 2.1.24 carry the account and access changes across three supported branches, according to the project's release notes. The releases also require the executing account to hold the administer site configuration permission before the "Apply recipe" action can run.

The changes matter most on sites where ECA models run through cron, queue workers, Drush or persistent workers, or where several models contribute to the same access decision. Several fixes alter existing behaviour, and the release notes tell administrators to review the published change records before updating. Drupal.org categorises all three versions as bug-fix releases, while their release notes describe the execution and access changes as hardening.

ECA previously resolved its configured model user and session user once per PHP process and reused those values for later model executions in the same process. That could leave the session_user token reporting an account from an earlier execution during cron runs, queue workers, Drush commands or persistent workers. The new releases resolve both identities for every execution and retain a stack so nested executions can still identify the account that triggered the outer execution.

Endpoint and Views access events also now accumulate results instead of allowing each reacting model to replace the previous result. Under the earlier behaviour, the last model to execute, determined by model weight, supplied the final verdict; after the change, a forbidden result from any reacting model takes precedence regardless of execution order. Administrators who deliberately used model weight to create a broad denial followed by an exception will need to revise those conditions. The "Apply recipe" change can also silently affect existing models because ECA skips an action when access is denied rather than treating the denial as an execution error.

A separate safeguard in ECA 3.1.7 limits how many times the same event object can appear on the execution stack through the eca.max_event_occurrences container parameter. The default is ten, providing a second guard for cases where models repeatedly trigger each other without matching the repeating pattern handled by ECA's existing recursion check. Legitimate models that nest the same event more than ten levels deep may need the limit raised in a services file.

Version 3.1.7 also introduces the [htmx:source] and [htmx:request_type] tokens for headers used by htmx 4. Drupal 12.0.0-beta1 is scheduled to move core to htmx 4, while the currently tagged Drupal 12.0.0-alpha1 still uses htmx 2. Drupal 11 uses htmx 3, where both ECA tokens remain empty. The request-type token distinguishes full-page and fragment requests, while the source token identifies the selector that triggered the request.

Across the three branches, the release notes list 50 resolved issues in 3.1.7, 26 in 3.0.15 and 22 in 2.1.24. Many are backports, so those totals should be read separately rather than combined. ECA 2.1.24 supports Drupal 10.3 and Drupal 11, ECA 3.0.15 supports Drupal 11.2 and later within Drupal 11, and ECA 3.1.7 supports Drupal 11.3 and Drupal 12. The releases are separate from ECA's recent documentation on six editor-workflow recipes, which The DropTimes covered on 7 September.