{"id":"6a30b9e7f7bb7cf5d2524bec","title":"2026 06 16","path":"how-to/committee/release-notes/2026-06-16","contentMarkdown":"# 16-Jun-2026 — inbox-aware email routing and Contact Us delivery [#278](https://github.com/nbarrett/ngx-ramblers/issues/278)\n\n## [build 698](https://github.com/nbarrett/ngx-ramblers/actions/runs/27590219957) — [commit 0fa5561](https://github.com/nbarrett/ngx-ramblers/commit/0fa55617496e02503b37568e37ac0013994814bf)\n\n_____\n\n> 📖 New to this feature? See [Setting up a Gmail inbox for committee replies](https://ngx-ramblers.org.uk/how-to/technical-articles/2026-05-29-gmail-inbox-setup) for the step-by-step setup guide.\n\nReworks how committee roles route email - outbound senders, inbound\nforwarding, and the Contact Us form - so the admin screens describe what\nactually happens for each group's setup: a connected Gmail inbox, a\nCloudflare catch-all, fan-out to several people, or individual personal\naddresses. Part of the Gmail inbox work in #278.\n\n## What's new for committee admins\n\n### Contact Us routing, per role\n\nEach role has a dedicated Contact Us tab controlling where contact-us form\nsubmissions for that role are sent, separate from the role's Inbound\nForwarding.\n\n- New option \"The role's own address\": contact-us is sent to the role\naddress (e.g. walks@yourdomain.org.uk) and then follows that role's\nInbound Forwarding, so it reaches the same place as the role's normal\nmail with no extra setup.\n- Automatic handling when the role uses a connected inbox: the tab\ncollapses to a short read-only note instead of a dropdown, because there\nis nothing to configure - contact-us rides the role's forwarding into the\nconnected inbox and appears grouped under the role.\n- The \"How this delivers\" summary describes the real path for each option\n(\"follows this role's Inbound Forwarding to wherever that's configured\")\nrather than assuming a connected inbox, so it is correct for groups that\nforward to personal addresses or to several recipients.\n- The Contact Us help text now lists all routing options and explains the\nconnected-inbox automatic handling.\n- The display name override and the copyable markdown contact link remain\non every role.\n\n### Inbound forwarding clarity\n\n- Connected Gmail inboxes appear as choices in a role's Inbound Forwarding.\n- Catch-all routing is described correctly even when the catch-all is a\nWorker fan-out, showing \"Multiple recipients (Worker)\" instead of wrongly\nreporting that no catch-all rule exists.\n- The \"link a member\" prompt only appears for the member's-personal-email\ntarget, where linking a member is the right action; Catchall, Custom and\nNo forwarding no longer show it.\n- A forwarding destination awaiting Cloudflare verification is shown as an\namber \"Verification needed\" notice rather than a red error.\n\n### Contact Us system role\n\n- No Contact Us tab (a role cannot contact itself).\n- Inbound Forwarding no longer offers \"Member's personal email\" (there is\nno member to link); it defaults to \"No forwarding\" and can be set to\nCustom, Multiple recipients, or Catchall.\n- The \"System role\" notice now shows the standard warning icon.\n- It cannot be deleted: the delete button is disabled with a tooltip\nexplaining it is the contact-us sender linked across the site. Other\nsystem roles (e.g. Info) are deletable.\n\n### Committee roles table\n\n- Email addresses stay on a single line instead of wrapping mid-address.\n- Name, Role and Description columns are sized so descriptions get room and\nnothing is cramped; the status columns are sized to their content and the\nsort carets no longer wrap onto a second line.\n\n### Email routing status\n\n- The \"Active\" tooltip shows the role's configured address for multi-role\nmembers, instead of one long address built by joining all of a member's\nrole names together.\n- The \"Catch-all\" and \"Multiple\" badge tooltips describe their destinations\nin the same style, e.g. \"Routed via catch-all -> 4 recipients\" and\n\"info@yourdomain.org.uk -> 4 recipients\".\n\n### Gmail inbox setup (External systems -> Mail)\n\n- The Pub/Sub setup now shows only the Google Cloud project ID; the topic\nname is hidden and defaulted internally, since the setup creates it.\n- The project ID persists when you save the configuration, with a note that\nit is not active until you Run Google Cloud setup.\n- The setup help text is reworded and no longer references the hidden topic\nfield; the success message now has a \"Google Cloud setup complete\" title\nand a tick icon.\n- The \"Clear OAuth client\" and per-mailbox \"Remove\" buttons are grey by\ndefault and red on hover; the \"Apply push\" button and the help text under\nfields have proper spacing.\n\n## Technical details\n\n- New outbound/contact-us target ForwardEmailTarget.ROLE_EMAIL, resolved\nserver-side to the role's own address without rewriting it\n(server/lib/contact-us/resolve-and-send.ts, committee.model.ts).\n- Connected-inbox detection roleForwardsToConnectedInbox() drives the\nContact Us collapse and forces contactUsTarget to ROLE_EMAIL so the saved\nvalue matches the displayed behaviour (committee-member.ts).\n- catchAllExists()/catchAllSummary() and catchAllTooltipDestination()\nrecognise Worker catch-alls; the \"not yet configured\" status is gated to\nthe member-email target only (committee-member.ts, email-routing-status.ts).\n- The Active badge tooltip uses roleEmailFor(role) (configured email,\nfalling back to type@domain) for consistency with the routing status\nlogic; removed the unused workerScriptNameFor() method\n(committee-settings.ts).\n- Roles table switched to natural (auto) layout with a non-wrapping email\ncell and content-sized status columns (committee-settings.ts).\n- Server Cloudflare email-routing endpoints share a single asyncRoute\nwrapper and HttpError type, with a shared pre-flight that creates and\nreports unverified forwarding destinations (server/lib/shared/async-route.ts,\nserver/lib/shared/http-error.ts, cloudflare-email-routing-routes.ts).\n- Client error display standardised via extractErrorMessage; verification\n-pending responses shown as an amber notice.\n- New migration 20260616000000-update-committee-contact-us-help upserts the\nrefreshed committee-contact-us-help content text so it updates on every\nenvironment at deploy; default-content.ts kept in sync.\n- StoredValue keys renamed to match their kebab on-screen values and sorted,\nwith no behaviour change (ui-actions.ts and consumers).\n- Gmail inbox settings: Project ID binds to googleInbox.pubsubProjectId so it\npersists on Save; topic-name field removed and defaulted; runSetup reads the\nproject ID from config; statusTitle drives the success alert title + icon\n(system-gmail-inbox-settings.ts).\n- New btn-grey-danger style (grey default, red hover) applied to Clear OAuth\nclient and Remove (buttons.sass and the two external-systems components).\n- Committee roles delete restricted to non-Contact-Us roles via\nisContactUsSystemRole(); Contact Us shows a disabled delete with tooltip\n(committee-settings.ts).","contentHtml":"

16-Jun-2026 — inbox-aware email routing and Contact Us delivery #278

\n

build 698 — commit 0fa5561

\n
\n
\n

📖 New to this feature? See Setting up a Gmail inbox for committee replies for the step-by-step setup guide.

\n
\n

Reworks how committee roles route email - outbound senders, inbound\nforwarding, and the Contact Us form - so the admin screens describe what\nactually happens for each group's setup: a connected Gmail inbox, a\nCloudflare catch-all, fan-out to several people, or individual personal\naddresses. Part of the Gmail inbox work in #278.

\n

What's new for committee admins

\n

Contact Us routing, per role

\n

Each role has a dedicated Contact Us tab controlling where contact-us form\nsubmissions for that role are sent, separate from the role's Inbound\nForwarding.

\n\n

Inbound forwarding clarity

\n\n

Contact Us system role

\n\n

Committee roles table

\n\n

Email routing status

\n\n

Gmail inbox setup (External systems -> Mail)

\n\n

Technical details

\n\n"}