{"id":"69fb87632d3be50e28f7c740","title":"2026 05 02","path":"how-to/committee/release-notes/2026-05-02","contentMarkdown":"# 02-May-2026 — Inbound Forwarding warnings + Committee Settings catch-all admin [closes #256](https://github.com/nbarrett/ngx-ramblers/issues/256)\n\n## [build 637](https://github.com/nbarrett/ngx-ramblers/actions/runs/25450246053) — [commit 4147694](https://github.com/nbarrett/ngx-ramblers/commit/4147694c1d909727dc0a320d1ce609f136bdcee5)\n\n_____\n\n## Part 1 — Inbound Forwarding warnings\n\nTwo alert-warning banners on the Inbound Forwarding tab, both rendered before the rule UI:\n\n- **Domain mismatch**: fires when the site's primary host (from `systemConfig.group.href`) is not under the deployed Cloudflare zone's apex domain. This catches the Winchester-style failure where a per-env `zoneId` was empty, the deploy fell back to the global `zoneId`, and rules were silently created in the wrong zone.\n- **Stale deploy**: fires when a per-env `zoneId` has been set in the staging `environments` doc but the running app's deployed `CLOUDFLARE_CONFIG` still has a different `zoneId` baked in (i.e. needs a redeploy).\n\nThe resolution chain in `cloudflare-config.ts` is unchanged; the new fields (`cloudflareZoneBaseDomain`, `primaryHost`, `perEnvironmentDbZoneId`) are added to `nonSensitiveCloudflareConfig()` purely to drive the warnings. Per-env `zoneId` is looked up by stripping the `ngx-ramblers-` prefix from `APP_NAME` and matching the `environments[]` entry.\n\nSuffix matching uses a new `isHostUnderDomain()` helper in `projects/ngx-ramblers/src/app/functions/hosts.ts` (apex or subdomain, case-insensitive, strips a leading `www.`). Spec covers the apex, subdomain, `www-prefix`, the deceptive `notngx-ramblers.org.uk` non-match, and missing inputs.\n\n## Part 2 — Manage zone catch-all rule from the Committee Settings admin\n\nToday the catch-all rule for a zone (e.g. `*@ngx-ramblers.org.uk` -> `nick.barrett36@gmail.com`) is only configurable from Cloudflare's own dashboard. This brings it into NGX so the same admin surface that manages per-role rules also handles the catch-all, and adds the worker-based fan-out for multi-recipient catch-all delivery.\n\nA new **\"Catch-all rule for `*@`\"** card sits on the Committee Members tab of Committee Settings, between the action toolbar and the role table. It shows the current state as a status badge (Disabled / Drop / Forward -> `` / Multiple recipients (Worker)) and an **Edit** button. The editor exposes an action selector with four choices and a destination input that switches shape based on the action: a single email field for Forward, an add/remove list for Multiple. Worker-backed catch-all rules pre-load their existing recipients when editing so the operator sees what's currently configured rather than starting blank.\n\nServer side adds an `updateCatchAllRule` helper that `PUT`s to `/zones//email/routing/rules/catch_all`, plus a `PUT /api/cloudflare/email-routing/rules/catch-all` route. The route resolves the request shape via a `planCatchAllRule` helper that uploads a worker named `email-fwd--catch-all` for the **Multiple** action (reusing the existing worker template machinery and `BREVO_RESEND` mode wiring from per-role workers) and tears down any previously-bound worker when switching to Drop, Disabled, or Forward. Rule names follow the existing `\" - \"` convention so they read sensibly in Cloudflare's UI alongside per-role rules.\n\nFrontend service exposes `updateCatchAllRule` which invalidates the relevant caches and pushes the new rule onto the existing `catchAllNotifications` `BehaviorSubject` so the badge refreshes after a save.\n\nNew model types: `CatchAllAction` enum, `UpdateCatchAllRequest` interface, `CatchAllResolution` interface (the latter for use by Part 3's catch-all-aware role view).\n\n727/727 frontend tests pass.","contentHtml":"

02-May-2026 — Inbound Forwarding warnings + Committee Settings catch-all admin closes #256

\n

build 637 — commit 4147694

\n
\n

Part 1 — Inbound Forwarding warnings

\n

Two alert-warning banners on the Inbound Forwarding tab, both rendered before the rule UI:

\n
    \n
  • Domain mismatch: fires when the site's primary host (from systemConfig.group.href) is not under the deployed Cloudflare zone's apex domain. This catches the Winchester-style failure where a per-env zoneId was empty, the deploy fell back to the global zoneId, and rules were silently created in the wrong zone.
    • \n
  • Stale deploy: fires when a per-env zoneId has been set in the staging environments doc but the running app's deployed CLOUDFLARE_CONFIG still has a different zoneId baked in (i.e. needs a redeploy).
    • \n
\n

The resolution chain in cloudflare-config.ts is unchanged; the new fields (cloudflareZoneBaseDomain, primaryHost, perEnvironmentDbZoneId) are added to nonSensitiveCloudflareConfig() purely to drive the warnings. Per-env zoneId is looked up by stripping the ngx-ramblers- prefix from APP_NAME and matching the environments[] entry.

\n

Suffix matching uses a new isHostUnderDomain() helper in projects/ngx-ramblers/src/app/functions/hosts.ts (apex or subdomain, case-insensitive, strips a leading www.). Spec covers the apex, subdomain, www-prefix, the deceptive notngx-ramblers.org.uk non-match, and missing inputs.

\n

Part 2 — Manage zone catch-all rule from the Committee Settings admin

\n

Today the catch-all rule for a zone (e.g. *@ngx-ramblers.org.uk -> nick.barrett36@gmail.com) is only configurable from Cloudflare's own dashboard. This brings it into NGX so the same admin surface that manages per-role rules also handles the catch-all, and adds the worker-based fan-out for multi-recipient catch-all delivery.

\n

A new "Catch-all rule for *@<baseDomain>" card sits on the Committee Members tab of Committee Settings, between the action toolbar and the role table. It shows the current state as a status badge (Disabled / Drop / Forward -> <addr> / Multiple recipients (Worker)) and an Edit button. The editor exposes an action selector with four choices and a destination input that switches shape based on the action: a single email field for Forward, an add/remove list for Multiple. Worker-backed catch-all rules pre-load their existing recipients when editing so the operator sees what's currently configured rather than starting blank.

\n

Server side adds an updateCatchAllRule helper that PUTs to /zones/<zoneId>/email/routing/rules/catch_all, plus a PUT /api/cloudflare/email-routing/rules/catch-all route. The route resolves the request shape via a planCatchAllRule helper that uploads a worker named email-fwd-<zone>-catch-all for the Multiple action (reusing the existing worker template machinery and BREVO_RESEND mode wiring from per-role workers) and tears down any previously-bound worker when switching to Drop, Disabled, or Forward. Rule names follow the existing "<Mode label> - <description>" convention so they read sensibly in Cloudflare's UI alongside per-role rules.

\n

Frontend service exposes updateCatchAllRule which invalidates the relevant caches and pushes the new rule onto the existing catchAllNotifications BehaviorSubject so the badge refreshes after a save.

\n

New model types: CatchAllAction enum, UpdateCatchAllRequest interface, CatchAllResolution interface (the latter for use by Part 3's catch-all-aware role view).

\n

727/727 frontend tests pass.

\n"}