[#3098] Enabled email rerouting in every cloud environment and moved 'reroute_email' to the development modules script.

[AlexSkrypnyk]

Closes #3098

Summary

web/sites/default/includes/modules/settings.reroute_email.php now enables reroute_email in every environment except local, ci and prod. ENVIRONMENT_STAGE left the list of environments that deliver mail, and the condition lost its negation, so rerouting is the fall-through default rather than the exception; the same file adds reroute_email to $settings['config_exclude_modules'].

A stage environment runs a copy of production content, so before this change any address that database sanitization missed received real mail as soon as a cron run, a content save or a UAT session triggered one. Separately, the module's drush pm:install call sat in the MODULES fence of scripts/provision-00-enable-demo-modules.sh, whose header tells projects to replace its operations once the site stops relying on demo content - a project that follows that instruction stops installing reroute_email on every environment it rebuilds afterwards, and mail starts reaching real recipients from dev as well.

reroute_email now installs from a MODULE_REROUTE_EMAIL block in scripts/provision-10-enable-dev-modules.sh, placed ahead of MODULE_GENERATED_CONTENT so the safety net is in place before content generation creates users, and it joins Modules::DEV_MODULES so the installer keeps that script when reroute_email is the last selected member of the set. local and ci still deliver to the intended recipient, and DRUPAL_REROUTE_EMAIL_DISABLED still forces delivery on any single environment - that is the supported route for a stage site that genuinely needs to mail real people during UAT. Both provision scripts keep their local/ci/dev/stage gate, and provision.mdx now documents the resulting disagreement with the settings file over custom environment types instead of resolving it.

Before / After

BEFORE
├─ settings.reroute_email.php
│    if (!in_array($env, [LOCAL, CI, STAGE, PROD], TRUE))  enable = TRUE
│    else                                                  enable = FALSE
│
│                 local   ci    dev   stage   prod   custom
│    rerouting      off   off   ON     off     off     ON
│                                       ▲
│                                       └── delivers to real inboxes
│
└─ provision-00-enable-demo-modules.sh   (projects are told to replace it)
        drush pm:install ... redirect reroute_email robotstxt ...

AFTER
├─ settings.reroute_email.php
│    $settings['config_exclude_modules'][] = 'reroute_email';
│
│    if (in_array($env, [LOCAL, CI, PROD], TRUE))          enable = FALSE
│    else                                                  enable = TRUE
│
│                 local   ci    dev   stage   prod   custom
│    rerouting      off   off   ON     ON      off     ON
│                                       ▲
│                                       └── reroutes, like every other
│                                           cloud environment
│
├─ provision-00-enable-demo-modules.sh
│      drush pm:install ... redirect robotstxt ...
│
└─ provision-10-enable-dev-modules.sh    (exists to survive that replacement)
        #;< MODULE_REROUTE_EMAIL
        drush pm:install reroute_email
        #;> MODULE_REROUTE_EMAIL

Changes

Behaviour

• web/sites/default/includes/modules/settings.reroute_email.php: dropped ENVIRONMENT_STAGE from the environments that deliver mail and inverted the condition so rerouting is the fall-through default; added reroute_email to $settings['config_exclude_modules'] so the module cannot reach production through exported configuration.
• scripts/provision-00-enable-demo-modules.sh: removed reroute_email from the contrib drush pm:install line.
• scripts/provision-10-enable-dev-modules.sh: added a MODULE_REROUTE_EMAIL fenced block that installs the module, placed ahead of MODULE_GENERATED_CONTENT.

Installer

• .vortex/installer/src/Prompts/Handlers/Modules.php: added reroute_email to Modules::DEV_MODULES, so deselecting it removes the fenced block through File::removeTokenAsync() and the dev script is deleted only once every member of the set is deselected. The constant's docblock described the set as development and testing tools, which no longer covers an environment-aware safety module, so it now names the shared property instead.
• Fixtures under .vortex/installer/tests/Fixtures/handler_process/ regenerated with ahoy update-snapshots, including the new modules_no_devel_sdc_devel_generated_content_testmode_reroute_email scenario.

Tests

• tests/phpunit/Drupal/SwitchableSettingsTest.php: the stage case now expects enable = TRUE, and a new case covers stage with DRUPAL_REROUTE_EMAIL_DISABLED set.
• tests/phpunit/Drupal/EnvironmentSettingsTest.php: testEnvironmentAcquiaStage and testEnvironmentLagoonTest now expect enable = TRUE, and the fenced reroute_email entry was added to all 16 config_exclude_modules assertions.
• .vortex/tooling/tests/unit/provision.bats: the install assertion moved from the demo-modules block to the dev-modules block across all 13 scenarios that install development modules.
• .vortex/tooling/tests/unit/provision-enable-dev-modules.bats: added the reroute_email drush mock expectation and its output assertions to both installing scenarios, and the not-expected line to the two production-skip scenarios.
• .vortex/installer/tests/Functional/Prompts/Handlers/ModulesHandlerProcessTest.php: modules_no_reroute_email now asserts the dev script survives without the install line, modules_no_devel_sdc_devel_generated_content_testmode asserts it survives on reroute_email alone, and a new scenario asserts it is deleted only when all five members are deselected.

Documentation

• .vortex/docs/content/development/modules/contributed-modules.mdx: added the install-source bullet, flipped the stage row in the environment behaviour table, recorded the config export exclusion, and named DRUPAL_REROUTE_EMAIL_DISABLED as the supported stage UAT opt-out.
• .vortex/docs/content/development/provision.mdx: added reroute_email to the dev script's "present when" list and to the section describing it, and documented that both provision scripts skip any environment type outside local, ci, dev and stage while the settings file reroutes everything outside local, ci and prod.
• .vortex/docs/content/development/modules/README.mdx: the development provisioning and config-exclusion rows no longer describe the set as development-only.

Not included

The recorded terminal demos (.vortex/docs/static/img/provision.* and siblings) still show the old demo install line. Re-recording rebuilds the whole set with timing-dependent output, CI does not verify them, and they are re-recorded wholesale during release preparation.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Team

Run ID: b4184113-9cc2-4ff4-85cc-c9951e425c99

📥 Commits

Reviewing files that changed from the base of the PR and between 6ac76c1 and 7769c1e.

📒 Files selected for processing (1)

• .vortex/tooling/tests/unit/provision-enable-dev-modules.bats

Included review availability: Your plan provides up to 10 included reviews per hour; 0 remain after this review.

---

Walkthrough

Reroute Email moves from demo provisioning to development provisioning. Configuration exports exclude the module. Cloud environments enable rerouting by default, while local, CI, and production remain disabled. Stage can disable rerouting through DRUPAL_REROUTE_EMAIL_DISABLED.

Changes

Email rerouting and provisioning

Layer / File(s)	Summary
Environment rerouting rules web/sites/default/includes/modules/settings.reroute_email.php, tests/phpunit/Drupal/*SettingsTest.php	Rerouting is disabled for local, CI, and production. Other environments enable rerouting. Stage tests and the override case reflect the new behavior.
Development module provisioning scripts/provision-00-enable-demo-modules.sh, scripts/provision-10-enable-dev-modules.sh, .vortex/tooling/tests/unit/provision*.bats	The demo script removes reroute_email. The development script installs it separately. Provisioning tests cover the revised commands and outputs.
Installer module retention .vortex/installer/src/Prompts/Handlers/Modules.php, .vortex/installer/tests/Functional/Prompts/Handlers/ModulesHandlerProcessTest.php	reroute_email becomes a development module. Installer tests verify script preservation and removal behavior.
Provisioning and environment documentation .vortex/docs/content/development/modules/*.mdx, .vortex/docs/content/development/provision.mdx	The documentation describes installation, configuration exclusion, supported environments, stage behavior, and the override variable.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Severity of issue fixed: Medium

Merge Risk: ⚪ Minimal · up to 7769c

The updated development-provisioning expectations cover Reroute Email installation and environment-specific skip behavior, with no remaining merge-blocking risk identified.

Sequence Diagram(s)

sequenceDiagram
  participant ProvisioningScript
  participant Drush
  participant RerouteEmailSettings
  ProvisioningScript->>Drush: install reroute_email from development provisioning
  RerouteEmailSettings->>RerouteEmailSettings: evaluate environment and override
  RerouteEmailSettings-->>Drush: enable or disable rerouting

Loading

🚥 Pre-merge checks | ✅ 2 | ❌ 3

❌ Failed checks (3 warnings)

Check name	Status	Explanation	Resolution
Linked Issues check	⚠️ Warning	The PR implements the environment behavior, module relocation, DEV_MODULES membership, configuration exclusion, override, tests, and documentation for [#3098]. The raw summary does not show the requir…	Update the DEV_MODULES docblock to describe reroute_email as an environment-aware safety module. Regenerate or update the installer snapshot fixtures listed in [#3098], then verify the related tests.
Out of Scope Changes check	⚠️ Warning	Most changes support [#3098], but the demo provisioning script also adds navigation_extra_tools. That change is not included in the linked issue objectives.	Remove the navigation_extra_tools addition, or provide a linked requirement that justifies the change and add corresponding test coverage if needed.
Title check	⚠️ Warning	The title accurately mentions moving reroute_email to the development-modules script, but it incorrectly states that email rerouting is enabled in every cloud environment. Production remains configu…	Update the title to specify that rerouting is enabled by default in non-production cloud environments, including stage, while production delivery remains enabled. For example: [#3098`] Enable cloud email rerouting by default and move rerout…

✅ Passed checks (2 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	Docstring coverage is 94.44% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 18 functions across 9 files.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

Full details: Linked Issues check

Explanation

The PR implements the environment behavior, module relocation, DEV_MODULES membership, configuration exclusion, override, tests, and documentation for [#3098]. The raw summary does not show the required DEV_MODULES docblock update or installer snapshot fixture updates.

Full details: Title check

Explanation

The title accurately mentions moving reroute_email to the development-modules script, but it incorrectly states that email rerouting is enabled in every cloud environment. Production remains configured for normal email delivery.

Resolution

Update the title to specify that rerouting is enabled by default in non-production cloud environments, including stage, while production delivery remains enabled. For example: [#3098] Enable cloud email rerouting by default and move reroute_email to development modules.‌

• Fix all pre-merge checks with AI

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/3098-reroute-email-cloud

---

_{A rabbit reads each line,
The patch grows clear beneath the moon,
Small changes hop in place,
Tests guard the garden path,
Reviews bloom before the dawn.}

_{Comment @coderabbitai help to get the list of available commands.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.98%. Comparing base (9052460) to head (7769c1e).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3099      +/-   ##
==========================================
- Coverage   87.32%   86.98%   -0.35%     
==========================================
  Files         108      101       -7     
  Lines        5161     5001     -160     
  Branches       49        3      -46     
==========================================
- Hits         4507     4350     -157     
+ Misses        654      651       -3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

📖 Documentation preview for this pull request has been deployed to Netlify:

https://6a9f60a2b3782a9a564d9726--vortex-docs.netlify.app

This preview is rebuilt on every commit and is not the production documentation site.

[github-actions]

Code coverage (threshold: 90%)

  Classes: 100.00% (1/1)
  Methods: 100.00% (2/2)
  Lines:   98.59% (210/213)

Per-class coverage

Drupal\ys_demo\Plugin\Block\CounterBlock
  Methods: 100.00% ( 2/ 2)   Lines: 100.00% ( 10/ 10)

[AlexSkrypnyk]

Code coverage (threshold: 90%)

  Classes: 100.00% (1/1)
  Methods: 100.00% (2/2)
  Lines:   98.59% (210/213)

Per-class coverage

Drupal\ys_demo\Plugin\Block\CounterBlock
  Methods: 100.00% ( 2/ 2)   Lines: 100.00% ( 10/ 10)

[AlexSkrypnyk]

Code coverage (threshold: 90%)

  Classes: 100.00% (1/1)
  Methods: 100.00% (2/2)
  Lines:   98.59% (210/213)

Per-class coverage

Drupal\ys_demo\Plugin\Block\CounterBlock
  Methods: 100.00% ( 2/ 2)   Lines: 100.00% ( 10/ 10)