Stop excluding drafts from sync across all three providers (Gmail DRAFT
label, Microsoft/IMAP Drafts folder) and add an isDraft boolean field on
Message so drafts are queryable by the API and AI agents.
Drafts render in the thread with a Draft tag; clicking one opens the
existing reply composer pre-filled with the draft's recipients, subject
and body, and Send reuses the existing send-email flow.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22178?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>
## Issue
A `PAGE_LAYOUT` navigation menu item can be created pointing at a page
layout whose type is **not** `STANDALONE_PAGE` (e.g. a `DASHBOARD`). The
sidebar always links such an item to `/page/<pageLayoutId>`, but that
route only renders `STANDALONE_PAGE` layouts, anything else is
redirected to 404.
Result: a silently broken sidebar link (cc:
https://discord.com/channels/1130383047699738754/1519045990047285288).
## Root cause
- `/page/:pageLayoutId` is standalone-only by design (route guard in
`usePageChangeEffectNavigateLocation`, and `StandalonePageLayoutPage`
hardcodes `layoutType: STANDALONE_PAGE`). Dashboards/record pages are
reached elsewhere (record show page).
- A `PAGE_LAYOUT` nav item unconditionally computes
`/page/<pageLayoutId>`.
- No validation ensured the referenced layout is `STANDALONE_PAGE`: the
migration/manifest validator only checked that `pageLayoutId` was
present, the DB constraint only checked `NOT NULL`, and the runtime tool
description even suggested pinning dashboards this way. So an app
manifest pairing a `DASHBOARD` layout with a `PAGE_LAYOUT` nav item
installed cleanly and produced a dead link.
## Fix (treat as invalid config — fail fast)
- Cross-entity validation in `FlatNavigationMenuItemValidatorService`
(both create and update): when `type === PAGE_LAYOUT`, resolve the
referenced page layout from the optimistic page-layout maps and raise
`INVALID_NAVIGATION_MENU_ITEM_INPUT` if its `type !== STANDALONE_PAGE`.
Existence keeps being enforced by foreign-key resolution, so the type
check only fires when the layout resolves.
- Corrected the misleading `create_navigation_menu_item` tool
description (no longer says "e.g. a dashboard"; states the target must
be a `STANDALONE_PAGE`).
- Added unit tests covering: `STANDALONE_PAGE` accepted; `DASHBOARD`
rejected; `RECORD_PAGE` rejected; unresolved reference not flagged as a
type error.
## Files changed
- `flat-navigation-menu-item-validator.service.ts` — new
`validatePageLayoutReference` + wired into create/update.
- `create-navigation-menu-item.tool.ts` — tool description fix.
- `__tests__/flat-navigation-menu-item-validator.service.spec.ts` — new
tests (4 passing).
## Out of scope / follow-up
- To open discussion, check
https://github.com/twentyhq/twenty/pull/22255
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22343?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. -->
## What & why
Removes the `twenty-sdk/ui` reexport. Apps now use Twenty UI by
installing
[`twenty-ui@1.0.0-alpha.1`](https://www.npmjs.com/package/twenty-ui/v/1.0.0-alpha.1)
from npm and importing its subpaths directly. The reexport re-exported
types that didn't resolve, forcing typecheck workarounds.
## Changes
- **twenty-sdk**: delete `src/ui/index.ts`, drop the `./ui` export,
remove it from the browser vite build, and rewire the CLI manifest-mock
to `twenty-ui` (`.css` falls through to the empty-CSS loader).
`twenty-ui` stays a devDependency for the CLI fixture tests.
- **Renderer + create-twenty-app template**: import from `twenty-ui`
subpaths; the template pins `twenty-ui@1.0.0-alpha.1`.
- **Docs**: new "Using Twenty UI components" section (install + subpath
imports + `useTheme()` for theme tokens), codex references, and the
cross-doc-contract validator.
The `twenty-for-twenty` / `twenty-slack` example apps are intentionally
left on `twenty-sdk/ui`: they consume the published SDK (which still
ships `./ui`), and `twenty-ui@1.0.0-alpha.1` requires react 19 + a
`monaco-editor` peer the react-18 apps can't satisfy. They migrate once
the SDK is republished.
## Summary
Fully deprecates the cached `asExpression` / `generatedType` settings on
`TS_VECTOR` (searchVector) fields. Previously the generated-column
expression was stored in `FieldMetadataSettings` and kept in sync via
imperative recompute side-effects. It is now **derived at DDL time**
from the `searchFieldMetadata` rows that describe which fields feed the
search vector, making `searchFieldMetadata` the single source of truth
and removing a whole class of cache-drift bugs.
This is delivered across the milestones tracked in #2587 and coordinates
with the frontend migration (#1428).
## Why
- The searchVector expression lived in two places (stored
`settings.asExpression` + the actual generated column), kept consistent
by bespoke side-effects (`recompute-search-vector-on-field-rename`,
label-identifier recompute, etc.).
- The frontend reconstructed the searchable-fields list by
**regex-parsing** the stored `asExpression`.
- Both are brittle. Deriving the expression from `searchFieldMetadata`
rows at build/run time removes the cache and the parsing.
## What changed
### Server - data model & derivation
- Introduce the `tsVectorFieldMetadata` relation on
`searchFieldMetadata` (`tsVectorFieldMetadataId` / universal identifier)
linking each searchable-field row to its target `TS_VECTOR` field.
- New runtime derivation
`deriveSearchVectorAsExpressionForTsVectorField`
(`flat-search-field-metadata/utils/...`) used by the create-object and
update-field handlers to generate the column expression from
`searchFieldMetadata` rows.
- Remove `asExpression` / `generatedType` from stored settings:
`FieldMetadataSettings.TS_VECTOR` is now `null`; the column builder
(`generate-column-definitions.util.ts`) hardcodes `generatedType:
'STORED'` and requires the derived expression.
- Delete the imperative recompute side-effects and the
`compute-search-vector-universal-settings-from-object-manifest` path;
drop the `settings` block from all 28 standard
`compute-*-standard-flat-field-metadata` utils.
### Server - migration runner
- New `rebuildSearchVector` marker on `update-field` actions: the
orchestrator synthesizes targeted column rebuilds
(`compute-search-vector-rebuild-target-universal-identifiers.util.ts` +
the deprioritize aggregator) only when a searchFieldMetadata change or
indexed-field rename actually requires it - instead of rebuilding on
every settings touch.
- Deferrable FKs + in-flight ID resolution so a `searchFieldMetadata`
row and its `TS_VECTOR` field can be created in the same transaction
(deterministic UUIDs).
### Frontend (contract change, #1428)
- New `SearchFieldMetadataDTO` + dataloader exposing
`searchFieldMetadataList` on object metadata.
- `SettingsObjectSearchSection` now reads
`objectMetadataItem.searchFieldMetadatas` instead of parsing
`asExpression`; new `SearchFieldMetadataItem` type, fragment, and
mapping updates.
### Upgrade commands (2.18)
-
`2-18-instance-command-fast-...-add-ts-vector-field-metadata-id-to-search-field-metadata`
-
`2-18-instance-command-fast-...-make-search-field-metadata-fks-deferrable`
-
`2-18-instance-command-slow-...-backfill-ts-vector-field-metadata-id-on-search-field-metadata`
(These were relocated from 2.16 to 2.18 and re-timestamped into an
ordered block - add column -> make FK deferrable -> backfill data -
since 2.16/2.17 are released.)
### Tests
- Updated search-vector side-effect integration specs to assert behavior
(search works) rather than the now-removed `asExpression`; removed the
obsolete expression-validation specs; refreshed the application-sync
snapshot (`universalSettings: null`).
## Upgrade / compatibility notes
- Existing workspaces keep their stored `settings` until a later
cleanup; nothing reads it anymore. The new derivation drives all DDL
going forward.
- Schema changes are gated behind the 2.18 instance commands above.
## Known follow-up (separate PR)
https://github.com/twentyhq/core-team-issues/issues/2620
- The column rebuild (`DROP`/`ADD` of the `searchVector` STORED column)
cascade-drops its GIN index and does not recreate it - a pre-existing
regression on `main` inherited here. A follow-up PR will fix the rebuild
handler to recreate the GIN index and add a 2.18 workspace command to
recompute every search vector + strip the deprecated settings.
(Planned.)
## Test plan
- [ ] `npx nx typecheck twenty-server` / `twenty-front`
- [ ] `npx nx lint:diff-with-main twenty-server` / `twenty-front`
- [ ] Server integration: create/update/delete field, rename indexed
field, update object - search returns expected records
- [ ] Run the 2.18 instance commands on a seeded DB; verify
`tsVectorFieldMetadataId` backfilled and FKs deferrable
- [ ] Frontend: object Search settings tab lists the correct searchable
fields (no `asExpression` parsing)
close https://github.com/twentyhq/core-team-issues/issues/2587
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22287?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. -->
## What & why
Node's HTTP server defaults `keepAliveTimeout` to **5s**, which is
shorter than the idle keep-alive timeout of common reverse proxies /
load balancers (nginx `upstream-keepalive-timeout` and AWS ALB both
default to **60s**). twenty-server currently calls `app.listen()`
without overriding these, so it runs on the 5s default.
When Node closes an idle keep-alive socket that the proxy still has
pooled, the proxy's next request races the close and gets a TCP reset.
nginx logs:
```
recv() failed (104: Connection reset by peer) while reading response header from upstream
```
and returns a **502** to the client. This is payload- and
endpoint-independent: in prod it hit `/graphql`, `/metadata`, `/mcp` and
the app-publish tarball upload alike, at a low continuous rate, on
healthy pods (no restarts, ~64% memory, no CPU throttling).
This is the well-documented "Node behind ALB/nginx 502" race. The fix is
the standard one: make the **server** idle timeout **longer** than the
proxy's, so the proxy is always the side that closes idle connections.
## Changes
- Set `server.keepAliveTimeout` / `server.headersTimeout` in `main.ts`
from config.
- Add two env-overridable config vars (`SERVER_CONFIG` group), with safe
defaults above the typical 60s proxy timeout:
- `SERVER_KEEP_ALIVE_TIMEOUT_MS` (default **65000**)
- `SERVER_HEADERS_TIMEOUT_MS` (default **66000**)
- `headersTimeout` is clamped to `keepAliveTimeout + 1s` at startup,
since Node requires `headersTimeout >= keepAliveTimeout` (otherwise it
re-introduces the same race).
- Document both in `.env.example`.
Defaults fix the issue out of the box. The env vars exist because
self-hosters sit behind many proxies (Cloudflare, Traefik, ALB, nginx)
with different idle timeouts — mirroring how Next.js exposes
`--keepAliveTimeout`, and how Fastify (72s) and Kestrel (130s) ship
safe-by-default values.
## Test
- `environment-config.driver.spec.ts` passes.
- `nx typecheck twenty-server` clean for the changed files (only a
pre-existing, unrelated `ical-generator` module-resolution error
remains).
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22327?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. -->
## What
Adds a custom Jest reporter to **twenty-front** that, in CI, suppresses
passing-test output and surfaces only failures — mirroring what we
already do for **twenty-server**.
## How
- New `packages/twenty-front/jest-failures-only-reporter.cjs` — a
verbatim port of
`packages/twenty-server/jest-failures-only-reporter.js`. It prints a
`FAIL` block per failing suite plus a final "FAILED TEST SUITES
SUMMARY", and otherwise emits only the suite/test totals.
- Wired into `packages/twenty-front/jest.config.mjs` via `...(isCI && {
reporters: ['./jest-failures-only-reporter.cjs'] })`, gated on `CI ===
'true'` exactly like twenty-server.
### Note on the `.cjs` extension
twenty-front's `package.json` sets `"type": "module"`, so a `.js`
reporter is parsed as ESM and `module.exports` throws. Renaming to
`.cjs` keeps the file as CommonJS (Jest requires CJS reporters).
twenty-server is not an ESM package, hence its `.js` extension.
## Testing
- Passing suite (`CI=true npx jest <file>`): output reduced to the
totals summary only.
- Temporary failing suite: shows the `FAIL` block, failure message, and
the failed-suites summary.
Local dev runs (no `CI` env) are unaffected — the default reporter is
used.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22345?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. -->
## Summary
Creating a Task or Note on a record of a newly-created custom object
failed to link them, and the console showed `Missing field 'targetTest…'
while writing result` for `TaskTarget`/`NoteTarget`.
After creating a custom object, the front-end metadata store was left
with an inconsistent morph relation group on the default-relation
objects (`taskTarget`, `noteTarget`, `attachment`, `timelineActivity`).
This reconciles the store from the server after creation so the morph
fields are rebuilt correctly.
## Context / root cause
The DB and server are correct: the new object adds a single member (e.g.
`targetTest`) to the existing `target` morph group (shared `morphId`),
and the server's `objects` query collapses + renames the group to one
`target` field with a full `morphRelations` array.
On the client, though, the metadata store is updated incrementally after
creation:
- The bulk `objects` query stores morph fields already collapsed
(`target` + `morphRelations`).
- The new reciprocal morph member arrives via SSE/mutation as a raw,
un-collapsed field row (`targetTest`, without `morphRelations`), which
`objectMetadataItemsWithFieldsSelector` simply joins in.
This leaves two morph fields on `taskTarget`/`noteTarget` (`target` with
stale members + an un-normalized `targetTest`).
`mapFieldMetadataToGraphQLQuery` then fans `targetTest` out into
non-existent fields (`targetTestCompany`, `targetTestPerson`, …), which
the server omits, breaking the optimistic cache write (`writeFragment`)
and leaving the activity target unlinked in the UI.
This is a regression from the metadata-store incremental-sync refactor
(the create path stopped reconciling reciprocal morph fields on existing
objects).
## Fix
In `useCreateOneObjectMetadataItem`, after the incremental store
updates, call `invalidateMetadataStore()` so the objects/field metadata
is refetched from the server and the morph groups are rebuilt in their
correct collapsed form. This mirrors the existing pattern in
`useDeleteOneObjectMetadataItem`.
## Test plan
- [ ] Create a new custom object.
- [ ] Open a record of that object and create a Task and a Note from it.
- [ ] Verify no `Missing field 'target…'` error in the console and the
task/note is linked (visible in the record's Tasks/Notes and on the
activity target).
- [ ] Confirm existing standard objects (Company/Person/Opportunity)
still link tasks/notes correctly.
- [ ] Confirm object creation still updates the left nav / views as
before.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22331?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
When navigating between the app and settings sections,
MainAppLayoutOutlet keeps the outgoing page mounted during the
AnimatePresence exit transition, and can leave a stale exit node behind
the active page, notably when the page hosts an app front component
whose Web Worker teardown blocks React from removing it.
The leftover page is invisible (opacity 0) but still captures pointer
events on top of the active route, so e.g. front-component buttons stay
clickable through the settings screen.
The existing `exit={{ pointerEvents: 'none' }}` mitigation is defeated
by descendants that set pointer-events explicitly (the front-component
container uses pointer-events: auto). Tag each transition page with its
route section and mark every non-active one `inert`, which descendants
cannot override, so any stale page is fully non-interactive.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22328?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. -->
## Summary
Two robustness fixes to `docs-i18n-pull.yaml` so localized docs can't
silently drift:
1. **Prune orphan localized files.** The pull only adds/updates files,
never deletes — so localized copies of renamed/moved/deleted English
pages linger and serve dead URLs (recently ~113 of them). A new
`prune-orphan-translations` script (run with `--apply` in the workflow,
on real pulls only) removes any `l/<lang>/**` file whose English source
no longer exists.
2. **Surface per-language download failures.** The loop previously
swallowed failures with `|| echo "Warning..."`, so a language whose
Crowdin server-side build fails (e.g. `ja`, failing at 79%) was skipped
*silently* and froze indefinitely while every other language updated. We
now collect failures, still commit the languages that succeeded, and
**fail the run at the end** so a broken language is visible.
---------
Co-authored-by: Cursor <cursoragent@cursor.com>
## Summary
**PR 3/4** of the app-metadata-translations stack. Extends runtime
translation resolution to the remaining Twenty-rendered metadata types
so coverage is complete.
- New shared `MetadataTranslationResolverService.getApplicationCatalog({
applicationId, workspaceId, locale })` — the single seam for fetching an
app's per-locale catalog.
- Wired into the **page-layout tab**, **page-layout widget**,
**view-field-group**, **command-menu navigation item**, and **view
name** resolvers, each extended with an optional `applicationCatalog`
param (backward-compatible).
Together with PR 1/4 (object + field), this covers all seven
translatable metadata surfaces.
## Stack
Stacks on #22236 (PR 2/4). Base branch:
`claude/app-translation-2-sdk-manifest`.
## Verification note
`yarn install` could not complete in the remote dev environment, so
typecheck/lint/tests were not run locally — **CI is the source of
truth**.
https://claude.ai/code/session_01NiE7o3cd3zCLZarVkJa6UA
---
_Generated by [Claude
Code](https://claude.ai/code/session_01NiE7o3cd3zCLZarVkJa6UA)_
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22237?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. -->
https://github.com/user-attachments/assets/b1ee4f77-c6d7-4638-b9f1-dd801d1cc0db
Completes the onboarding-v2 flow: a dedicated verify step, the
reordering that makes the plan step come last, and the
upgrade-free-trial page itself.
## Verify step (`/verify-v2`)
After the cross-domain token exchange, v2 sign-ups land on a clean
`BlankLayout` "Verifying your email" screen (fading Twenty logo) instead
of the v1 `AuthModal` flashing over the background mock. The redirect
target is chosen from `isOnboardingV2` (read from the Jotai store at
redirect time). The pulsing logo is extracted into a shared
`OnboardingPulsingLogo`, reused by the workspace-activation loader.
`/verify-v2` joins the same exempt lists as `/verify` (ongoing-creation
guard, metadata gater, apollo unauthenticated handler, captcha, page
title) — intentionally not `useShowAuthModal`, which is what drops the
modal.
## Plan step is now last
`getOnboardingStatus` checks `PLAN_REQUIRED` after invite-team instead
of first, so onboarding runs workspace activation → email → profile →
invite → plan. This is what lets the upgrade step be reached as the
final step instead of gating right after sign-up. Applies to both v1 and
v2 (same order).
## Upgrade free trial page (`PlanRequiredV2` → `ChooseYourPlanV2` /
`UpgradeFreeTrial`)
The final step, full-screen under `BlankLayout` via
`OnboardingV2Layout`, matching the Figma (billing card with the Stripe
form, the "Basic / without credit card" option, trial + credits pills).
Reuses the v1 `ChooseYourPlanContent` billing logic
(`SubscriptionPaymentForm`, `useHandleCheckoutSession`). The "+N free
credits" reward comes from
`clientConfig.onboarding.upgradeCreditsReward` (sourced from
`BILLING_FREE_WORKFLOW_CREDITS_FOR_TRIAL_PERIOD_WITH_CREDIT_CARD`).
## Also
Fixes a latent staleness in the Apollo `onUnauthenticatedError` handler
— it captured `location` from the memoized client, now read via a ref —
so auth-path exemptions are correct after navigation.
Note: the onboarding step order change affects v1 too (plan becomes its
last step as well).
## Problem
The `2.17` `AddWorkspaceMemberJobTitleField` upgrade command failed for
every workspace that has a **custom field on `workspaceMember`** (it
aborted the per-workspace upgrade sequence). Root cause:
The command used `FieldMetadataService.createManyFields`, which —
besides creating the field metadata — also creates the new field's
**view fields** across the object's existing views. Validating a
view-field creation enumerates the target view's full
`viewFieldUniversalIdentifiers`, which includes view fields owned by
**another application** (a custom field a user added to
`workspaceMember`). Those cross-application view fields are filtered out
of the build's application-scoped dependency maps, so the build throws
`Could not find flat entity with universal identifier ...`.
## Fix (command-scoped)
Create the field metadata **only — no view fields** — sourced from the
standard-application definition, mirroring
`AddInactiveGenericStandardFieldsCommand` (which adds a standard field
the same way and is unaffected by this bug). The standard view-field
side effects are reconciled as code, so they should not be produced at
runtime here.
Concretely: source the standard `jobTitle` `FlatFieldMetadata` from
`computeTwentyStandardApplicationAllFlatEntityMaps`, blank its
`viewFieldIds` / `viewFieldUniversalIdentifiers`, and run a
`fieldMetadata`-only `validateBuildAndRunWorkspaceMigration` instead of
`createManyFields`. Also drops the now-unused `FieldMetadataModule`
import from the 2-17 command module.
## Trade-off
Existing workspaces get the `jobTitle` field + column but **no view
field**, so it won't appear as a default column in `workspaceMember`
views until the standard-application reconciliation adds view fields.
`jobTitle` is `isSystem` / `isUIReadOnly`, so this is acceptable as the
immediate unblock.
## Scope
This is the small, immediate unblock for the failed `2.17` upgrade. The
general framework fix (load cross-application children of involved
parents into the build scope) is tracked separately in #22294.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22306?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. -->
### The current order is:
1. Create filter groups
2. Update filter groups
3. Destroy filter groups ← **happens here**
4. Clean up store (cascade)
5. Create/update/delete filters (which may reference groups just
destroyed)
The fix is to move filter group destruction after filter operations, so
filters that reference those groups get created/updated/deleted first.
### after fix : The persistence order is now:
1. Create filter groups
2. Update filter groups
3. Create/update/delete view filters (these can safely reference groups
that still exist)
4. Destroy filter groups (only after all filter mutations are done)
5. Clean up store (cascade-deleted filters
**root cause :** step 4 happened before step 3, so filter
creates/updates would reference groups that had already been deleted in
the same save cycle ; causing the backend to fail with "Migration
execution failed" when it couldn't resolve the `viewFilterGroupId
`foreign key.
this fixes the bug : #21351
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22248?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: Souheyl Gouadria <souheyl.gouadria@medius.com>
Co-authored-by: Charles Bochet <charles@twenty.com>
## TL;DR
Adds a workspace upgrade command that normalizes index names to the
current v2 deterministic naming convention (IDX_ prefix). This will
close https://github.com/twentyhq/twenty/issues/21383 : uniqueness
constraint cannot be disabled (for users who set it before v2
determinist naming is enforced).
### Background
The deterministic index name embeds the table name, columns, uniqueness
and where clause. The naming convention changed on **2025-09-23**
(#14567 - added the `IDX_`/`IDX_UNIQUE_` prefix and folded the table
name into the hash). Index rows created before that kept their old name
in `core."indexMetadata"`, and nothing rewrites it (only targeted
phone/relation rebuilds got new names).
Code paths that locate an index by recomputing its expected name then
miss these legacy-named rows. The most visible symptom is #21383:
toggling a field's `isUnique` from `true` → `false` recomputes the
expected unique-index name, fails to find the legacy-named index, and
silently no-ops — so uniqueness can't be disabled.
### What the command does
Per workspace, for each index:
- recomputes the expected name with the same generator the app uses
(`generateFlatIndexMetadataWithNameOrThrow`);
- if the stored name differs → **rename** it (metadata `UPDATE` + a new
metadata-only `ALTER INDEX … RENAME`, which preserves the unique
constraint with no rebuild/lock);
- if a correctly-named twin already exists (the legacy +
freshly-generated duplicate case) → **drop the redundant** one (physical
+ metadata, field rows cascade) and keep the canonical;
- invalidates the metadata cache so the running app + `isUnique`
derivation reflect the new names.
Honors `--dry-run`, wraps writes in a transaction (rolls back on error),
and skips (with a warning) any single index whose name can't be
recomputed so it can't abort the whole workspace.
### Notable changes
- New `renameIndex` on `WorkspaceSchemaIndexManagerService` (`ALTER
INDEX IF EXISTS … RENAME`).
- Planning logic extracted into a pure, unit-tested util
(`planIndexNameNormalization`).
## After
<img width="1476" height="658" alt="image"
src="https://github.com/user-attachments/assets/25a042dd-eabf-4b71-9872-d3b627104634"
/>
## Summary
This PR adds the ability for admins to manually synchronize the
marketplace application catalog from the admin panel. It introduces a
new mutation endpoint and UI controls to trigger catalog synchronization
with user feedback via snackbar notifications.
## Key Changes
- **Frontend (SettingsAdminApps component)**:
- Added `useSnackBar` hook for user feedback on sync success/failure
- Imported `useMutation` from Apollo Client to handle the sync operation
- Added `IconRefresh` and `Button` imports for the sync UI control
- Created `handleSyncCatalog` function that triggers the mutation,
refetches app registrations, and displays appropriate snackbar messages
- Added a new "General" section with a "Synchronize catalog" button
above the existing app registrations table
- Button shows loading state and is disabled while sync is in progress
- **Backend (AdminPanelResolver)**:
- Added `syncMarketplaceCatalog` mutation that queues a
`MarketplaceCatalogSyncCronJob` via the message queue
- Uses `@InjectMessageQueue` decorator to inject the cron queue service
- Includes job deduplication via `id: 'marketplace-catalog-sync'` to
prevent multiple pending sync jobs
- Protected with `@UseGuards(AdminPanelGuard)` for admin-only access
- **GraphQL Schema**:
- Added `SyncMarketplaceCatalog` mutation type definition
- Generated corresponding TypeScript types and mutation document
- **New Files**:
- Created `syncMarketplaceCatalog.ts` GraphQL mutation document
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22260?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
When creating or editing a dashboard and opening a page layout side
panel (clicking the **"Add widget"** box, or editing a widget via grid
edition), clicking another nav item like **"Opportunities"** crashes the
whole app ("Sorry, something went wrong").
### Steps to reproduce
1. Go to `/objects/dashboards` and click **"+ Add new"** to create a
dashboard.
2. Click the **"Add widget"** box (or add a widget via grid edition and
open its settings).
3. Click another nav item such as **"Opportunities"**.
4. The app crashes.
## Root cause
The side panel stays mounted during its close animation, but the main
context store has already switched to the new page (the record index has
no single targeted record). The still-mounted page layout side panel
page (`SidePanelPageLayoutDashboardWidgetTypeSelect`, chart settings,
etc.) re-renders and calls `usePageLayoutIdFromContextStore`, which
throws `Error: Only one record should be selected`. With no local error
boundary, the throw propagates to the top-level boundary and crashes the
app.
## Fix
`SidePanelRouter` now skips rendering page layout side panel pages
whenever the main context store has no single targeted record — the same
condition `usePageLayoutIdFromContextStore` requires to not throw.
During navigation the panel closes cleanly instead of crashing.
This is safe because `usePageLayoutIdFromContextStore` unconditionally
throws without a single-record selection, so the guard can only skip
pages that would otherwise crash — it cannot break a currently-working
flow. The guard uses the existing `isPageLayoutSidePanelPage` helper, so
it covers all page layout side panel pages (widget type select, chart /
iframe / record table settings, record page field settings, etc.).
## Testing
- Reproduced the crash in the running app, applied the fix, and
confirmed navigating to Opportunities from both the **widget type
select** and the **chart settings** panels now lands on the
Opportunities list with no console or page errors.
- `oxlint --type-aware` and `nx typecheck twenty-front` both pass.
<img width="3024" height="1500" alt="CleanShot 2026-06-26 at 18 09
47@2x"
src="https://github.com/user-attachments/assets/e91f30a5-2763-42a0-9abf-d9fa8400870c"
/>
Adds the v2 onboarding **Invite team** page (`INVITE_TEAM`), shown right
after the create-profile step for the onboarding-v2 cohort. It renders
full-screen under `BlankLayout` via the shared `OnboardingV2Layout`,
matching the Figma (340px column, email inputs with inline remove, dark
Invite, Skip).
Reuses all v1 invite-team logic via a new `useInviteTeam` hook (v1
`InviteTeam` now consumes it too; its UI is unchanged). Routing mirrors
`SyncEmailsV2`/`CreateProfileV2`: new `AppPath.InviteTeamV2`, lazy
route, and an `isOnboardingV2`-gated branch in
`usePageChangeEffectNavigateLocation` (+ tests and a Storybook story).
No backend changes.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22229?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. -->
Closes#22250
## What
Adds four standard pod spec fields to both server and worker Deployments
of the Helm chart, exposed under `server.*` and `worker.*` in
`values.yaml`:
- `nodeSelector`
- `tolerations`
- `dnsPolicy`
- `dnsConfig`
## Why
Self-hosters who run Twenty on clusters with dedicated nodes, taints, or
custom DNS requirements currently need to fork the chart or patch
rendered manifests with Kustomize. These are the standard pod spec
fields supported by virtually every other community chart (Bitnami,
prometheus-community, cert-manager, etc.) and are commonly needed in
production setups.
## How
Uses the same `{{- with }}` pattern already present in the chart (e.g.
`extraEnv`, `extraVolumeMounts`), so empty defaults skip rendering
entirely:
```yaml
{{- with .Values.server.nodeSelector }}
nodeSelector:
{{- toYaml . | nindent 8 }}
{{- end }}
```
## Backward compatibility
Fully backward compatible. Defaults are empty:
```yaml
server:
nodeSelector: {}
tolerations: []
dnsPolicy: ~
dnsConfig: {}
```
`helm template` output is bit-identical to the previous version for any
existing install.
## Schema note
`dnsPolicy` is typed as `[string, null]` and the enum includes `null` so
the empty default (`dnsPolicy: ~`) passes validation. The `{{- with }}`
guard treats null as falsy and renders nothing.
## Validation
- `helm lint` passes
- `helm template` with default values produces bit-identical output to
before this PR
- `helm template` with values set renders the four fields correctly on
both server and worker
- Live install validated on a multi-node Kubernetes cluster, pinning
Twenty to a dedicated tainted node with custom DNS (`ndots: 1`); server
and worker scheduled and started successfully
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22233?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>
## Summary
Makes AI-assisted bulk data import (CSV/Excel/spreadsheets) reliable and
token-efficient by letting an entire import run inside a single
code-interpreter call, with a persistent sandbox session and server-side
bulk helpers. Also includes supporting improvements to attachment
handling, upsert reporting, and field-permission error messages.
## Changes
### Code interpreter
- **Persistent per-session kernel** in `LocalDriver`: a long-lived
Python process per `sessionId` keeps variables, imports, and files alive
across calls (matching E2B behavior). Falls back to the existing
ephemeral per-call path when no session is provided. CAN BE REMOVED,
INTERESTING FOR DEV X
- Idle watchdog that self-terminates the kernel, configurable via the
new `CODE_INTERPRETER_IDLE_TIMEOUT_MS` config variable; the process also
exits on parent shutdown (EOF on control fd). CAN BE REMOVED,
INTERESTING FOR DEV X
- New `bulk_upsert` and `lookup_by` helpers on the sandbox `twenty`
object for idempotent batched writes (≤200/batch) and bounded
relation-ID resolution.
### Records
- `upsert_many_*` now reports a `created` / `updated` / `total` split in
its result and log line (new `isFreshlyCreatedRecord` util).
### AI chat
- `replaceUnsupportedFileParts`: user-attached files whose MIME type the
model can't handle natively (and that aren't code-interpreter-supported)
are downgraded to a descriptive text note instead of being sent as
unsupported file parts. Modality→MIME mapping drives native support
detection.
- Finalize dangling tool parts before `convertToModelMessages` to avoid
malformed model messages.
- Extracted shared types/constants for code-interpreter file extraction.
### Permissions
- Field permission-denied exceptions now include the field name and
entity name for easier debugging.
### Skill docs
- Added the bulk-import recipe
## To do in following PR
- [ ] Skill command migration
## Test plan
- [x] Unit tests for `getNativeMimeTypesForModalities` and
`replaceUnsupportedFileParts` pass
- [x] Run a bulk import (>50 rows) end-to-end through the code
interpreter and verify a single sandbox call handles read → resolve
relations → upsert → summary
- [x] Verify session persistence: define a variable in one call, use it
in the next within the same session
- [x] Verify the kernel self-terminates after
`CODE_INTERPRETER_IDLE_TIMEOUT_MS`
- [x] Verify unsupported attachments are replaced with a text note for
models lacking the modality
- [x] Verify `upsert_many_*` returns correct created/updated counts
- [x] Verify field-restricted role triggers a permission error naming
the field and entity
- [ ] Test with
[hotel_business.xlsx](https://github.com/user-attachments/files/29376307/hotel_business.xlsx)
and simple "import record" prompt
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22209?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
Using an AI Agent step in a workflow fails with:
> Invalid schema for function 'navigate_app': schema must be a JSON
Schema of 'type: "object"', got 'type: "None"'.
## Root cause
The `navigate_app` tool declared its `inputSchema` as a top-level
`z.discriminatedUnion('type', [...])`. When serialized via
`toToolJsonSchema`, a discriminated union produces a **root-level
`anyOf`** with no top-level `"type"`:
```json
{ "anyOf": [ { "type": "object", ... }, ... ] }
<!-- This is an auto-generated description by cubic. -->
<a href="https://cubic.dev/pr/twentyhq/twenty/pull/22284?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
After v2.17.0 shipped app-owned metadata translations (#22235), `POST
/metadata` got slower for workspaces with translation-carrying apps
installed. Sentry flagged it as an N+1
(`performance_n_plus_one_db_queries`): a single request fires **many**
concurrent identical queries:
```sql
SELECT … FROM "core"."applicationTranslation" WHERE "applicationRegistrationId" = $1 AND "deletedAt" IS NULL
```
Span aggregates since the deploy: **272** such spans, **avg 74 ms**,
**p95 556 ms**, **max 694 ms**, all on `POST /metadata`. HTTP stays 200
— it's latency, not errors.
Reported via Sentry `TWENTY-SERVER-HQY` (`twenty-v7`).
## Root cause
`ApplicationTranslationCacheService` kept a TTL value cache but had **no
in-flight de-duplication**. The object/field metadata resolvers call
`getCatalog` directly, per record. On a cold/expired (30 s TTL) cache,
many fields of the same app resolve concurrently, all miss, and each
fires its own `repository.find` — a classic cache **stampede**, which
queues on the connection pool and produces the 556–694 ms tail. Each
read also pulls the full per-locale `messages` JSON, so the redundant
reads aren't free.
## Fix
Rebuild the service on the shared **`PromiseMemoizer`** primitive — the
same one `WorkspaceCacheService` and `CoreEntityCacheService` already
use. It pairs the 30 s TTL value cache with a `pending` promise map, so
concurrent callers for the same registration **share a single in-flight
query** instead of stampeding. Per-request query count for a given app
goes from N → 1.
- Public API (`getCatalog` / `invalidate`) is unchanged — no caller
touched.
- `invalidate` now clears via `memoizer.clearKeys(...)` (clears both the
cached value and any in-flight read), matching `WorkspaceCacheService`.
- Adds a unit test asserting 10 concurrent `getCatalog` calls trigger
exactly **one** `repository.find`, plus cache-hit / empty-locale /
post-invalidation reload cases.
## Notes
- Process-local 30 s TTL behaviour is unchanged (deliberate; no
cross-process invalidation), this only removes the redundant concurrent
reads.
- Verified formatting with oxfmt locally; couldn't run the server test
suite in this environment, so relying on CI for typecheck/test.
https://claude.ai/code/session_01NiE7o3cd3zCLZarVkJa6UA
---
_Generated by [Claude
Code](https://claude.ai/code/session_01NiE7o3cd3zCLZarVkJa6UA)_
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22285?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. -->
## What's this PR doing?
Two inline rename inputs run their action on `Enter` without ignoring
the `Enter` that confirms an IME composition:
- `AiChatThreadListItem` (renaming an AI chat thread). It also calls
`preventDefault()`, so the composition-commit `Enter` is swallowed and
the half-typed title gets saved.
- `AttachmentRow` (renaming an attachment). The same `Enter` saves the
unfinished name.
When you type with an IME (Japanese, Chinese, Korean), the first `Enter`
after typing confirms the candidate text rather than submitting, so
these handlers fire with text the user hasn't finished entering.
## Why
The codebase already guards this where keyboard handling goes through
`useHotkeysOnFocusedElement` (`if (keyboardEvent.isComposing ||
keyboardEvent.keyCode === 229) return`), and the inline inputs that
don't use that hook add the same check themselves: see
`SettingsAccountsBlocklistInput`, `SettingsDevelopersApiKeysNew`, and
the sign-up workspace forms. These two rename inputs were just missing
it.
## How
Add the same `isComposing || keyCode === 229` guard before the `Enter`
branch. For input without an IME, `isComposing` is `false` and `keyCode`
is `13`, so the rename-on-Enter behavior stays the same. This only skips
the action on the composition-commit key.
I checked the change against the repo's Prettier config locally. I
couldn't add a unit test because jsdom doesn't dispatch real composition
events (`isComposing` stays `false`), so it can't reproduce the
keystroke. Happy to add an e2e test if that's preferred.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22270?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. -->
## What
The twenty-infra **"Deploy Website"** workflow has failed every run
since 06-26 — at OpenNext's R2 incremental-cache step, **not** the
build:
```
Failed to provision remote R2 bucket "twenty-website-cache-dev"
for binding "NEXT_INC_CACHE_R2_BUCKET":
Failed to check whether bucket exists: … Premature close
```
## Root cause
`@opennextjs/cloudflare`'s `ensureR2Bucket()` calls the Cloudflare SDK's
`r2.buckets.get()`. On **Node 24** (which the deploy pins) undici
truncates the **gzip-compressed** Cloudflare API response → `Premature
close`. The SDK's own retries don't help (it's systematic, not flaky),
and pre-creating the bucket doesn't help (it always `.get()`s first).
This is **pre-existing and unrelated to the multi-locale change**
(#22257): the *Build Worker* step succeeds, and the identical error
appears on 06-26 runs (two days before that merged).
## Fix
opennext **1.20.0** fixes this precisely — it passes `defaultHeaders: {
"Accept-Encoding": "identity" }` to the Cloudflare SDK client, so the
API returns **uncompressed** responses (no decompression → no premature
close). **Node 24 is kept**, and no twenty-infra change is needed — the
deploy runs `twenty`'s own `npx opennextjs-cloudflare`, so bumping the
dep here is enough.
`^1.0.0 → ^1.20.0`. **1.20.0, not the latest 1.20.1**, because the
repo's `npmMinimalAgeGate: 3d` still quarantines 1.20.1 (published
06-26); 1.20.0 (06-25) is past the gate and carries the same fix.
## Verification
- Resolved to `1.20.0`; confirmed `Accept-Encoding: identity` is in the
installed `dist/cli/utils/ensure-r2-bucket.js`.
- `nx typecheck twenty-website` green (OpenNext config API unchanged
across the bump).
- Diff is just `package.json` + `yarn.lock`.
⚠️ Full confirmation needs a **Deploy Website** run (exercises the build
+ the R2 provision step), which I can't trigger — please re-run it after
merge.
## What
The marketing site now serves every language the **documentation** ships
— 14 locales (`en, fr, ar, cs, de, es, it, ja, ko, pt, ro, ru, tr, zh`),
up from 3 (`en, es, fr`).
## How
- **Single source of truth.** `WEBSITE_LOCALE_LIST` derives directly
from `DOCUMENTATION_SUPPORTED_LANGUAGES` (`twenty-shared/constants`).
Add a documentation language → it flows to the website automatically.
- **Off `APP_LOCALES` entirely.** The website locale type is now
`DocumentationSupportedLanguage` (short codes), so a locale **is** its
URL segment — no short↔full mapping, and no `pt-BR`/`zh-CN` ambiguity to
resolve.
- **Removed the indirection this exposed** (it only existed because
`AppLocale` was a superset of the deployed set):
- `locale-to-url-segment` / `locale-by-url-segment` (locale == segment)
- `get-locale-messages` pass-through → callers read `MESSAGES_BY_LOCALE`
directly
- the `messages-by-locale` runtime guard → a total
`Record<DocumentationSupportedLanguage, Messages>` (a missing catalog is
now a **compile** error, not a runtime throw)
- `isWebsiteLocale` → a `string → DocumentationSupportedLanguage` type
guard
- the vestigial language-code `split('-')` in `locale-display-name`
## Catalogs
- Renamed `es-ES → es`, `fr-FR → fr`; added 11 new locales (untranslated
for now → **English fallback**).
- `crowdin-website.yml` switched to `%two_letters_code%`.
- Regenerating catalogs also synced `en.po` with current source
(`Boolean` / `Date & Time` / removed `Fields widget` from the
already-merged #22249).
- `ci-website` is unchanged — no `lingui:compile` step added; catalogs
stay committed.
## Testing
- `typecheck` · `lint` (check-conventions + oxlint + oxfmt) · 347/347
tests — all green. PR CI runs exactly lint + typecheck + test.
## Follow-up (out of repo)
Enable the 11 languages on **Crowdin project 4** so `website-i18n-pull`
backfills real translations. Until then, the new locales render with
English fallback (correct behavior).
## Summary
**PR 2/4** of the app-metadata-translations stack. Gives app developers
the authoring side, as part of the normal manifest build — and it stays
out of the way of developers who don't translate.
- `twenty-sdk` CLI i18n pipeline: collect translatable strings from the
manifest, generate value-as-key message ids (`sha256(value)` truncated,
byte-identical to the server's `generateMessageId`), a `dev
i18n-extract` command to scaffold per-locale catalog files, and a
compile step folded into `build` that emits `manifest.translations`.
- Opt-in: no `locales/` dir → `compileApplicationTranslations` returns
`undefined` → manifest is unchanged.
- Adds an optional `locale` to the front-component execution context so
components can translate against the host locale.
## Stack
Stacks on #22235 (PR 1/4). Base branch:
`claude/app-translation-1-runtime-resolution`.
## Tests
Unit (vitest): extract/compile round-trip + message-id determinism.
## Verification note
`yarn install` could not complete in the remote dev environment, so
typecheck/lint/tests were not run locally — **CI is the source of
truth**.
https://claude.ai/code/session_01NiE7o3cd3zCLZarVkJa6UA
---
_Generated by [Claude
Code](https://claude.ai/code/session_01NiE7o3cd3zCLZarVkJa6UA)_
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/22236?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. -->
neo773
