## Problem
Fixes#23307. Every transactional email (workspace invite, password
reset,
email verification, etc.) is delivered with an **empty body** — no
title, text,
or CTA.
## Root cause
`twenty-server` pins `@react-email/render` directly at `^1.2.3`:
```jsonc
// packages/twenty-server/package.json
"@react-email/render": "^1.2.3",
```
In 1.2.3, `render()` reads `renderToReadableStream` **before** the email
template's async Suspense boundary (i18n/locale load) has resolved. The
result
is the Suspense fallback marker instead of the real markup:
```html
<!DOCTYPE html ...><!--$!--><template></template><!--/$-->
```
This was fixed upstream in `@react-email/render@2.0.6`
(*"await stream.allReady before reading renderToReadableStream
output"*).
`twenty-emails` already resolves a 2.x render via `react-email@6.5.0`,
so the
server's direct pin was simply stale — the two were out of sync.
## Fix
Bump the direct pin to `^2.0.6` (resolves to `2.1.0`) and regenerate the
lockfile. The server's `render()` imports now use the fixed 2.x.
> Note: a `1.2.3` entry remains in `yarn.lock` — it is an internal
transitive
> pin of `@react-email/components@0.5.3`, not the server render path, so
it is
> expected and harmless.
## Verification
Rendering `SendInviteLinkEmail` through the real `render()` (Node 24)
now
returns full markup (5.7 kB) with no Suspense marker and the resolved
invite
link + workspace content, instead of the empty fallback.
A jest unit test was intentionally not added: `@react-email/render` 2.x
uses a
dynamic import that jest's CJS runtime rejects ("A dynamic import
callback was
invoked without --experimental-vm-modules") — which is exactly why the
existing
email specs mock `render`. The fix was verified with a standalone Node
script.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/23323?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
---------
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
## Problem
The automated `i18n - translations` PR (branch `i18n`) conflicts on
`twenty-emails` `.po` files on **every** cycle. Each time, the msgid
*set* is identical to main — only the entry **order** differs.
## Root cause
`twenty-emails` uses explicit message ids (`js-lingui-explicit-id`).
With lingui's default ordering, **`lingui extract` is non-idempotent for
this catalog** — two consecutive runs on identical source produce
different `.po` orderings:
```
# no source change between runs
lingui extract # run 1
lingui extract # run 2 -> ~170 lines reordered vs run 1
```
So the order produced by the `i18n-push` extract on main, the order
stored in Crowdin, and the order the `i18n-pull` bot downloads never
agree, and the translation PR re-conflicts perpetually.
`twenty-front`/`twenty-server` use hashed ids and are already idempotent
— this is isolated to emails.
## Fix
Set `orderBy: 'messageId'` in `twenty-emails/lingui.config.ts`. Verified
this makes extraction idempotent — two consecutive extracts now produce
byte-identical output.
This commit includes the one-time reorder of the existing catalogs into
the stable order. Generated `.ts` output is unchanged (already
order-independent). After merge, one push cycle syncs Crowdin to the
stable order, after which the recurring conflicts stop.
## Test plan
- `nx run twenty-emails:lingui:extract` twice → no diff on the second
run.
- `nx run twenty-emails:lingui:compile` → succeeds, generated `.ts`
unchanged.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22803?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
## Problem
Billing and workspace-suspension emails hardcoded a
`BILLING_SETTINGS_URL` constant pointing at
`https://app.twenty.com/settings/billing`. A user in
`myworkspace.twenty.com` therefore received a CTA that bounced through
the central `app` domain instead of landing on their own workspace.
Those cross-subdomain redirects are unreliable, so it's better to link
straight to the workspace.
The invite, password-reset and email-verification emails already do this
correctly by building a workspace-specific URL server-side with
`WorkspaceDomainsService.buildWorkspaceURL(...)`; the billing/suspension
senders had the `workspace` entity in scope but never used it.
## Fix
Build the billing settings URL server-side and pass it into the
templates as a `link` prop, mirroring the existing pattern:
- **Templates** now take a `link` prop instead of the hardcoded
constant: `billing-trial-ending`, `billing-trial-converting`,
`billing-subscription-renewing`, `warn-suspended-workspace`.
- **`BillingReminderService`** and **`CleanerWorkspaceService`** build
`buildWorkspaceURL({ workspace, pathname:
getSettingsPath(SettingsPath.Billing) })` and thread it through.
- Wired `WorkspaceDomainsModule` into both NestJS modules; deleted the
now-unused `billing-settings-url.constant.ts`; updated the reminder unit
test.
This also fixes **self-hosted** deployments, which previously got the
same wrong hardcoded `app.twenty.com` link.
### Intentionally unchanged
- `clean-suspended-workspace` keeps its central-domain "start a new
workspace" CTA — that workspace is already deleted, so its subdomain no
longer resolves.
- `password-update-notify` (not a billing email) still uses
`getBaseUrl()`; the workspace entity isn't readily loaded there. Can be
a follow-up.
## Testing
Extended `billing-reminder.service.spec.ts` to assert the
workspace-specific `link` is threaded into the email. Note: local
`typecheck`/tests could not be run because the sandbox proxy repeatedly
dropped `yarn install` mid-fetch; the diff was reviewed line-by-line and
import paths verified against the actual `twenty-shared` exports and
module wiring. CI will provide the authoritative check.
https://claude.ai/code/session_01QsgNd4SWdcRkPFyrnCgj2b
---
_Generated by [Claude
Code](https://claude.ai/code/session_01QsgNd4SWdcRkPFyrnCgj2b)_
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22401?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
## Why
We currently rely on Stripe's automated trial-ending email. It misfires:
the global "remind 7 days before trial ends" setting lands the reminder
on **signup day** for the 7‑day no‑card trial, and the "your card will
be charged" copy makes no sense for a trial with no card. This replaces
it with our own honest, well‑timed, Twenty‑branded emails.
## 🔒 Safety — these emails are OFF by default
Because these reach real customers, the whole feature is gated behind a
kill‑switch that **defaults to `false`**:
- **`BILLING_REMINDER_EMAILS_ENABLED` (default `false`)** — checked
**both** at cron registration **and** on every job run (defense in
depth), so the emails can never be sent inadvertently (not on deploy,
not in staging, not via a stray trigger). They only go out once an
operator explicitly opts in.
- Also gated on `IS_BILLING_ENABLED` (cloud‑only; self‑hosters
unaffected).
- In non‑prod the email driver is typically `logger`, so even if enabled
there, nothing is actually sent.
A unit test asserts that with the switch off, **zero** emails are
produced.
## What it does
A daily cron (`0 8 * * *`) sends three honest, Twenty‑branded emails:
| Plan | Email | When |
|---|---|---|
| No‑card trial (7d) | "Add a card to keep your data" | **1 day before**
trial ends |
| Card‑on‑file trial (30d) | Upcoming‑charge heads‑up (cancel in one
click) | **7 days before** first charge |
| Yearly subscription | Renewal reminder (no surprise) | **7 days
before** each renewal |
- **Monthly renewals get no reminder** (avoids noise) — only the first
charge and annual renewals do.
- Branches no‑card vs with‑card on the customer's payment‑method flag
(with a trial‑duration fallback), so someone who adds a card mid‑trial
correctly gets the charge heads‑up instead of the add‑a‑card one.
- **Idempotent** per `(workspace, boundary date)` via workspace‑level
user vars — yearly reminders re‑fire each period, but the daily cron
never double‑sends.
- Offsets are configurable via new `BILLING_*_REMINDER_DAYS_BEFORE`
variables.
Also **warms up the tone** of the existing suspended / deleted workspace
emails (less robotic, fair, loss‑aversion framing) — these already act
as the "come back or lose your data" win‑back, so no extra win‑back
email was added.
## Rollout
1. Merge.
2. Disable Stripe's automated trial/renewal customer emails in the
Stripe dashboard.
3. Review copy/timing, then set `BILLING_REMINDER_EMAILS_ENABLED=true`
to turn the cron on.
## Notes for reviewers
- **i18n:** new English strings render via Lingui's msgid fallback;
translation catalogs are intentionally **not** included to keep the diff
focused (the repo extracts translations via its standard periodic
`lingui extract` sync — `main` already carries catalog drift). Diff is
18 code files.
- **Recipients:** reminders go to all workspace members, consistent with
the existing suspension emails. Happy to scope the charge‑related ones
to billing admins if preferred.
- **Follow‑ups discussed:** in‑app trial banner, loss‑aversion with real
record counts, and failed‑payment dunning are the higher‑leverage
conversion levers beyond this.
## Test plan
- [x] `typecheck` (twenty-server, twenty-emails)
- [x] oxlint type‑aware + oxfmt
- [x] Unit tests: no‑card path, with‑card path, idempotency, yearly
renewal, billing‑disabled, **kill‑switch off → no send** (6/6 green)
- [ ] Manual: set the flag on a staging instance with `logger` driver
and confirm the right email is logged at each boundary
https://claude.ai/code/session_0147ujzHv1X4vzimf4iGbnT4
---
_Generated by [Claude
Code](https://claude.ai/code/session_0147ujzHv1X4vzimf4iGbnT4)_
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22186?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
## Context
Closes#21522
Large values in the dashboard **Number** widget are always abbreviated
(e.g. `1300090` → `1.3m`) with no way to display the full number.
Following a discussion with the core team who were interested in this
feature
(https://discordapp.com/channels/1130383047699738754/1509604545381142649)
, this adds a **Format** option in the **Style** section of the Number
(aggregate chart) widget, letting users choose between **Short**
(abbreviated, current behavior) and **Full** (complete number with
thousand separators).
Only the displayed value of the Number widget is affected — axes, labels
and tooltips of other chart types are intentionally left untouched.
## What's inside
**Server**
- New `ChartNumberFormat` GraphQL enum (`SHORT` / `FULL`), following the
`AxisNameDisplay` pattern
- The existing — and previously unused — `format` field on
`AggregateChartConfigurationDTO` is now typed with this enum and
validated with `@IsEnum`
- The dashboard AI tool schema (`widget.schema.ts`) accepts the new
`format` option
- Regenerated GraphQL types and the `twenty-client-sdk` metadata client
to reflect the enum
**Front**
- New **Format** setting in the Style section of the Number widget
settings, with a Short/Full selection dropdown (same pattern as the Axis
name setting)
- `transformAggregateRawValueIntoAggregateDisplayValue` takes an
optional `numberFormat`:
- `FULL` → full number via `formatNumber` (currency values keep up to 2
decimals)
- `SHORT` → abbreviated via `formatToShortNumber`
- not set → behavior unchanged (currency short, number full), so
existing widgets and the record table/board footers render exactly as
before
## Screenshots
| Full UI Look |
<img width="1917" height="955" alt="Twenty_Showcas_FullShort"
src="https://github.com/user-attachments/assets/05d05779-395d-4e1a-8ff0-964f6fbef182"
/>
| Menu UI Look |
<img width="291" height="308" alt="Screenshot_2"
src="https://github.com/user-attachments/assets/82b5a1de-32fe-46ec-a9b8-add11ab4c6cd"
/>
## Tests
- Extended `transformAggregateRawValueIntoAggregateDisplayValue` unit
tests with SHORT/FULL cases for currency and number fields
- Updated the page-layout-widget creation/update integration tests and
snapshots to use `ChartNumberFormat.SHORT`
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21521?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
## What this does
Resolves the remaining esbuild security alerts on packages we own, and
upgrades the repo to **Vite 8** (which drops esbuild entirely in favour
of rolldown/oxc).
### 1. esbuild → `^0.28.1` (security)
- Raised the declared `esbuild` floor in `twenty-sdk` and the
logic-function common-layer (both were `^0.25.0`, which can only resolve
to a vulnerable version). These are our packages, so this is just
declaring the patched version — clears Dependabot **#1467** and
**#1468**.
### 2. Vite 7 → 8
- Bumped `vite` to `^8` in the 5 packages that declare it, and
`@vitejs/plugin-react-swc` to `^4.3.1` (the only plugin that needed a
bump for Vite 8; everything else already supports it).
- `twenty-front` keeps esbuild minification, so esbuild is now an
explicit (patched) devDependency there — Vite 8 no longer ships it.
### Two Vite-8 fallout fixes (bundler internals changed)
- **Storybook tests:** added React to `optimizeDeps.include` so Vite's
dep optimizer doesn't re-bundle React mid-run and break in-flight
imports in browser-mode tests.
- **`hex-rgb`:** it's ESM-only and broke rolldown's CJS interop (a
default import resolved to the wrong thing under jest). Replaced its one
use with a tiny inline hex→rgb parse and dropped the dependency.
## Verified
Vite resolves to a single `8.0.16` with no esbuild in its tree. Builds
pass on Vite 8/rolldown: `twenty-front` production build, the SDKs, and
Storybook; the previously-failing front and storybook test jobs now
pass; `yarn install --immutable` is clean.
## Note
This doesn't close root alert **#1469** — esbuild is still pulled by
other third-party tools (storybook, tsx, lingui, zapier, etc.) that
haven't shipped a patched release. The vulnerable code path (esbuild's
dev server) isn't used here, so that one is best dismissed as
not-affected.
## Context
AWS Inspector flags the `prod-twenty` image (built from current main)
with 16 findings, and Dependabot alert 174 flags esbuild. This PR fixes
the OpenSSL scanner findings and the esbuild CVE. The typeorm bump
(CVE-2025-60542) was **pulled out of this PR** — see "typeorm status"
below.
## Changes
### Strip `/usr/local/include/node` from runtime stages
(`twenty-server`, `twenty-app-dev`)
15 OpenSSL CVEs (June 9 advisory, incl. CRITICAL CVE-2026-34182) are all
detected via **Node's bundled OpenSSL dev headers**: 3 GENERIC
`openssl/openssl` 3.5.6 detections per CVE at
`/usr/local/include/node/openssl/archs/linux-x86_64/{asm,asm_avx2,no-asm}/include/openssl/opensslv.h`.
The headers are only needed by node-gyp and native addons are compiled
in the build stages — nothing compiles at runtime. Dropping them clears
all 45 detection instances and permanently ends this class of finding
(third occurrence: 3.5.5 → 3.5.6 → 3.5.7). None of these CVEs are
reachable through Node (no CMS/PKCS#7 API, `pfx` is operator-supplied,
Node's QUIC uses ngtcp2, ASN.1 issues need ~2GB inputs).
**Follow-up (~June 17, 2026):** the `node` binary itself still
statically links OpenSSL 3.5.6 — invisible to the scanner after this PR
and unreachable in practice, but the real fix is bumping the pinned
`node:24-alpine` digest once the [announced June 17 Node.js security
releases](https://nodejs.org/en/blog/vulnerability/june-2026-security-releases)
ship a 24.x linking OpenSSL ≥ 3.5.7 (verify via
`deps/openssl/openssl/VERSION.dat` on the release tag — 24.16.0 is still
on 3.5.6). A dated TODO sits next to the cleanup in the Dockerfile.
### esbuild dev-server CORS CVE (Dependabot alert 174,
GHSA-67mh-4wv8-2f99)
`@lingui/cli@5.1.2` (pins `esbuild ^0.21.5`) was the last parent
resolving a vulnerable esbuild (≤ 0.24.2 lets any website send requests
to the dev server and read responses). Instead of a resolution override,
this bumps the lockstepped **lingui suite 5.1.2 → 5.9.5** (within-major;
lingui adopted `esbuild ^0.25.1` in 5.4.1), which:
- removes `esbuild@0.21.5` and all its platform packages from the
lockfile with no forced ranges;
- drops the `@lingui/core` lockstep resolution (its comment marked it
droppable on the next coordinated lingui bump — the tree now resolves a
single `@lingui/core@5.9.5`);
- `@lingui/swc-plugin` stays at `^5.11.0` (peers on `@lingui/core: 5`;
its 6.x line targets lingui 6).
**lingui 5.9.5 behavioral fallout handled here:**
- Translation functions now **throw without an active locale** (5.1.2
fell back silently). The global `i18n` singleton that backs server-side
`` t`…` `` calls only had a messages compiler set, never an activated
locale → activate the source locale in `I18nService.loadTranslations()`,
mirrored in the server jest setup (unit tests bypass Nest bootstrap).
- `msg`/`t` placeholders are now strictly typed (reject
`null`/`undefined`/`unknown`) → one server call site and 16 twenty-front
files adapted with minimal nullish-coalescing fixes that preserve
rendering.
- `.po`/compiled-catalog churn from the new extractor/compiler
(reference reordering, sorted keys — verified content-identical on
unchanged `.po` inputs) is intentionally not committed: the scheduled
i18n workflows regenerate those.
## typeorm status (pulled out)
typeorm 0.3.20 → 0.3.26 was originally in this PR but **made workspace
metadata sync intermittently lossy**: `example-app-postcard` failed
twice with a *different* field missing from the synced PostCard object
each run, and one integration shard's `DataSeedWorkspaceCommand` died
with "Could not find flat entity with universal identifier …" — versus
zero such failures on recent main. Local runs (db reset + seed, group-by
integration suite 19/19) pass, so it is a nondeterministic
CI-load-sensitive regression that needs dedicated debugging (typeorm
changed LIMIT/OFFSET 0 semantics, lazy count for `getManyAndCount`,
upsert WHERE construction, and topological-sort internals in that
range). The resolutions comment documents this as the blocker;
CVE-2025-60542 is MySQL-driver-only (`sqlstring`), so Postgres-only
Twenty is not exposed in the meantime.
## Verification
- `npx nx typecheck twenty-server` / `twenty-front` — clean (no cache)
- `npx nx test twenty-server` — full suite green
- `lingui:extract` + `lingui:compile` — clean for twenty-server /
twenty-emails / twenty-front
- `oxfmt --check` — clean for both packages
- Lockfile diff: lingui 5.9.5 entries, `esbuild@0.21.5` +
`@esbuild/*@0.21.5` platform packages removed, no typeorm changes
## What
Clears **all 9 High `next` Dependabot alerts** (incl.
GHSA-26hh-7cqf-hhc6) in twenty-emails — via a parent bump, no
resolutions.
All 9 traced to a stale **`next@16.0.10`** pulled by
`@react-email/preview-server` 5.x. The latest preview-server 5.x still
ships a vulnerable next (16.1.7 < 16.2.6), so bumping it alone wouldn't
help. **react-email 6.x** is a rewrite that no longer depends on next or
on a separate preview-server.
- bump `react-email` `5.1.0` → `6.5.0`
- remove the obsolete `@react-email/preview-server` devDependency
- add `@react-email/ui` `6.5.0` devDependency
### Why `@react-email/ui` (the CI fix)
react-email 6's `email dev` preview server loads its UI from
`@react-email/ui`, and **prompts to install it interactively** if
missing — which hangs the `emails-test` CI job (no TTY), so the server
never starts and the `/preview/test.email` smoke check fails. Pinning
`@react-email/ui` makes `email dev` start non-interactively.
### Net effect on `next`
The vulnerable `16.0.10` is gone. `@react-email/ui@6.5.0` pulls
**`next@16.2.6`** — the **patched** version (≥ every current next
advisory fix), so all 9 alerts clear and **no vulnerable next remains**.
## Notes
- `react-email` and `@react-email/ui` pinned to exact `6.5.0` (matching
the prior react-email pin) because the `6.6.0` line was published today
and is still registry-quarantined.
- react-email is a dev-only preview tool; CI builds emails via `vite` +
typecheck.
## Verification
- No `next < 16.2.6` in `yarn.lock`
- `nx build` + `nx typecheck` twenty-emails
- `email dev -d src/emails -p 4001` starts non-interactively and serves
`/preview/test.email` → HTTP 200 (reproduces the emails-test check, now
passing)
- `yarn install --immutable` clean
## Closes#19785
In-app management of **server-level admin rights**
(`canAccessFullAdminPanel`, `canImpersonate`) so self-hosters no longer
need raw SQL + a Redis flush + restart to grant access.
> **Draft** — feature complete; `/code-review` + `/security-review` run
and addressed.
### Background
`AdminPanelGuard` / `ServerLevelImpersonateGuard` read
`request.user.{canAccessFullAdminPanel,canImpersonate}`, hydrated each
request from `CoreEntityCacheService.get('user', …)` (local 30-min +
Redis no-TTL). The cache was only invalidated on soft-delete, so a raw
`UPDATE core."user"` never took effect. The **first** signup auto-gets
both flags; every subsequent admin previously needed raw SQL.
### UX
- **Admin Panel → General → Administrators**: a read-only overview of
every user with server-level access; each row links to that user's admin
page.
- **Find anyone** via the user search (Recent Users) — available to full
admins and impersonators — then open their **admin user page**.
- On the user page, an **"Administrator access"** card (gated on
`canAccessFullAdminPanel`) has two toggles — *Full admin panel access*
and *Impersonation* — that work for **any** user (a user with no access
shows both off). Mirrors how **Impersonate** already works (find user →
user page → act). Each change opens a confirm dialog with a **2FA code**
field; the last full admin's toggle is disabled.
### Backend / security
- **Cache fix** — invalidate the user entity cache on committed user
updates (not just soft-delete) so privilege changes propagate (~100 ms,
cluster-wide) with no restart.
- `getServerAdmins` query + `updateServerAdminAccess` mutation (any
`targetUserId`), gated on `canAccessFullAdminPanel`.
- `NoImpersonationGuard` on both — an impersonated full-admin session
can't be used to escalate an impersonator.
- Fresh **2FA TOTP step-up** (enrolled+verified method **and** a fresh
code; genuine 2FA errors surface; dev-skip on trusted `NODE_ENV`).
- **Last-admin lockout** in a transaction with a pessimistic row lock
(no TOCTOU).
- **Email-to-all-admins + affected user** (rendered once per locale),
structured log, audit event-log emit.
- **Authorization**: the read-only `userLookupAdminPanel` +
`adminPanelRecentUsers` lookups now accept `canAccessFullAdminPanel OR
canImpersonate` (new `AdminPanelOrImpersonateGuard`), so a full admin
without impersonate can still find users to manage.
Workspace/impersonation queries stay impersonate-gated.
### Reviews
- `/code-review` (max effort): 3 security findings
(impersonation-escalation sink, lockout TOCTOU, step-up accepting
PENDING 2FA) — **all fixed**. `/simplify`: applied. `/security-review`:
**no high/medium vulnerabilities**.
### Follow-ups (not in this PR)
- Unit tests for `AdminPanelServerAdminService` + a frontend test.
- Point the self-host troubleshooting docs at the new UI.
- OTP retry UX: `ConfirmationModal` closes on confirm, so a wrong code
needs a reopen (kept to reuse the existing modal; no new pattern).
### Notes for reviewers
- `generated-admin/graphql.ts` entries were hand-added to match codegen
output (admin codegen needs a running server); re-run `nx
graphql:generate twenty-front --configuration=admin` to confirm parity.
- First-admin bootstrap (first signup) is unchanged.
---------
Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>
## What
Clears **all 14 High `minimatch` ReDoS alerts** (GHSA-7r86-cg39-jmmj,
GHSA-23c5-xmqv-rm74, GHSA-3ppc-4f35-3m26) in the root tree — **by
bumping the actual parent dev tools, with no `resolutions`/overrides**.
Each parent that pinned a vulnerable minimatch is upgraded so the
patched version resolves naturally.
| Vulnerable minimatch | Pinned by | Fix |
|---|---|---|
| 10.0.3 | `@microsoft/api-extractor` 7.55.1 | → 7.58.7 (in-range
refresh) → minimatch 10.2.3 |
| 3.1.2 | `@stoplight/spectral-core` 1.20.0 | → 1.23.0 (in-range
refresh) → minimatch ^3.1.4 |
| 3.0.8 | `vite-plugin-dts` 3.8.1 → api-extractor 7.43.0 | bump to
`^4.5.4` (already used elsewhere here) → minimatch 10.2.3 |
| 4.2.3 | `graphql-config` 4.5.0 via `@graphql-codegen/cli` ^3.3.1 |
bump cli to `^5.0.7` → graphql-config 5.1.6 → minimatch ^10 |
| 9.0.3 | `zapier-platform-cli` ^15.4.1 | bump to `^19.0.0` |
| 7.4.6 | `verdaccio` 6.5.2 → `@verdaccio/core` 8.0.0-next | refresh to
6.7.2 → core 8.1.1 → minimatch 7.4.9 |
All six are **build/test tooling** — the ReDoS exposure is build-time,
never shipped to users.
## Verification
- ✅ Every resolved `minimatch` in `yarn.lock` is now ≥ its patched floor
(3.1.5 / 7.4.9 / 9.0.9 / 10.2.3+). No `resolutions` added.
- ✅ `nx build`: twenty-shared, twenty-ui, twenty-ui-deprecated,
twenty-emails (validates vite-plugin-dts v4)
- ✅ twenty-zapier: typecheck + build + `zapier validate` (35/35 checks
pass; cli 19 + core 15.5.1)
- ✅ twenty-front: typecheck; `graphql:generate` with codegen cli 5
produces **byte-identical** output (no generated-file changes in this
PR)
- ✅ `yarn install --immutable` clean
## Notes
- The large `yarn.lock` diff is expected: major bumps to codegen (3→5),
zapier-cli (15→19), and vite-plugin-dts (3→4) cascade through dev-tree
transitives (net −1244 lines after dedup).
- `zapier-platform-core` (runtime) intentionally left at 15.5.1 — only
the CLI (dev tool) carried the vulnerable minimatch; `zapier validate`
flags only a non-blocking "consider upgrading core" suggestion.
- codegen plugins (`typescript`/`typescript-operations`) left at v3:
they run fine under cli 5 and produce identical output, so the minimal
change is just the cli bump.
**1. Shared Lingui factory in `twenty-shared`**
- Extracted `createI18nInstanceFactory` into
`packages/twenty-shared/src/i18n/create-i18n-instance-factory.ts` so
every package gets the same per-render Lingui bootstrap with a
per-locale singleton cache and a `SOURCE_LOCALE` fallback.
- `twenty-emails/src/utils/i18n.utils.ts` now consumes the shared
factory.
**2. `twenty-website-new` Lingui bootstrap + Crowdin wiring**
- `lingui.config.ts`, `src/lib/i18n/*`, `nx run
twenty-website-new:lingui:{extract,compile}`.
- 31 locale PO files generated; minified compiled output kept out of
Prettier and Oxlint.
- `i18n-{push,pull}.yaml` workflows updated to include
`twenty-website-new` in Crowdin sync.
**3. `app/[locale]/...` segment routing with English at the root**
- All marketing routes moved under `src/app/[locale]/`; static
generation preserved (15 routes × 31 locales = 465 prerendered URLs).
- Middleware behavior:
- `/{en}/...` → 301 redirect to unprefixed canonical.
- `/{non-en}/...` → pass through, set `NEXT_LOCALE` cookie.
### What this PR explicitly does not do (deferred)
- Lingui-wrapping the actual marketing copy. Keys, build pipeline, and
runtime are wired; copy migration is a separate, reviewer-friendlier
PR.
Guillaume Flambard
