houseassassin/twenty
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
12,702 Commits 1 Branch 0 Tags
f869ce87b1bfe3e8556cfa3b163b48defd4fc96f
Commit Graph

4874 Commits

Author SHA1 Message Date
Félix Malfait f869ce87b1 [Experiment] perf(front): cache-first currentUser bootstrap (#21532) 
## Experiment — not for merge as-is

A perf experiment for discussion. Opening as a draft to gather feedback
and let CI run.

## Problem

On a warm (returning) load, the app gate
([`MinimalMetadataGater`](https://github.com/twentyhq/twenty/blob/main/packages/twenty-front/src/modules/metadata-store/components/MinimalMetadataGater.tsx))
blocks first paint until **both** object/view metadata **and**
`currentUser` are ready.

The metadata store is already cache-first: it persists each entity
(including `status: 'up-to-date'`) to `localStorage` with `getOnInit`,
opens from cache, and revalidates in the background via collection
hashes. 👏

`currentUser` (and `currentWorkspace` / `currentWorkspaceMember` /
`currentUserWorkspace`) is **not** — it lives in an in-memory atom, so
every load fires a blocking `GetCurrentUser` round-trip before the gate
opens. That round-trip is the one remaining network hop on the warm-load
critical path; everything else the first screen needs is already in
`localStorage`.

## Approach

Generalize the pattern the metadata store already proves out, to the
user bootstrap — **without adding any new `useEffect`**:

- Persist the four bootstrap atoms (`currentUser`, `currentWorkspace`,
`currentWorkspaceMember`, `currentUserWorkspace`) via the existing
`createAtomState({ useLocalStorage, localStorageOptions: { getOnInit:
true } })`.
- The gate opens from cache on its own: the existing
`IsMinimalMetadataReadyEffect` already derives readiness from the
`currentUser` atom alongside metadata status, so persisting the atoms is
enough — no new effect.
- Keep firing `GetCurrentUser` (now `network-only`, no longer skipped
when a user is present) so it **revalidates in the background** and the
existing write-through effect updates the atoms with the fresh result.
- Clear the cached identity on sign-out by adding the four keys to
`clearSessionLocalStorageKeys` (already invoked by `clearSession`, which
then hard-reloads).

Net effect: warm loads no longer wait on `GetCurrentUser`; the shell
paints from cache and corrects within one round-trip. Cold loads (no
cache) are unchanged.

## Risks to validate

- **Permission staleness** — `currentUserWorkspace` carries
`objectsPermissions` / `permissionFlags`. Cache-first means a brief
stale-permission window before revalidation. Not a security boundary
(the server authorizes every request), but it can momentarily show a
menu item the user no longer has; worst case it 401s and corrects on the
next paint.
- **Feature-flag / workspace staleness** —
`currentWorkspace.featureFlags` may be one round-trip stale on warm
load.
- **`X-Schema-Version` header** — sourced from
`currentWorkspace.metadataVersion`; caching it actually makes the header
*consistent* with the already-cached metadata rather than absent, but
worth confirming against the server's mismatch handling.
- **Test isolation** — these atoms now persist; tests relying on the
default `null` could see cross-test leakage if `localStorage` isn't
reset. The directly-affected suites pass locally (`useAuth`,
`useDefaultHomePagePath`, `useSetNextOnboardingStatus`); CI's full run
is the real check.

## Validation

- [ ] Full CI (types/lint/unit) green
- [ ] Manual: throttle network, hard-reload a logged-in workspace,
confirm the shell paints before `GetCurrentUser` resolves and that fresh
data writes through
- [ ] Sign out → sign in as a different user on the same browser;
confirm no stale identity flashes
 2026-06-13 18:38:45 +02:00
neo773 5d892bdfd0 [WIP] Feat/marketing emails (#21173) 
Marketing/campaign emails on top of the emailing-domain (SES) feature:
send a broadcast to a hand-picked list, with per-customer-domain
unsubscribe links and opt-out-only **unsubscribe topics**.

## Model

Standard objects (workspace schema, flat-metadata):
- `messageCampaign` — a campaign send (subject, body template, from
address, status, list, optional unsubscribe topic).
- `messageList` + `messageListMember` — the hand-picked audience (person
↔ list join). A campaign's recipients are its list's members; everyone
is sendable unless suppressed.

Core entities (`core` schema, workspace-scoped — readable by the public
unsubscribe flow without a workspace context):
- `unsubscribeTopic` — an opt-out-only category (name, description,
visibility). There is no opt-in subscription state.
- `messageSuppression` — the single consent store: a row with
`unsubscribeTopicId` NULL is a global block; a row with an
`unsubscribeTopicId` and reason `UNSUBSCRIBE` is a per-topic opt-out.
Two partial unique indexes dedupe global vs per-topic rows (Postgres
treats NULLs as distinct).
- `emailingDomain` — the workspace's SES sending domain,
auto-provisioned when an email channel is added (and cleaned up when its
last channel is removed), with verification status + DNS records.

Campaign messages reuse the existing `message` / `messageThread` /
`messageParticipant` model — one outbound `message` per recipient with a
`deliveryStatus` state machine.

## Sending

- `sendMessageCampaign` resolves the audience **under the caller's
permissions**, creates the campaign, and enqueues a single fan-out job
(the request never materializes per-recipient rows or jobs).
- The fan-out job materializes one QUEUED message per recipient
(deterministic ids → idempotent re-runs, reconciles crash-orphaned rows)
and fans out per-recipient send jobs carrying **only ids**.
- Each send job renders per-recipient `{{variable}}` merge fields and
sends via `EmailingDomainSenderService`, which applies suppression
(global + per-topic) and the unsubscribe footer/headers. Suppressed
recipients are recorded `SKIPPED`.
- The campaign finalizes `SENT`, or `SENT_WITH_ERRORS` if any recipient
terminally failed.
- `previewMessageCampaignAudience` returns a pre-send breakdown (total /
without-email / duplicate / globally-unsubscribed / topic-unsubscribed /
sendable), shown as a hint under the composer pickers.

## Unsubscribe

- Encrypted (AES-256-GCM) token carrying workspaceId, address, optional
`unsubscribeTopicId`, `issuedAt`, and a `preview` flag.
- One-click POST (RFC 8058) + `mailto:` — topic-scoped when the token
carries a topic, global otherwise.
- Preferences page: a checkbox per visible topic (checked = still
receiving); submitting creates per-topic opt-outs for unchecked topics
and lifts re-checked ones (UNSUBSCRIBE only — never
`BOUNCE`/`COMPLAINT`, never a global block).
- A **Preview** action in settings opens the live page via a
preview-claim token; opt-out POSTs are no-ops for preview tokens, so
previewing never mutates state.
- SES webhooks: inbound unsubscribe + outbound bounce/complaint →
suppression (race-safe against at-least-once delivery, with reason
escalation that never downgrades).
- Per-customer unsubscribe hostname (Cloudflare DNS); sends are gated on
it being active, except in LOG/demo mode.

## Architecture

Campaign orchestration, suppression, the sender, the unsubscribe
controller, and the SES webhook handlers live in `src/modules/emailing`
+ `src/modules/messaging-webhooks` (the workspace-feature layer).
`core-modules/emailing-domain` keeps the SES driver, domain
provisioning, the `unsubscribeTopic` / `messageSuppression` core
entities, and the unsubscribe token/hostname plumbing. Domain creation
is validated (`CreateEmailingDomainInput` — domain-format regex,
lowercased) before any value reaches SES or the unsubscribe hostname.

## Frontend

- Campaign composer side panel (from / list / unsubscribe topic /
subject / body) with a live audience-preview hint.
- Email settings: email channels each showing their auto-provisioned
sending domain in a single section (status + DNS records + a "Check
verification" action), plus an **Unsubscribe Topics** section to
create/manage topics and preview the recipient page. A demo-mode banner
is shown when the LOG driver is active.

---------

Co-authored-by: Félix Malfait <felix@twenty.com>
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
 2026-06-13 18:37:39 +02:00
Félix Malfait 2c5da39dc5 perf(front): load Front chat during browser idle time (#21533) 
## Context

The Front support chat bundle
(`chat-assets.frontapp.com/v1/chat.bundle.js`, ~2.3s in a profiling
trace) was being injected only `500ms` after auth + client-config +
workspace-member resolved (`useInstantiateSupportChat.ts`). Because the
effect's gating conditions are themselves network-bound, that `500ms`
still lands the fetch + execute **inside the critical boot window**
(metadata load + first render), where the bundle competes for bandwidth
and main-thread time.

Two pre-existing issues:
- The `500ms` delay was too short to clear the critical window.
- The injected `<script>` already had `defer = true`, but `defer` is a
no-op on dynamically-inserted scripts (they're `async` by default), so
it contributed nothing.
- The `setTimeout` was never cleared, so an effect re-run within the
delay could schedule duplicate loads.

## Change

- Add a small `scheduleIdleCallback(callback, { timeout })` helper
(`src/utils/`) that runs work during a browser idle period via
`requestIdleCallback`, capped by `timeout`, and returns a canceller.
- Use it in `useInstantiateSupportChat` with a `2000ms` cap, and
**return the canceller from the effect** so a pending load is cancelled
on re-run/unmount.

### Why not gate on first interaction?
The launcher must appear proactively to surface an unread-reply badge,
so it has to load without user action. `requestIdleCallback` keeps it
proactive while yielding to the critical path.

### Safari / iOS
`requestIdleCallback` is disabled by default in all shipping Safari/iOS
versions (not Baseline). The helper falls back to a plain `setTimeout`
of the same duration there. Because `requestIdleCallback`'s `timeout` is
a *maximum* (it fires earlier at the first idle gap) while `setTimeout`
fires *at* that value, a single `2000ms` value gives:
- **Chrome/Firefox/Edge/Android**: loads at first idle, guaranteed
within 2s.
- **Safari/iOS**: loads at 2s (a fixed, longer delay — 4× the old
500ms).

Both paths are strictly better than the previous behavior.

## Testing

- `scheduleIdleCallback` unit tests (both the `requestIdleCallback` and
the fallback path, plus cancellation) — 4/4 pass.
- `npx nx typecheck twenty-front` — passes.
- `oxlint --type-aware` + `oxfmt` on changed files — clean.

https://claude.ai/code/session_013YXr5yNGFH1NYUe4ysmiEy

---
_Generated by [Claude
Code](https://claude.ai/code/session_013YXr5yNGFH1NYUe4ysmiEy)_

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21533?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: Claude <noreply@anthropic.com>
 2026-06-13 17:53:09 +02:00
Félix Malfait 76f69efb43 Keep synced messages and events when removing a workspace member (#21443) 
## Context

Removing a workspace member deletes their connected accounts, which
cascades into deleting every message and calendar event those accounts
synced. For a CRM, losing the email history of departed teammates is a
big deal.

## What this does

Connected accounts are now kept and reassigned instead of deleted when a
member is removed:

- Ownership moves to the acting user (whoever removed the member). When
members remove themselves (leave workspace, account deletion), it falls
back to the oldest admin.
- OAuth tokens are revoked, credentials wiped, message/calendar channels
get `isSyncEnabled = false`, and the account is stamped with a new
`archivedAt` column (fast instance command included).
- Synced messages, threads and calendar events stay in the workspace.
Channel visibility settings keep applying as before, since channels and
associations survive.
- The reassigned account appears in the new owner's Settings → Accounts,
where it can still be deleted (with its data) like any other account.

The transfer happens synchronously during removal, while the member's
userWorkspace row still exists. This also removes
`DeleteWorkspaceMemberConnectedAccountsCleanupJob` and its listener: the
async job had to reconstruct the account-owner link from rows the
removal flow had just deleted, which was race-prone (see 2181fb541e).

Archived accounts are excluded from the workflow send-email default
account resolution, and both removal confirmation modals now mention
what happens to synced data.

---------

Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>
 2026-06-13 15:52:13 +02:00
Weiko f63f053444 CommandMenuItem overridable entity (#21486) 
## Context
Second PR of the overridable-entities track (after #21436 for views):
command menu items become overridable so that edits on non-owned items
are stored as overrides instead of mutating the row, and
deletion/deactivation becomes reversible.

 ## What this does

- `CommandMenuItemEntity` now extends
`OverridableEntity<CommandMenuItemOverrides>` (adds `isActive` +
`overrides`). All editable properties are overridable for now (to
discuss).
- **Update**: mutations on a command item not owned by the caller
(standard items) are written into `overrides`; reads merge them in the
DTO. The command palette edit mode (pin,
reorder, shortLabel) now preserves standard values, "Reset label to
default" gains true post-save semantics.
- **Delete**: protected items are deactivated (`isActive = false`)
instead of deleted; custom items still hard-delete.
- **Object deactivate/enable toggle**: now flips `isActive` on the
command item (merged into the main migration call) instead of
delete/recreate; a create-if-missing fallback covers legacy deactivated
objects.
- **Front**: inactive command items are filtered out of the palette
selector.


<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21486?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>
 2026-06-13 14:21:27 +02:00
Félix Malfait 036d9a2bcf feat: gate record creation on isUICreatable only, decoupled from isSystem (#21527) 
## Context

The generic "create a record" UI affordance previously required
`!isSystem`, conflating two distinct concerns: **"hidden from Data
Model"** and **"not user-creatable"**. This blocked legitimately
creatable system objects (e.g. marketing message lists kept `isSystem:
true` only to stay out of the Data Model).

This PR makes creatability depend on `isUICreatable` alone, so
visibility (`isSystem`) and creatability (`isUICreatable`) become
independent.

## Changes

- **Front gate** (`canCreateRecordsForObjectMetadataItem.ts`): drop the
`!isSystem` clause — creatability is now `isUICreatable && !readOnly`.
Updated comment + unit test.
- **Command menu** (`standard-command-menu-item.constant.ts`): drop the
matching `not objectMetadataItem.isSystem` clause from the
`createNewRecord` availability expression so the "Create new X" command
mirrors the front gate. Existing workspaces get this via the
already-present `SyncCreateRecordCommandAvailabilityExpressionCommand`,
which re-syncs from the live definition.
- **Standard object audit**
(`create-standard-flat-object-metadata.util.ts`): the 15
sync/system-created standard objects that relied on `!isSystem` to stay
non-creatable now set `isUICreatable: false` (attachment, blocklist,
calendar*/message*/note/task targets, message, messageThread,
messageParticipant, timelineActivity, callRecording,
workflowAutomatedTrigger, …).
`workflowRun`/`workflowVersion`/`workspaceMember` were already `false`.
Non-system objects (company, person, note, opportunity, dashboard, task,
workflow) are untouched.
- **Backfill**: new fast instance command
(`2-13-…-1781277480000-backfill-non-ui-creatable-standard-system-objects.ts`)
runs `UPDATE core.objectMetadata SET isUICreatable = false` for those
standard system objects (symmetric `down`), registered in
`instance-commands.constant.ts`.

`isSystem` and Data-Model visibility logic are unchanged.

## Verification

- Front gate unit test (7 pass), standard-application suite incl.
callRecording (10 pass)
- `oxlint` clean on all changed files
- `twenty-server` and `twenty-front` typecheck green

🤖 https://claude.ai/code/session_01TF4kjD56hHjP31wkHPxPv3

---
_Generated by [Claude
Code](https://claude.ai/code/session_01TF4kjD56hHjP31wkHPxPv3)_

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21527?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: Claude <noreply@anthropic.com>
 2026-06-13 14:05:42 +02:00
Thomas des Francs b14195428a Fix navigation and settings UI polish (#21523) 
## Summary

This PR groups the requested UI polish pass across navigation, settings,
AI settings, data model, community/lab, and dashboard chips.

### Navigation and drawer polish
- Smooths app/settings route switching with a 300ms content transition.
- Smooths app menu/settings menu drawer swaps with a fade transition
while preserving the existing drawer dimensions.
- Keeps navigation and AI chat history panes mounted to avoid flicker
when switching tabs.
- Aligns the first app/settings section with the AI chat history section
title.
- Removes the main app navigation "Other" section.
- Aligns the settings exit header with the workspace switcher header.
- Sets the settings exit icon gap to 8px, uses the small icon stroke
token, and keeps the icon color on text-secondary.
- Makes the workspace switcher button 28px high inside its 32px
container, moves the dropdown up so the workspace name does not jump,
and keeps a 2px gap between header icon buttons.
- Moves Settings below Support in the workspace switcher menu.
- Pins the Advanced toggle to the bottom of the settings drawer and
aligns its right padding with nav items.

### Settings surface polish
- Fixes vertically cropped dropdown menu headers.
- Makes wizard parent titles tertiary when a nested wizard title is
visible.
- Places danger-zone buttons side by side.
- Uses a 32px Visualize button.
- Restores 8px top/bottom padding on settings tables.
- Separates AI overview counts into three columns like layout overview.
- Adds separators inside setting cards, including the Smart Model / Fast
Model card.
- Groups lab/early-access toggles into one card with separators and
full-width row backgrounds.
- Replaces deprecated Enterprise adornment tags with the Organization
adornment on gated AI/security/settings surfaces.
- Uses the Discord brand icon in Community while keeping the standard
icon component rendering pattern.
- Tightens Skills/Tools search-to-table spacing so switching tabs does
not shake the table top.
- Fixes the small gap in nested navigation breadcrumbs between Emails
and Calendars.

### Dashboard/data table polish
- Fixes vertically cropped "Not shared" chips on dashboards.
- Keeps table row/header spacing stable after the settings table padding
restoration.

## Validation

- `npx nx lint:diff-with-main twenty-front`
- `npx tsc -p packages/twenty-front/tsconfig.json --noEmit`
- Manual Chrome pass on `apple.localhost:3001` for profile, app
navigation, workspace switcher, AI overview/models/skills/tools/usage,
community/lab, data model, new-field wizard, and dashboards.

## Visual QA

### Settings surface fixes

<img width="1324" height="2668" alt="Settings surface fixes before/after
board"
src="https://github.com/user-attachments/assets/312131fa-3922-4724-9460-46fd373754d1"
/>

### Navigation drawer fixes

<img width="1324" height="1816" alt="Navigation drawer fixes
before/after board"
src="https://github.com/user-attachments/assets/ca0b29e5-e393-46c0-81f7-e6bed2557b59"
/>

### Tables, wizards, gates and chips

<img width="1324" height="2242" alt="Tables, wizards, gates and chips
before/after board"
src="https://github.com/user-attachments/assets/5f358240-c31c-4c15-8ca8-04ed761fbf85"
/>
 2026-06-13 13:13:55 +02:00
Charles Bochet 869680a5a1 fix(deps): esbuild ^0.28.1 floors + vite 7→8 (rolldown) upgrade (#21517) 
## 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.
 2026-06-13 10:44:22 +00:00
Félix Malfait 1efa3567ef Rename isUIReadOnly to isUIEditable, add isUICreatable, expose both to app developers (#21504) 
<!-- CURSOR_AGENT_PR_BODY_BEGIN -->
# UI capability flags: `isUIEditable` + `isUICreatable`

## Per-verb capability model

This PR replaces the negative `isUIReadOnly` metadata flag with
positive, per-verb capability flags (à la Salesforce
`createable`/`updateable`):

- **`isUIEditable: boolean`, default `true`** — rename of `isUIReadOnly`
with inverted polarity, on **both** `objectMetadata` and
`fieldMetadata`. It is one concept ("can the user edit this through the
generic UI?") at two altitudes, so it carries one name at both levels.
- **`isUICreatable: boolean`, default `true`** — new, **object-level
only** (fields have no create verb). When `false`, no generic UI
affordance to create a record of this object appears anywhere (table "+"
buttons, board column add, calendar add, relation-section "Add new",
record picker "Add new", command-menu create action and its keyboard
shortcut).

Both flags are **UI-affordance flags only**: the server does not block
create/edit mutations based on them, so the system, API, and workflows
continue to mutate these records freely. They are orthogonal statements
about the object's nature with no implication rule in the data model.
Because today's inline creation UX creates a blank record the user must
then edit, the frontend create predicate currently requires both
`isUICreatable` and effective editability.

There is no CREATE permission in `ObjectPermissions`; the frontend keeps
gating creation on `canUpdateObjectRecords` as a proxy, ANDed with the
new flags.

## Unified create predicate

All generic creation entry points now flow through one predicate,
`canCreateRecordsForObjectMetadataItem` (`isUICreatable` && not
`isSystem` && not effectively read-only, where effective read-only
covers `isUIEditable`, `isRemote`, and the `canUpdateObjectRecords`
proxy via `isObjectMetadataReadOnly`). This deletes the previously
hardcoded suppression lists:

- `isRecordTableCreateDisabled.ts` and its hardcoded
`WorkflowRun`/`WorkflowVersion` list — deleted; those objects (plus
`workspaceMember`) now declare `isUICreatable: false` in the standard
application instead.
- The hardcoded `workspaceMember` guard inside
`useAddNewRecordAndOpenSidePanel.ts` — deleted.
- The `CREATE_NEW_RECORD` command menu item's availability expression
now checks `objectMetadataItem.isUICreatable`, `isUIEditable`,
`isSystem`, and `isRemote`; a workspace upgrade command re-syncs the
expression in existing workspaces.

Component-local conditions (soft-delete filter active, layout
customization mode) stay in their components.

## GraphQL compatibility and removal plan

The schema delta versus main is **purely additive plus deprecations —
zero breaking changes**:

- `isUIReadOnly` remains on both the ObjectMetadata and FieldMetadata
GraphQL output types for **one release** as a deprecated field computed
as `!isUIEditable` (`deprecationReason: 'Use isUIEditable'`). The Twenty
frontend no longer queries it.
- `isUIReadOnly` also remains on the **input side** for one release
(`CreateFieldInput`, `UpdateFieldInput`, `FieldFilter`, `ObjectFilter`),
keeping the schema shape identical to main for those members. On create
it acts as a legacy alias mapped to `!isUIReadOnly` (`isUIEditable` wins
when both are provided); on update it is ignored, exactly as on main (it
was never an editable property). Filtering on the deprecated member
keeps working until the column is dropped at upgrade time; after that it
is a deprecated no-op surface kept only for schema compatibility.

**Removal plan for next release: drop `isUIReadOnly` from the output
DTOs (and resolvers' `@ResolveField`s), from the input/filter types,
from the create-input mapping, and the `@WasRemovedInUpgrade`-retained
entity columns and decorators.**

## ⚠️ Webhook / database-event payload shape change

The `database-event-payload` type in `twenty-shared` got a clean rename
(no alias): metadata snapshots in webhook and database-event payloads
now carry `isUIEditable` (and `isUICreatable` at object level) **instead
of** `isUIReadOnly`, with inverted polarity. Consumers of these payloads
that read `isUIReadOnly` must switch to `isUIEditable`.

## New manifest properties (app-developer DX)

Application developers can now set these flags in their app manifests
(purely additive — existing manifests and older `twenty-sdk` versions
are unaffected, defaults apply when omitted):

- `objects[].isUICreatable?: boolean` (default `true`)
- `objects[].isUIEditable?: boolean` (default `true`)
- `fields[].isUIEditable?: boolean` (default `true`)

The manifest converters previously hardcoded `isUIReadOnly: false`; they
now read the manifest values with `?? true` defaults. The types are
re-exported through `twenty-sdk` from `twenty-shared`.

## Migration & backfill

- One fast instance command: adds `isUIEditable` (NOT NULL default
`true`) on `core."objectMetadata"` and `core."fieldMetadata"`, backfills
`isUIEditable = false` exactly where `isUIReadOnly = true`, drops
`isUIReadOnly`, and adds `isUICreatable` (default `true`) on
`objectMetadata`. The `down` is the exact inverse. Uses `ADD/DROP COLUMN
IF (NOT) EXISTS`, matching the 2-12 drop-`isCustom` precedent. Verified
up and down in separate transactions against a dev database with exact
backfill counts.
- **Cross-version upgrade safety (multi-version self-hosted jumps):**
the upgrade sequence interleaves per version (instance → workspace
commands), so pre-2.13 workspace commands run **before** the 2.13 rename
when an old instance jumps several versions. Following the `isCustom`
precedent: `isUIEditable`/`isUICreatable` are marked
`@WasIntroducedInUpgrade` and `isUIReadOnly` stays on both entities as
`@WasRemovedInUpgrade`, so the upgrade-aware entity metadata adapter
hides the not-yet-existing columns (and keeps the legacy column live) at
pre-2.13 cursors. **No committed upgrade command outside the 2-13
directory is modified**: the old 1-21/2-8/2-9 commands keep their
original `isUIReadOnly: true` inputs, which still compile (entity
property retained, deprecated create-input alias mapped) and still
produce the correct legacy column writes pre-rename.
- A 2-13 workspace command (`sync-standard-ui-capability-flags`)
re-syncs `isUICreatable` **and** `isUIEditable` on standard objects and
`isUIEditable` on standard fields from the standard-application
definitions. This backfills `isUICreatable: false` on
`workflowRun`/`workflowVersion`/`workspaceMember` and heals fields
created mid-cross-upgrade by pre-2.13 commands (whose hidden
`isUIEditable` value cannot reach the insert). Both 2-13 sync commands
pass `isSystemBuild: true` — the flat metadata validator otherwise
rejects direct updates to system objects (verified against a
deliberately drifted dev database; the run is idempotent).
- A second 2-13 workspace command re-syncs the create-record command
availability expression.

## Testing

- Unit tests for `canCreateRecordsForObjectMetadataItem`
(flag/permission/system combinations) and for the manifest converters
(flags set / omitted → defaults).
- Full `upgrade --dry-run` boots the sequence (107 steps) and validates
the upgrade-aware decorator references; both 2-13 sync commands verified
end to end against real drift and re-run idempotently.
- Schema verified by live introspection after the input-alias restore:
all four input/filter members match main, output deprecations intact;
frontend metadata types and `twenty-client-sdk` schema regenerated from
the running server.
- Read-only-related and touched jest suites pass on both packages;
typecheck and lint pass on `twenty-server` and `twenty-front`.
<!-- CURSOR_AGENT_PR_BODY_END -->

<div><a
href="https://cursor.com/agents/bc-0f3e04cb-b04a-40be-8330-5609c4538e8a"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://cursor.com/assets/images/open-in-web-dark.png"><source
media="(prefers-color-scheme: light)"
srcset="https://cursor.com/assets/images/open-in-web-light.png"><img
alt="Open in Web" width="114" height="28"
src="https://cursor.com/assets/images/open-in-web-dark.png"></picture></a>&nbsp;<a
href="https://cursor.com/background-agent?bcId=bc-0f3e04cb-b04a-40be-8330-5609c4538e8a"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://cursor.com/assets/images/open-in-cursor-dark.png"><source
media="(prefers-color-scheme: light)"
srcset="https://cursor.com/assets/images/open-in-cursor-light.png"><img
alt="Open in Cursor" width="131" height="28"
src="https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a>&nbsp;</div>



<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21504?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: Cursor Agent <cursoragent@cursor.com>
 2026-06-13 07:10:22 +02:00
Charles Bochet ee6fcdbec2 fix(front): show readable targets in morph relation picker (#21513) 
## Problem

The **morph relation picker is broken** when the user does not have read
permission on *every* object a morph relation can point to.

A morph (polymorphic) relation can target several objects. The
single-record picker passed **all** of those target objects to the
`search` query via `includedObjectNameSingulars`. The backend runs the
per-object searches inside a single `Promise.all`, so if **one** target
object is forbidden, the whole search rejects and the picker shows **"No
records found"** — even for the target objects the user *can* read.

This makes the morph relation picker unusable in any workspace where a
role restricts read access to one of the morph targets (e.g. the demo
workspace's `Object-restricted` role, which denies reading `Rocket` —
the picker for a Pet's polymorphic owner then shows nothing, hiding the
readable `Survey result` records too).

## Fix

Filter the searched target objects down to the ones the current user is
allowed to read before querying, in
`useSingleRecordPickerPerformSearch`. This mirrors what the
multiple-record picker (`useMultipleRecordPickerPerformSearch`) already
does via `filteredSearchableObjectMetadataItems`.

For a normal (single-target) relation this is a no-op; for a morph
relation the picker now lists records from every target the user can
read and silently skips the forbidden ones.

## Test

Added `useSingleRecordPickerPerformSearch.test.tsx`:
- excludes morph target objects the user cannot read from the search
- keeps all targets when the user can read all of them

## Verification

Reproduced locally on a Pet's "Polymorphic Owner" morph relation
(targets `Rocket` + `Survey result`) with `Rocket` read denied:
- **Before:** picker shows "No records found".
- **After:** picker lists the readable `Survey result` records and omits
the `Rocket` ones.

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21513?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. -->
 2026-06-12 23:28:50 +02:00
Charles Bochet d22fa377e7 fix(front): store auth tokenPair in localStorage instead of a cookie (#21507) 
## Problem

A client hit an AWS S3 `RequestHeaderSectionTooLarge` error
(`MaxSizeAllowed 8192`) when opening a
`https://<workspace>.twenty.com/verify?loginToken=<JWT>` link — the
request to load the `/verify` SPA page is served from S3, which rejects
it before the app loads.

The dominant cause is the **`tokenPair` cookie**. The auth tokenPair
(access + refresh JWTs, ~2–5KB) was persisted in a host-scoped,
JS-readable cookie. Nothing server-side ever reads it — the access token
is sent to the API via an `Authorization: Bearer` header set in the
Apollo auth link (`ExtractJwt.fromAuthHeaderAsBearerToken()` on the
backend; no `cookie-parser`). Yet the browser attached that cookie to
**every** request to the origin, including static assets and the
`/verify` page. Combined with the `loginToken` in the URL, the request
header section exceeds S3's 8192-byte limit.

## Fix

Move `tokenPair` from cookie storage to **localStorage**, which is never
transmitted in request headers.

- `tokenPairState` now uses `useLocalStorage` (with `getOnInit: true`).
- `getTokenPair` (the synchronous read used by the Apollo auth link)
reads from localStorage under the same key.
- A one-time migration (`migrateTokenPairCookieToLocalStorage`) runs
before React renders: it ports any existing `tokenPair` cookie into
localStorage and **deletes the cookie**, so already-authenticated users
aren't logged out and the oversized cookie stops being sent.

## Why this is safe

**Behavior:** equivalent. The cookie was host-scoped (no `domain`
attribute), so it never provided cross-subdomain sharing —
cross-workspace auth already re-establishes the token per-origin via the
`loginToken`-in-URL → `/verify` handoff. localStorage has identical
origin scoping.

**Security:** neutral-to-positive.
- No XSS protection lost — the cookie was **not** `httpOnly` (it can't
be; JS reads it to build the Bearer header), so it was already
XSS-exposed exactly like localStorage.
- No CSRF surface change — the token was never sent as a cookie
credential (no `credentials: 'include'`).
- **Reduced exposure** — the token no longer leaks into CDN/proxy/server
access logs or request headers, which is the actual bug.
- Server-side revocation (`revokedAt`) and the 60-day refresh-token JWT
expiry govern validity, so localStorage's lack of auto-expiry is moot.

## Testing

- `getTokenPair` unit tests updated to localStorage.
- New unit tests for the migration util (port, no-op, no-clobber,
error-safety).
- `nx test twenty-front` auth + apollo suites: 125 passing.
- `lint:diff-with-main` clean; changed files typecheck clean.


<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21507?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. -->
 2026-06-12 22:39:20 +02:00
Rahman Husain e269b51f40 Fix: Improve UX by explaining email edit restriction for multi-workspace users (#18750) 
### Fix: inform users why email edit is disabled for multi-workspace
accounts (#18733)

#### Issue
Users were unable to change their email even when:
- Email field is enabled in Security settings  
- User has permission to edit profile details  

This occurs when the user belongs to **multiple workspaces**, but there
was no feedback explaining why the edit action was disabled, causing
confusion.

#### Solution
- Added a tooltip/popup on hover over the email edit (pen) icon  
- Tooltip informs users that email cannot be changed if they belong to
**2 or more workspaces**

#### Result
- Provides clear feedback to users  
- Reduces confusion around email edit restrictions  
- Improves overall user experience  

#### Notes
- No changes to permission or backend logic  
- Purely a UI/UX improvement  

Fixes twentyhq/core-team-issues#2335

---------

Co-authored-by: Charles Bochet <charles@twenty.com>
 2026-06-12 17:45:07 +00:00
Charles Bochet 247e422eac fix(front): prevent timeline "Invalid configuration" on update events without a diff (#21460) 
## Fixes #20597

### Problem
A person's (or any record's) timeline renders the whole widget as
**"Invalid configuration"** when it contains an `*.updated` event
without a usable `properties.diff`.

The error-boundary fallback (`PageLayoutWidgetInvalidConfigDisplay`) is
triggered because `EventRowMainObjectUpdated` **throws** during render:

```ts
const diff = event.properties?.diff;       // can be undefined
const diffEntries = Object.entries(diff);  // throws TypeError when undefined
if (diffEntries.length === 0) {
  throw new Error('Cannot render update description without changes');
}
```

`filterOutInvalidTimelineActivities` only validates activities that
**already carry** a diff (`canSkipValidation = !diff`), so a main-object
`*.updated` event with a missing diff passes straight through to this
renderer and crashes it. A single malformed row takes down the entire
timeline.

### Fix
Render nothing instead of throwing when an update event has no changes
to show. This mirrors the sibling `EventRowMainObject` default branch
(which returns `null`) and the filter's own behaviour of dropping empty
diffs, and keeps one bad row from crashing the whole widget.

The fix is intentionally kept in the renderer rather than the filter:
the filter cannot distinguish a diff-less main-object update (must be
dropped) from a diff-less `linked-task`/`linked-note` update
(legitimately has `properties: {}` and renders fine via
`EventRowActivity`) without duplicating routing logic.

### Test
Added `EventRowMainObjectUpdated.test.tsx` — a regression test asserting
the component renders nothing (no throw) for both a missing-diff and an
empty-diff update event.
 2026-06-12 18:58:05 +02:00
Thomas Trompette ba94c3b857 feat(workflow): idempotent stop + retry failed runs from failing step (#21458) 
https://github.com/user-attachments/assets/5a25396f-8959-4bd8-93cb-1187559ffe5f



## Summary

Two workflow-run improvements, with all non-trivial logic isolated in
pure, unit-tested utils.

### 1. Idempotent stop
`stopWorkflowRun` no longer throws when a run is already in a terminal
status (`COMPLETED` / `FAILED` / `STOPPED`) or already `STOPPING`; it
returns the run unchanged. This fixes:
- bulk stop aborting on the first non-stoppable run in a
mixed/select-all selection,
- the click-vs-processing race on a single run (run finishes between
click and mutation).

It also releases the cached not-started throttle slot when stopping a
`NOT_STARTED` run (prevents counter drift), and ends runs with no
`state` directly.

### 2. Retry a failed run from the failing step
New `retryWorkflowRun` mutation (same guards/passthrough as
`stopWorkflowRun`). It resets the failed step(s) to `NOT_STARTED`, flips
the run to `RUNNING`, and enqueues a `RunWorkflowJob` with the steps to
re-execute; downstream execution and status computation are unchanged.

Logic lives in pure utils:
- `build-retry-step-infos.util.ts` - decides per failed step what to
reset; delegates iterator-specific logic to
`build-retry-iterator-step-infos.util.ts` (an iterator that failed
mid-loop is restored to `RUNNING` with cursor preserved, an iterator
that failed itself restarts its whole loop).
- `get-runnable-step-ids.util.ts` - reuses the executor's
`shouldExecuteStep` to also resume branches that never started (avoids
hangs), excluding loop-interior steps.

The service method only orchestrates; the job's status check is a race
guard (retriability is enforced in the service before enqueue).

A "Retry" command menu item surfaces only for `FAILED` runs
(`someEquals(selectedRecords, "status", "FAILED")`).

### 3. Keep the run diagram visible across regenerations
The run diagram is regenerated on every run state change, producing
fresh nodes without the dimensions Reactflow had measured. Reactflow
hides unmeasured nodes until it re-measures them, so the diagram could
flicker and disappear when the last regeneration before going idle left
nodes unmeasured (reproducible after retrying a failed run). The
regenerated nodes now carry over the previously measured dimensions (by
id) so they stay rendered.

## Test plan
- [x] Unit tests for both retry utils (9 cases: plain failed step,
non-failed untouched, iterator mid-loop restore, iterator self-failure,
frontier parent gating, entry steps, loop-interior exclusion, parallel
branches)
- [x] `twenty-server` + `twenty-front` typecheck
- [x] `lint:diff-with-main` clean for both packages
- [x] Manual: retry a failed run repeatedly and confirm the diagram
stays visible
- [ ] Manual: stop a COMPLETED/mixed selection (no error), retry a
failed run and confirm it resumes from the failing step
 2026-06-12 15:25:53 +00:00
Thomas Trompette a8a8bbb2ed feat(workflow): add offset to Find Records node for pagination (#21484) 
<img width="471" height="362" alt="Capture d’écran 2026-06-12 à 15 38
45"
src="https://github.com/user-attachments/assets/9656d3a6-6f56-4587-add6-55c0a0a32482"
/>

## Summary

The workflow Find Records (search) node previously exposed only
`objectName`, `filter`, `sort`, and `limit` (capped at
`QUERY_MAX_RECORDS` = 200), with no way to page beyond the first page of
results.

This adds an optional **Offset** to the node so a workflow can fetch an
arbitrary page (`offset = pageIndex * limit`) while keeping the same
filter and sort. The underlying `FindRecordsService` already accepts
`offset` (it forwards it to the query runner's `skip`, and stabilizes
ordering with an `id` tiebreaker), so this change just threads `offset`
through the remaining layers:

- `workflowFindRecordsActionSettingsSchema` (shared zod schema) — new
optional `offset`
- `FindRecordsInput` type — new optional `offset?: number`
- `find-records.workflow-action.ts` — forwards `offset` to
`FindRecordsService.execute`
- `WorkflowEditActionFindRecords.tsx` — new "Offset" number input
(non-negative, defaults to 0) with form state + persistence
- Default `FIND_RECORDS` step settings — `offset: 0`

### Notes / non-goals
- Offset-only, single page: the node returns one page. Looping over all
pages inside one run is not included (the Iterator action loops a static
array and cannot re-query). The node output already returns
`totalCount`, so a workflow can compute total pages as `ceil(totalCount
/ limit)`.
- Offset on very large/changing datasets can be slow or skip/duplicate
rows; cursor/keyset pagination would be a future follow-up.

## Test plan
- [x] Create a Find Records node, set Limit=50, Offset=0 → returns first
page
- [x] Set Offset=50 with the same filter/sort → returns the second page
(no overlap)
- [x] Negative offset shows a validation error and is not saved
- [x] Existing Find Records nodes (no offset stored) still run,
defaulting to offset 0
- [x] Typecheck/lint pass in CI

<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21484?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. -->
 2026-06-12 14:11:53 +00:00
Raphaël Bosi bd4161a905 Show app logo on workflow logic function nodes (#21482) 
Workflow `LOGIC_FUNCTION` action nodes (functions provided by an
installed app) previously rendered a generic ƒ icon in the diagram. They
now display the owning app's logo instead.

The node's logic function id is resolved to its `applicationId` and
rendered via the existing `AppChip`. When no app can be resolved (e.g.
the logic function isn't loaded yet, or has no application), it falls
back to the original ƒ icon, so nodes never look broken. Inline `CODE`
actions are unchanged.

## Before
<img width="692" height="670" alt="CleanShot 2026-06-12 at 15 27 22@2x"
src="https://github.com/user-attachments/assets/4d7c17ce-dbe3-45e6-9d44-41e363b2e4a5"
/>

## After

<img width="592" height="628" alt="CleanShot 2026-06-12 at 15 26 22@2x"
src="https://github.com/user-attachments/assets/d55c308f-3cde-4153-8d5d-ec948bebc823"
/>


<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21482?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. -->
 2026-06-12 13:36:30 +00:00
Raphaël Bosi c4453923f0 Update CI: Argos visual regression for twenty-front storybook (#21454) 
## What

Adds Argos visual regression for `twenty-front`, reusing the storybook
CI already builds and the existing sharded test matrix. Stories in the
`modules` and `pages` scopes are captured as PNGs during
`front-sb-test`, merged into one artifact, and pixel-diffed against
`main` on the self-hosted Argos with results posted as a PR comment —
same pipeline as `twenty-ui` (#21210 / #21262).

## How

- **Capture**: `@argos-ci/storybook` vitest plugin, same setup as
`twenty-ui`. Skipped for `performance` stories (nondeterministic
profiling reports). Freezes framer-motion to avoid flaky diffs (#21412).
- **Sharding**: each modules/pages shard uploads a partial artifact; a
new `front-sb-screenshots` job merges them into
`argos-screenshots-twenty-front` (`overwrite: true` so re-runs work).
- **Baselines**: `CI Front` now runs on `push: main` — Argos resolves
base builds by exact merge-base commit, so every main commit needs a
build (#21217/#21222 pattern). Main pushes get a per-SHA concurrency
group so back-to-back merges can't cancel queued runs and leave baseline
gaps; the `performance` scope is dropped on push.
- **Dispatch**: `visual-regression-dispatch.yaml` watches `CI Front` →
`project=twenty-front`.

## Rollout

- ✅ Prod Argos project `twenty-front` created (id 68) +
`ARGOS_TOKEN_FRONT` secret set
- ⬜ Merge the twentyhq/ci-privileged companion PR **before** this one
- First PR builds show as *orphan* until the first main push creates a
baseline
  (expected, same as the twenty-ui rollout)
 2026-06-12 13:36:16 +00:00
Matt Van Horn cb653e4ecc feat: inline image thumbnails and legacy-label fallback for FILES field chips (#21294) 
## Summary

Custom FILES field chips now show an inline image thumbnail for image
attachments and fall back to the legacy label when an attachment
predates filename storage. This covers two of the UX complaints n2ojim
collected in #20942: image files were indistinguishable from other
attachments, and older attachments rendered with an empty chip label.
The 10-file cap from the same issue already shipped in #20950; the
gallery/grid layout and hover-delete affordances are deliberately left
for follow-ups per the maintainer's cost notes on the thread.

## Why this matters

#20942 is founder-tagged UX feedback on the new custom FILES field: once
a record carries more than a couple of attachments, users scan chips
visually, and a thumbnail answers "which one is the screenshot" without
opening anything. The fallback keeps old records readable instead of
showing blank chips. Changes stay inside `FileChip.tsx` and follow the
existing file-display patterns; Storybook stories cover both behaviors.

## Testing

Added 9 Storybook stories: image attachment (thumbnail), non-image (icon
unchanged), missing filename (legacy fallback label), long names, and
combinations. Targeted typecheck of the changed files surfaced no
errors; the monorepo's CI lint/build covers the rest.

Refs #20942

---------

Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>
Co-authored-by: Etienne <45695613+etiennejouan@users.noreply.github.com>
 2026-06-12 14:04:06 +02:00
Etienne fefd9d7704 feat(workflow) - Add validation layer (#21422) 
Add workflow validation framework and consolidate output schema
types/search logic into twenty-shared

This PR introduces a comprehensive workflow validation system that
catches configuration errors at build-time, and consolidates the
fragmented output-schema type definitions and variable-search logic from
the front-end into twenty-shared

**Workflow validation** — A new system that checks workflows for errors
before activation: graph connectivity (unreachable steps, dangling
references), step parameter schemas (via Zod), variable references
(typos, wrong step order), and workspace metadata (non-existent
objects). Returns structured errors/warnings with "did you mean?"
suggestions. Runs automatically after create_complete_workflow and
update_workflow_version_step, and is also available as a standalone
validate_workflow tool.

**Output schema consolidation** — Moves all output schema types and the
variable-search logic from scattered front-end files into twenty-shared,
replacing ~800 lines of duplicated per-schema-type code with a single
unified searchVariableInOutputSchema dispatcher.


To do : 
- validation on CODE and AGENT step

---------

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-06-12 08:23:03 +00:00
Weiko cfb9772179 feat(server): convert view to overridable entity (#21436) 
## Context

Every entity created as a side effect of object creation must support
the overridable pattern (`isActive` + `overrides` + override routing)
before we can re-own side effects to their true application. Starting
with View.

viewField, viewFieldGroup, pageLayoutTab and pageLayoutWidget already
extend `OverridableEntity`. This PR brings `view` to the same pattern.

## What this does

- `ViewEntity` now extends `OverridableEntity<ViewOverrides>` (adds
`isActive` boolean + `overrides` jsonb). All editable view properties
are overridable; the 3 fieldMetadata foreign keys are converted to/from
universal identifiers like viewField's `viewFieldGroupId`.
- **Update**: mutations on a view not owned by the caller (e.g. standard
views like "All Companies") are written into `overrides` instead of
mutating the row. Reads merge overrides in
the DTO.
- **Delete/destroy**: views not owned by the caller are deactivated
(`isActive = false`) instead of deleted.
~~- **INDEX invariant**: `key = INDEX` views can only be created via
object-creation side effect. The API now rejects creating, deleting or
destroying INDEX views (object-deletion cascade is unaffected). This was
not really needed for this migration but was flagged during
implementation.~~
- **Front**: views with `isActive = false` are filtered out of the views
selector.
- Fast instance command adds the two columns
(`2-12-instance-command-fast-...-view-overridable-entity.ts`).

## Notes

- Custom (caller-owned) views behave exactly as before: direct updates,
soft delete.
- View-group side effects (kanban groups) are computed on the
override-merged view so overridden `mainGroupByFieldMetadataId` works.
 2026-06-11 16:00:52 +00:00
DeviSriSaiCharan 947a4d5253 Fix: prevent unexpected navigation when destroying record from side panel (#21391) 
Fixes: #21243 

# Issue
When a user is on a specific record's page (for example, looking at a
Person) and opens a related record (like a Note) in the right-side
panel, clicking "Permanently Delete" on that Note would abruptly
redirect the user to the main "Notes" list. This breaks the user's
workflow, as they typically want to remain on the parent Person page
after deleting a sub-record.

# Root Cause
Inside the `DestroyRecordsCommand` and `DeleteRecordsCommand`
components, the application was programmed to unconditionally trigger a
`navigateApp` redirect to the deleted object's index page upon
successful deletion. The code did not account for whether the deletion
was triggered from the main index page or from inside a contextual side
panel.

# How we fixed it
I introduced a new `isInSidePanel` flag into the
`HeadlessCommandContextApi`.
The command menu now detects if the delete action originated from inside
a side panel and passes this flag down the execution chain. If `true`,
the `DestroyRecordsCommand` simply closes the panel
(`closeSidePanelMenu()`) and keeps the user exactly where they were.

## After that fix, I encountered another issue (UI not updating
automatically)
Because the app now correctly kept the user on the Person page, a new
bug surfaced: the "Note" chip inside the relation table did not
disappear immediately. The user had to manually refresh the page to see
the deletion.

This happened because:
1. The Apollo optimistic cache occasionally failed to trace deeply
nested morph-relationships back to the parent.
2. A standard local React `useState` fallback was insufficient. The
table component aggressively unmounts and remounts relation cells
whenever a user hovers over them to display interactive controls, which
would wipe the local React state clean and cause the "ghost chip" to
reappear.

##How I fixed that issue (and optimized it)
I built an event-driven fallback using global Jotai state to permanently
hide the chips:

1. **Precision ID Broadcasting**: I updated the `useDestroyManyRecords`
and `useIncrementalDestroyManyRecords` hooks to extract and broadcast
only the *confirmed* destroyed IDs directly from the Apollo mutation
response, preventing false-positive UI removals if the backend performed
a partial delete.
2. **Batch Optimizations**: During bulk deletions, events are now
broadcasted per-batch rather than accumulating thousands of IDs in
memory until the end, keeping the UI instantly responsive and memory
bounded.
3. **Per-Cell State Scoping (`atomFamily`)**: Instead of a leaky global
array, we used Jotai's `atomFamily` to dynamically generate a unique
Noticeboard for every specific table cell (`${recordId}-${fieldName}`).
This ensures the hidden-state survives mouse-hover unmounts while
remaining cleanly isolated.
4. **Defensive Filtering**: The `RelationFromManyFieldDisplay` component
was updated to defensively guard against `undefined` array entries and
strictly match deleted IDs only against valid foreign keys (ending in
`'Id'`), preventing false-positive removals if a UUID happened to be
pasted into a description field.
5. **SSE Resilience**: We hardened the Server-Sent Event (SSE) listeners
with optional chaining and null-filtering to ensure malformed backend
payloads do not crash the real-time event pipeline.


# Screen Recording


https://github.com/user-attachments/assets/19fc8a3f-ba28-43c2-b1f3-a91127cdad97

---------

Co-authored-by: bosiraphael <raphael.bosi@gmail.com>
Co-authored-by: Raphaël Bosi <71827178+bosiraphael@users.noreply.github.com>
 2026-06-11 15:40:56 +00:00
Charles Bochet 184c4948d6 security: strip Node dev headers from images + lingui 5.9.5 (drops vulnerable esbuild) (#21448) 
## 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
 2026-06-11 15:11:29 +02:00
Etienne 303c415dd1 fix(ai) - add logs + remove dashboard building (#21440) 
- add logs for thread finishing without agent message
- add logs to monitor toolCall token usage
- remove dashboard building via AI (before fixing it)
- fix Anthropic compute
 2026-06-11 12:45:25 +00:00
nitin 20c83e1f86 fix(kanban): preserve scroll on board re-init + propagate same-column reorders via SSE (#20637) 
closes
https://discord.com/channels/1130383047699738754/1504130730840821860


https://github.com/user-attachments/assets/d5833031-01c6-4e46-b699-c29c42435a53





## Summary

Fixes two related issues with the kanban (board view) collaboration
experience:

1. **Scroll-to-top on every data change** —
`triggerRecordBoardInitialQuery` always scrolled the board to the top,
even when re-initializing for a single-record data change (SSE echo of
your own mutation, a collaborator's update). Scroll reset only makes
sense when the dataset itself changes (filter / sort / group).
2. **Same-column reorders by other users did not propagate** — the
server's diff function stripped `FieldMetadataType.POSITION`, so
position-only updates produced empty `updatedFields` and short-circuited
event emission entirely. SSE clients never received them.

## What's in here

- **Frontend** — `useTriggerRecordBoardInitialQuery` now exposes a
`triggerRecordBoardInitialQueryWithoutScrollReset` variant; data-driven
re-inits in `RecordBoardDataChangedEffect` use it, while genuine filter
/ sort / group changes keep the scroll-resetting
`triggerRecordBoardInitialQuery`. `getRecordBoardEffectsForUpdateInputs`
classifies each update as `trigger-initial-query` / `reposition-records`
/ `none`. For position- or group-only changes we skip the re-query and
reposition records in place in the store
(`useRepositionRecordsOnBoard`), which avoids the flicker and preserves
scroll.
- **Server** — removes `POSITION` from `objectRecordChangedValues`'
strip list, so position-only updates emit a non-empty diff and flow
through SSE. Position is now treated as a field like any other across
all event consumers (SSE, webhooks, workflows, logic functions); a
trigger with an explicit field filter still excludes it.
 2026-06-11 07:26:51 +00:00
Félix Malfait 9d7f0c405f fix(twenty-front): new layout fast-follows — command menu, field options & logs (#21429) 
Fast-follows for the new layout — the remaining open sub-issues of
twentyhq/core-team-issues#2478.

## Changes

- **Command menu items should not have extra right padding**
(twentyhq/core-team-issues#2500)
`SidePanelList` set `width: calc(100% - spacing[4])` on top of its own
8px left/right padding. Under the global `box-sizing: border-box`, that
extra `-16px` shrinks the list and, because it's left-aligned, dumps the
whole gap on the right. Switched to `width: 100%` so item highlights
inset 8px symmetrically. This is shared by every side-panel list — they
all had the same right-only gutter, so they're all corrected the same
way.

- **Field options should not be cropped and should keep row gaps**
(twentyhq/core-team-issues#2503)
The option row used a fixed `height: spacing[6]`, so under border-box
the `6px` vertical padding was absorbed and consecutive rows sat flush.
Changed `height` → `min-height` so the padding separates the rows again.

- **Logs table with filters should use Background secondary**
(twentyhq/core-team-issues#2505)
The Logs filter card and the upgrade card defaulted to a transparent
background, showing the white page through. Passed
`backgroundColor={themeCssVariables.background.secondary}`, matching
`SettingsTableCard`. The results table stays on the primary surface, per
the Figma reference.

- **Command menu back chevron** (twentyhq/core-team-issues#2504)
`SidePanelTopBar` showed a back chevron whenever the nav stack had more
than one entry. A command-menu page is the root of a fresh command-menu
session, so it now only shows the chevron when it was opened from
another command-menu page. Every other side-panel page keeps standard
history-based back navigation, so workflow / page-layout / record stacks
are unaffected.

## Verification
- oxlint (`--type-aware`, full `src/`): 0 errors
- oxfmt: clean
- tsgo typecheck: no errors in the changed files (the one reported error
is pre-existing in `RestPlayground.tsx`, which this PR does not touch)
- Verified live at apple.localhost:
- #2500 — command menu item highlight insets measured 8px left / 8px
right (was 8 / 24)
- #2503 — option rows render at 38px tall with ~14px gaps, text no
longer cropped
- #2505 — filter + upgrade cards compute to background-secondary;
results table stays on primary
- #2504 — direct command menu shows the close-X with no chevron; pages
opened from the command menu still show the chevron

## Open question for review (#2504)
The issue also describes the page-header three-dots toggle: *"the three
dots icon button should remain visible if the side panel is on a page
that is not a child of the command menu (AI chat, or a page opened
directly)."* Today that toggle morphs to an X for any non-command-menu
side-panel page (e.g. Ask AI). Honoring that touches the shared
`SidePanelToggleButton`, and there's a related decision: search / Ask AI
opened from the command menu currently reset the nav stack rather than
push, so they don't get a "back to command menu" chevron. I left those
out here since they're a behavior change to a shared control with a
product call attached — happy to follow up once you confirm the intended
toggle behavior.

Closes twentyhq/core-team-issues#2500
Closes twentyhq/core-team-issues#2503
Closes twentyhq/core-team-issues#2505
Refs twentyhq/core-team-issues#2504
Refs twentyhq/core-team-issues#2478
 2026-06-11 08:58:23 +02:00
Joseph Chiang 941c9e7586 fix: match relation field filters in optimistic & RLS record matchers (#21301) 
Closes #21345.

## What

It should be caused by the GraphQL optimistic query.

`isRecordMatchingFilter` (front, Apollo optimistic cache) and
`isRecordMatchingRLSRowLevelPermissionPredicate` (server, RLS) now
handle a view filter that targets a **relation field object** (e.g. an
"is (not) empty" filter on a relation) by matching against the related
record id, instead of throwing.


<img width="3436" height="2250" alt="CleanShot 2026-06-08 at 06 44
01@2x"
src="https://github.com/user-attachments/assets/1dccbd1e-133c-4f4a-a0a9-7ccd02a9a0ae"
/>

<img width="1496" height="380" alt="CleanShot 2026-06-08 at 06 45 34@2x"
src="https://github.com/user-attachments/assets/e5c2071e-69df-4d99-bb7d-66d503a175b6"
/>


## Why

Both matchers only implemented the relation **join column** branch
(`fooId`) and threw `Not implemented yet, use UUID filter instead on the
corresponding "fooId" field` for the relation field itself (`foo`). In
practice the UI still stores relation filters keyed on the relation
object, so any view with such a filter made every create/update/delete
on that object throw: the optimistic effect re-evaluates all active view
filters against the changed record and hits the unimplemented branch.

Repro: add a self-relation field on People (e.g. "Referred By"), put it
in a view filter as "is not empty", then edit any Person. The optimistic
update throws.

## Behaviour change

| Scenario | Before | After |
|---|---|---|
| View filter on relation object (`referredBy is not empty`), then edit
a record | Throws `Not implemented yet...` | Record matched by related
id; update succeeds |
| Filter on relation join column (`referredById`) | Worked | Unchanged |

## Test plan

```bash
cd packages/twenty-front && npx jest isRecordMatchingFilter
cd packages/twenty-server && npx jest is-record-matching-rls-row-level-permission-predicate
```

- [x] Front: relation `is empty` / `is not empty` / `in` match by
related id; join-column path still passes (20/20)
- [x] Server: relation `is empty` / `is not empty` match by related id
(9/9)
- [x] `lint:diff-with-main` clean on both packages

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
 2026-06-11 07:29:10 +02:00
Gami 61b76b681e fix: i18n missing hardcoded strings in settings (#21424) 
## What

Two user-visible strings in the Settings area were never wrapped with
Lingui, so they were excluded from i18n extraction and shipped
untranslated regardless of the selected language:

- **"Remote"** — the type chip shown for remote objects in **Settings →
Data Model** (`SettingsItemTypeTag`)
- **"Done"** — the confirm button of the fields configuration group
rename input (`FieldsConfigurationGroupRenameInput`)

## Changes

- Wrap the `Chip` `label` with the `t` macro in
`SettingsItemTypeTag.tsx` (the `placeholder` / `placeholderColorSeed`
props are intentionally left as-is — they drive the avatar initial and
color hash, not display text).
- Wrap the `Button` `title` with the existing `t` from `useLingui()` in
`FieldsConfigurationGroupRenameInput.tsx`.
- Add the corresponding source entries to `en.po` so Crowdin can
propagate the translations to all supported locales.

Both follow i18n patterns already used throughout the codebase — these
two were simply missed.

## Screenshots

Both components rendered via Storybook (source `en` locale) after the
change — the strings now resolve through Lingui's `t` macro without
breaking rendering:

![i18n settings
strings](https://raw.githubusercontent.com/AmilGael/twenty/pr-assets/.github/pr-assets/i18n-hardcoded-strings-settings.png)

## How to test

1. Switch the workspace language to a non-English locale.
2. Go to **Settings → Data Model** with a remote object present → the
type chip reads "Remote" translated.
3. Rename a fields configuration group → the confirm button reads "Done"
translated.

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-11 04:38:58 +00:00
Brendan Erofeev f1c7aecadb fix(front): sanitize optimistic input when creating a record (#21076) 
## Summary

Closes #15800.

Clicking **+ Add New** from a relation cell to create a **Task** or
**Note** (e.g. from a custom object's Tasks/Notes section in the list
view) throws:

```
Uncaught (in promise) Error: Should never occur, encountered unknown fields name in objectMetadataItem task
```

### Root cause

`useCreateOneRecord` computes a **sanitized** input (with
`sanitizeRecordInput`, which strips fields that don't belong to the
object) and sends it to the GraphQL mutation. But it still feeds the
**raw** input to the optimistic cache computation:

```ts
const sanitizedInput = { ...sanitizeRecordInput({ objectMetadataItem, recordInput }), id: idForCreation };

const optimisticRecordInput = computeOptimisticRecordFromInput({
  ...
  recordInput: {
    ...computeOptimisticCreateRecordBaseRecordInput(objectMetadataItem),
    ...recordInput, // ← raw input, may contain fields unknown to the object
    id: idForCreation,
  },
  ...
});
// mutation uses the sanitized input:
mutate({ variables: { input: sanitizedInput } });
```

`computeOptimisticRecordFromInput` asserts that every input key maps to
a field on the object and `throw`s otherwise. So when the create input
carries a field the target object doesn't have (the relation-create path
passes a `name`, but Task/Note use `title`), the optimistic step throws
before the mutation ever runs.

`useCreateManyRecords` does **not** have this problem — it already feeds
the sanitized input to `computeOptimisticRecordFromInput`.

### Fix

Feed the sanitized input to the optimistic computation in
`useCreateOneRecord`, exactly as `useCreateManyRecords` does:

```ts
recordInput: {
  ...computeOptimisticCreateRecordBaseRecordInput(objectMetadataItem),
  ...sanitizedInput,
},
```

This is safe and behavior-preserving for valid creates:
`computeOptimisticRecordFromInput` only ever reads *known* fields (it
iterates the object's field metadata); unknown input keys never
contribute to the optimistic record — they only trip the invariant.
Relations are resolved through their join columns, which sanitization
keeps.

## Test plan

- [x] `npx oxlint --type-aware` — passes on the changed files
- [x] `npx oxfmt --check` — passes
- [x] `tsc --noEmit` — no type errors in the changed files
- [x] `npx jest computeOptimisticRecordFromInput` — passes, including a
new case asserting that input which has been through
`sanitizeRecordInput` no longer trips the "Should never occur,
encountered unknown fields" invariant (the existing test already covers
the raw input throwing)
- [ ] Manual: from a custom object's Notes/Tasks relation, use **+ Add
New** to create a Note/Task — no error, the record is created

### Note on test scope

The crash only reproduces through the full relation-create flow with
live metadata; at the hook level in jsdom the create resolves
regardless, so a hook-level test would not guard the regression. The
added test instead locks the underlying mechanism the fix relies on —
that sanitized input is safe for `computeOptimisticRecordFromInput` —
alongside the existing test that proves raw unknown fields throw.

---------

Co-authored-by: Charles Bochet <charles@twenty.com>
 2026-06-10 12:22:59 +00:00
Félix Malfait adba66caea fix(twenty-front): new layout fast-follows — settings drawer, loading & command menu (#21389) 
Second batch of new-layout fast-follows (master:
twentyhq/core-team-issues#2478). All changes verified live against a
running workspace.

## Settings drawer & header
- **twentyhq/core-team-issues#2489** — sidebar icons render as plain
16px icons, no background tiles.
- **twentyhq/core-team-issues#2488** — Advanced toggle spans the full
drawer width; yellow dot removed.
- **twentyhq/core-team-issues#2497** — page title stays centered in the
settings header (breadcrumb stays left).
- **twentyhq/core-team-issues#2490** — Exit Settings control aligned to
the workspace switcher (24px, matching padding/gap).
- **twentyhq/core-team-issues#2499** — 2px vertical gap restored between
collapsible drawer section items.
- **twentyhq/core-team-issues#2491** — settings drawer rhythm now
matches the main app (28px items, 2px gaps, 28px section headers).
- **twentyhq/core-team-issues#2492** — Home/Chat tab switch no longer
flickers: both tab subtrees stay mounted (a shared
`NavigationDrawerTabbedContent` toggles visibility instead of remounting
+ flashing the chat skeleton).

## Loading states
- **twentyhq/core-team-issues#2486** — metadata loading shows an empty
body (no dense skeleton rows).
- **twentyhq/core-team-issues#2487** — settings table keeps its layout
while loading, with the shimmer localized to the first row's first cell.

## Command menu & navigation
- **twentyhq/core-team-issues#2501** — navigation section header height
matches the nav item rhythm (28px).
- **twentyhq/core-team-issues#2502 (part 1)** — the page side-panel
toggle stays as the dots glyph while the command menu is open, instead
of morphing into a second close control.

## New-field flow
- **twentyhq/core-team-issues#2494** — the new-field stepper moved from
a breadcrumb dropdown into a centered secondary wizard bar (back chevron
+ Save on the configure step); breadcrumb stays clean and the object
label is the centered title.

## Descoped (substantive bugs already fixed)
- **twentyhq/core-team-issues#2500** — command-menu highlight right
gutter: the menu-item base measures full-width, so it's likely a
scrollbar gutter on the list, not the shared component. Left for a
focused follow-up.
- **twentyhq/core-team-issues#2502 part 2** — moving the command-menu
close from left to right is cosmetic (the duplicate-control bug is fixed
by part 1) and would touch the shared `SidePanelTopBar` used by
search/AI panels.

## Verification
typecheck (tsgo) + oxlint + oxfmt green for all changed files; each
change DOM-measured / screenshotted in the running app.
 2026-06-10 11:02:36 +02:00
Abdullah. ca63904ac5 fix(security): bump @scalar/api-reference-react to clear unhead XSS (#21382) 
Resolves [Dependabot Alert
630](https://github.com/twentyhq/twenty/security/dependabot/630).

unhead@1.11.20 was pulled in transitively via
@scalar/api-reference-react@0.4.42 (@unhead/vue@^1.11.11). The
useHeadSafe XSS bypass (GHSA, alert
https://github.com/twentyhq/twenty/issues/630) is only patched on the
unhead 2.x line; the 1.x branch was never fixed and 1.11.20 is the
latest 1.x release, so the existing semver range could not reach a
patched version. Rather than a resolutions override, bump the direct
dependency to a Scalar release that depends on @unhead/vue@^2.x, which
resolves unhead to 2.1.15.

- Upgrade @scalar/api-reference-react ^0.4.36 -> ^0.9.42 (0.9.43+
blocked by the 3-day npmMinimalAgeGate; the caret adopts them once
aged).
- Migrate RestPlayground configuration to the new Scalar API:
  - spec.content -> top-level content
- authentication.http.bearer ->
authentication.securitySchemes.bearerAuth (with
preferredSecurityScheme), matching the server's OpenAPI scheme name.
- Drop the ?inline query on the style.css import. It was added in
https://github.com/twentyhq/twenty/pull/12099 to stop the old Scalar's
global CSS reset from leaking; the new CSS scopes every reset to
:where(.scalar-app), so importing it normally restores styling without
re-introducing that leak.

Proof:
<img width="215" height="48" alt="image"
src="https://github.com/user-attachments/assets/3a738fae-63bd-4e88-82c3-5dbe72d993ec"
/>

Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
 2026-06-10 07:33:13 +02:00
Félix Malfait ce2d77be2a feat(server): in-app server-level admin management (#19785) (#21321) 
## 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>
 2026-06-10 06:50:25 +02:00
Weiko 6c65ae8257 perf(twenty-front): stop Sentry Replay from re-serializing record-table mutations on navigation (#21381) 
## Problem

Navigating between record-index pages (e.g. People ↔ Companies) blocks
the main thread for seconds, on every navigation, for ~every user.
Profiling pointed at **Sentry Session Replay(rrweb)**, not app code.

 ## Root cause

Swapping one record table for another produces a large DOM mutation
batch. rrweb serializes that batch **synchronously on the main thread**
(`_isParentRemoved` / mutation processing).
The built-in `mutationLimit` safety valve doesn't help: it's a *count*
threshold (default 10000), but our cost is *per-mutation serialization*
on a wide/deep table DOM — the batch is expensive, not numerous, so it
slips under the limit.

  ## Fix

```ts
replayIntegration({
  _experiments: {
    ignoreMutations: ['[id^="row-virtual-index-"]'],
  },
}),
```

- ignoreMutations tells rrweb to drop mutation batches originating from
the virtualized row containers (StyledVirtualizedRowContainer, ids
row-virtual-index-N) — the source of the
table-swap churn. The table still appears in replays (initial snapshot;
text is already masked by default), its live row updates just aren't
re-serialized.

## Test

Measured locally
  ```

┌────────────────────────────────────────────────────────────┬───────────┬───────────────┐
│ │ Baseline │ With fix │

├────────────────────────────────────────────────────────────┼───────────┼───────────────┤
│ Replay/rrweb total │ 4,112 ms │ 188 ms (−95%) │

├────────────────────────────────────────────────────────────┼───────────┼───────────────┤
│ _isParentRemoved │ 2,195 ms │ 6 ms │

├────────────────────────────────────────────────────────────┼───────────┼───────────────┤

  ```

## Tradeoff

ignoreMutations tells rrweb to skip mutation batches coming from the
virtualized record-table rows, so session replays won't reflect live
changes inside the table — rows scrolling, cells updating, inline edits
will appear "frozen" at the last full snapshot. The table still shows in
the replay (initial render), and **its text is masked by default anyway,
so in practice we lose little**: the surrounding UI, navigation, clicks,
and interactions are all still recorded. The cost we're removing
(multi-second main-thread freeze on every navigation, for ~all users)
**far outweighs not seeing table row churn in replays** imho.
(@FelixMalfait @charlesBochet)

Two caveats worth noting: _experiments.ignoreMutations is an
experimental Sentry API, and it's batch-coarse, if a mutation batch
contains any matching element, the whole batch is dropped, so an
unrelated change occasionally batched with table mutations could be
missed. During navigation these batches are almost entirely table
mutations, so collateral is minimal.
If it ever proves insufficient, the reliable fallback is
`data-sentry-block` on the record-table body (which turns the table into
a placeholder box in replays).

---------

Co-authored-by: Cursor Agent <cursoragent@cursor.com>
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
 2026-06-09 20:05:04 +00:00
Clive F 5f7638cdaf fix(front): surface widget render errors via ErrorBoundary onError (#21009) 
## Summary

The page-layout widget `ErrorBoundary` in `WidgetCardShell` renders a
generic
"Invalid Configuration" fallback whenever a widget renderer throws.
Because
there is no `onError` handler, the underlying error is swallowed —
unrelated
widget types (fields, notes, front-component, etc.) all surface the same
chip
with no telemetry, which makes render failures hard to triage.

This adds an `onError` handler that forwards the caught error to
`console.error`
and to Sentry (when available) with the widget's `id`, `type`, and
`configurationType` as extra context. It reuses the same dynamic-import
Sentry
pattern already used by `AppErrorBoundary` and
`CommandMenuItemErrorBoundary`,
so it degrades gracefully to a console log when Sentry is not
configured. The
fallback UI is unchanged.

## Test plan

- [ ] `npx nx typecheck twenty-front` passes
- [ ] `npx nx lint:diff-with-main twenty-front` passes
- [ ] When a widget renderer throws, the "Invalid Configuration" chip
still
      renders and the error now appears in the browser console / Sentry

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: Charles Bochet <charles@twenty.com>
 2026-06-09 15:56:55 +00:00
joeltco 7894ae39f0 fix(front): reject backslash paths in isValidReturnToPath (open-redirect hardening) (#21287) 
## Summary

`isValidReturnToPath` validates the post-login `returnTo` path and
already rejects protocol-relative `//` paths — but not the backslash
variant. Browsers normalize `\` to `/`, so `/\evil.com` resolves like
`//evil.com` (a protocol-relative, external URL) while still passing the
existing `//` check:

```ts
isValidReturnToPath("/\\evil.com"); // returns true today; should be false
```

This hardens the open-redirect guard by rejecting any path containing a
backslash, so a `returnTo` can only ever be a same-site absolute path.

## Changes
- `isValidReturnToPath`: reject paths containing `\`.
- Added tests for backslash-tricked paths.

Framed as defense-in-depth — the validator should reject this class
regardless of how each consumer performs the redirect.

---------

Co-authored-by: Charles Bochet <charles@twenty.com>
 2026-06-09 16:31:49 +02:00
Weiko 9c66975520 isCustom deprecation for Objects and Fields (#21228) 
## Context

`isCustom` was a legacy denormalized boolean on `ObjectMetadataEntity`
and `FieldMetadataEntity`.
Now that every metadata row carries `applicationId` (via
`SyncableEntity`), "is this custom" is fully derivable, and the stored
boolean was a redundant second source of truth that could drift.

The real meaning of `isCustom` is **"the owning application is not the
twenty-standard application"** — i.e. `!belongsToTwentyStandardApp`.
Note this is *not* "belongs to the workspace custom app" as I initially
thought: third-party-application
objects/fields are custom too. 
The standard application has a globally stable `universalIdentifier`, so
the value derives with no per-workspace lookup.

## Changed
## `isCustom` checks — before → after

`isCustom` is no longer a stored column. The table below lists every
site that branched on it and how it resolves now. The unifying rule:
`isCustom ≡
!isTwentyStandardApplicationUniversalIdentifier(applicationUniversalIdentifier)`.

### Server — behavioural checks

| Location | Purpose | Before | Now |
|---|---|---|---|
| `utils/compute-object-target-table.util.ts` | Physical table name `_`
prefix | `computeTableName(nameSingular, objectMetadata.isCustom)` |
derives from `applicationUniversalIdentifier` (single source for all
table-name callers) |
| `twenty-orm/factories/entity-schema.factory.ts` +
`…/entity-schema-metadata.type.ts` | ORM table name (hot path) |
`object.isCustom` | `object.applicationId !== standardApplicationId`
(computed in `buildEntitySchemaMetadataMaps`) |
|
`twenty-orm/repository/workspace-{delete,soft-delete,update}-query-builder.ts`
| Table name for mutations | `computeTableName(nameSingular,
objectMetadata.isCustom)` | `computeObjectTargetTable(objectMetadata)` |
| `index-metadata/utils/generate-deterministic-index-name-v2.ts` | Index
name hash (must stay bit-identical) | `flatObjectMetadata.isCustom` |
derives from `applicationUniversalIdentifier` |
| `object-metadata/object-record-count.service.ts` | Table name for
record count | `computeTableName(nameSingular, isCustom)` |
`computeObjectTargetTable(flatObjectMetadata)` |
|
`workspace-manager/dev-seeder/data/services/dev-seeder-data.service.ts`
| Match seed config by table name | `computeTableName(item.nameSingular,
item.isCustom)` | `computeObjectTargetTable(item)` |
| `commands/workspace-export/workspace-export.service.ts` +
`…/utils/generate-workspace-schema-ddl.util.ts` | Export table name (raw
entity) | `objectMetadata.isCustom` |
`!isTwentyStandard…(objectMetadata.application?.universalIdentifier)` |
|
`flat-field-metadata/services/flat-field-metadata-type-validator.service.ts`
| Block users creating reserved field types |
`args.flatEntityToValidate.isCustom` |
`!args.flatEntityToValidate.isSystem` |
| `api/common/.../common-create-many-query-runner.service.ts` | Don't
let client overwrite system `createdBy` |
`createdByFieldMetadata.isCustom === false` |
`createdByFieldMetadata.isSystem === true` |
|
`field-metadata/utils/resolve-field-metadata-standard-override.util.ts`
| Skip i18n/overrides for custom fields | `if (fieldMetadata.isCustom)
return raw` | **removed** — falls through on
`isDefined(standardOverrides)` |
|
`object-metadata/utils/resolve-object-metadata-standard-override.util.ts`
| Skip i18n/overrides for custom objects | `if (objectMetadata.isCustom)
return raw` | **removed** — same fall-through |
|
`command-menu-item/utils/build-navigation-interpolation-context.util.ts`
| Override context for nav labels | passed `isCustom` into resolver |
dropped (resolver no longer needs it) |
| `api/common/.../data-arg-processor.service.ts` | `isCustom` for
record-position table name | `flatObjectMetadata.isCustom` | derives
from `applicationUniversalIdentifier` |
| `metadata-modules/minimal-metadata/minimal-metadata.service.ts` |
Minimal DTO + override context | `flatObjectMetadata.isCustom` | derives
from `applicationUniversalIdentifier` |
|
`commands/upgrade-version-command/1-23/…backfill-record-page-layouts.command.ts`
| Filter to custom objects | `objectMetadata.isCustom` |
`!isTwentyStandard…(applicationUniversalIdentifier)` |

### Server — DTO / API population

| Location | Before | Now |
|---|---|---|
|
`flat-object-metadata/utils/from-flat-object-metadata-to-object-metadata-dto.util.ts`
| passthrough `isCustom` | derives from `applicationUniversalIdentifier`
|
|
`flat-field-metadata/utils/from-flat-field-metadata-to-field-metadata-dto.util.ts`
| passthrough `isCustom` | derives from `applicationUniversalIdentifier`
|
|
`object-metadata/utils/from-object-metadata-entity-to-object-metadata-dto.util.ts`
(REST) | `entity.isCustom` | `entity.applicationId !==
standardApplicationId` |
|
`field-metadata/utils/from-field-metadata-entity-to-field-metadata-dto.util.ts`
(REST) | `entity.isCustom` | `entity.applicationId !==
standardApplicationId` |
| `dataloaders/dataloader.service.ts` | passed
`flatFieldMetadata.isCustom` into override resolver | dropped (resolver
no longer needs it) |

> REST controllers (`object-metadata.controller.ts`,
`field-metadata.controller.ts`) resolve `standardApplicationId` once per
request from the cached `flatApplicationMaps`.

### Frontend

| Location | Purpose | Before | Now |
|---|---|---|---|
| `settings/.../SettingsObjectFieldDisabledActionDropdown.tsx` | Whether
an inactive field is deletable | `isDeletable = isCustomField` |
`isDeletable = isCustomField && !isSystemField` |

### Unchanged (out of scope)

`isCustom` on `IndexMetadata` / `View` / `Skill` / `Agent` and their
guards still read the persisted column.

Breaking change is on the isCustom filter on field and object APIs, this
is never used in the FE and unlikely used by external consumers
 2026-06-09 13:57:19 +00:00
Félix Malfait 02aa086866 fix(twenty-front): new layout fast-follows (#21360) 
Fast-follows for the new layout / flat redesign (master:
twentyhq/core-team-issues#2478).

## Changes
- **Main navbar 48px** (twentyhq/core-team-issues#2479) —
`SIDE_PANEL_TOP_BAR_HEIGHT` 40 → 48, so `PageCardHeader` matches the
Figma target. The side panel top bar shares this constant and stays
aligned.
- **Content panel 12px radius** (twentyhq/core-team-issues#2480) —
`PageCardLayout` card gets a full border + 12px radius and an 8px inset
(`spacing[2]`) so it floats on the shell instead of square full-bleed.
- **Square three-dots button** (twentyhq/core-team-issues#2481) — added
a `square` option to `AnimatedButton`; the page-header side-panel toggle
now renders a 24×24 square icon button instead of a 32×24 pill.
- **Table checkbox sizing** (twentyhq/core-team-issues#2482) — restored
`box-sizing: content-box` on the checkbox box. Its border is declared
outside the label size, so the global `border-box` reset (#21349) was
shrinking it (14px → 12px). Same fix pattern as #21349.
- **Tertiary navbar background** (twentyhq/core-team-issues#2483) — left
navbar / app shell use `background/tertiary` instead of the noisy
surface (`DefaultLayout`, `UserOrMetadataLoader`).
- **Skeleton loading** (twentyhq/core-team-issues#2484) — metadata +
content loading now match the new layout: tertiary shell, 12px rounded
content panel, 48px navbar, sparse bars, empty body (removed the dense
full-width rows). Left-panel skeleton bars use `quaternary` so they stay
visible on the tertiary shell.

## Verification
- typecheck (tsgo) + oxlint + oxfmt pass for all changed files.
- Verified live against a running workspace: measured navbar = 48px,
three-dots = 24×24, checkbox box-sizing = content-box (14px), card
radius = 12px, shell background = tertiary (no noisy image).
Content-loading skeleton matches the target.
 2026-06-09 16:10:36 +02:00
Marie c27c8c88b0 Fix various graphs bugs (#21311) 
Some bugs fixed in this PR
1. From UI any field could be chosen to group the query by it, while for
instance, RAW_JSON type (eg workflowRun.state) is not supported by
PostgreSQL to group a query by. Fix: removed it from the "group by"
fields options in FE + in BE -->
2. The BE check existed (isFlatFieldMetadataSupportedInGroupBy) but the
signature was malformed: it expected`{ fieldMetadataType,
fieldMetadataName, fieldMetadataIsSystem }` while every caller passes a
flat field metadata object with type/name/isSystem. So the check is
mis-wired — at runtime the destructured props are undefined, making it
always return true (validation bypassed). Fixed this.
3. Group by does not work with Morph relations if their direction is
ONE_TO_MANY. Added that constraint.
4. Group by with morph relations were broken even for MANY_TO_ONE,
because a morph is stored as one field per target
(polymorphicOwnerRocket, polymorphicOwnerSurveyResult…), each with its
own join column, but the frontend collapsed them into a single
polymorphicOwner field — so the backend tried to resolve a non-existent
polymorphicOwnerId. Fix: Frontend: added a target picker so you choose
the specific morph target (then its sub-field), storing the real
per-target field id. Backend: fixed validate-relation-subfield to use
the per-target field's own relationTargetObjectMetadataId instead of the
multi-target resolver that returned null.
5. (improvement) When an error occured in the query, the graph showed
"No data". Updated it to "error". (screenshot 1)
6. When a field used as a filter on a graph is deleted, it is not
deleted as a graph filter (which is ok because it would involve parsing
all the graph's configuration json to find whether a field is
referenced; there is no foreign key), which prevented from further
modifying the graph's filters. Fixed this + add an indicator that the
filter is can/should be removed (see screenshot 2)
7. "Ambiguous column name" PG error occurs when ordering by "creation
date" of a related field, because both objects have createdAt field.
Fixed it by adding table alias as prefix.
8. (improvement) While working on #5 I did not understand why we could
directly do `"objectMetadataNameSingular"."columnName" `while I expected
that for custom objects it would have to be
`_objectMetadataNameSingular`. that's simply because we use an alias
from the beginning. To add clarity, within groupBy code I replaced
`objectMetadataNameSingular` with `objectAlias` everywhere it is indeed
inherited from us using objectAlias.

<img width="685" height="391" alt="Screenshot 2026-06-08 at 12 01 45"
src="https://github.com/user-attachments/assets/f2b15ca5-da39-4114-8188-69f58f3c4cbf"
/>

<img width="598" height="341" alt="Screenshot 2026-06-08 at 11 53 55"
src="https://github.com/user-attachments/assets/66372811-4a37-40d9-b43a-4af51f89b6e6"
/>
 2026-06-09 16:08:22 +02:00
Marie 137fe45cf6 Deprecate dummy enterprise key 2/2 (#21328) 
Following [1/2](https://github.com/twentyhq/twenty/pull/20890)

Now that all usages of hasValidEnterpriseKey has been removed in prod
and deployed, we can safely remove it altogether.

---------

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
 2026-06-09 16:07:36 +02:00
Charles Bochet ba4ac6b70e fix(twenty-front): restore top-bar-title testid to unbreak merge queue (#21367) 
## Problem

The merge queue is broken. Every queued PR (#21357, #21361, #21364,
#21366, …) fails on the same E2E assertion in
`workflow-creation.spec.ts:36`:

```
Locator: getByTestId('top-bar-title').getByPlaceholder('Name')
Error: element(s) not found
```

All other E2E tests pass, which pointed to a regression already on
`main` rather than any individual PR.

## Root cause

#21308 ("generalize the page primary/secondary bars (flat redesign)")
switched `RecordShowPageHeader` from `PageHeader` to the new
`PageCardHeader`.

- The old `PageHeader` wrapped its title in `<StyledTitleContainer
data-testid="top-bar-title">`.
- The new `PageCardHeader` renders the breadcrumb slot **without** that
`data-testid`.

The editable record title cell (the `Name` input the test fills in)
still renders fine inside `ObjectRecordShowPageBreadcrumb` — it just
lost the `top-bar-title` wrapper that the E2E suite locates it by. The
testid is also used by the `blank-workflow` fixture.

## Fix

Restore `data-testid="top-bar-title"` on the record-show breadcrumb
container, which wraps exactly what `PageHeader` previously did (the
editable `Name` input and, after save, the record name text). Minimal
and behavior-preserving; record-index and standalone pages use different
header slots and were unaffected (their E2E tests passed throughout).
 2026-06-09 15:57:46 +02:00
Raphaël Bosi 7606dd75a8 Fix: pinned command-menu actions run with empty selection (#21366) 
## Cause
PR #21308 ("generalize the page primary/secondary bars") swapped the old
`PageHeader` for the new `PageCardHeader` on the record-index,
record-show, and standalone pages. The old header set
`data-click-outside-id="page-action-container"` on its action container
— an id that the record table/board/calendar click-outside listeners
exclude so header clicks don't clear the current selection. The new
`PageCardHeader` dropped that attribute.

## Implications
With the attribute gone, clicking a pinned command-menu item registered
as a click *outside* the table/board, which reset the selected records
before the action read them. As a result, pinned actions and workflows
triggered from the top bar ran with an empty selection.

## Fix
Re-add `data-click-outside-id={PAGE_ACTION_CONTAINER_CLICK_OUTSIDE_ID}`
to `PageCardHeader`'s action container. Since all three migrated headers
route their buttons through this shared component, the single change
covers every affected page.
 2026-06-09 15:32:41 +02:00
Raphaël Bosi 92502efacc Restore content-box sizing for components broken by the global border-box reset (#21361) 
Since [#21315](https://github.com/twentyhq/twenty/pull/21315), the new
twenty-ui's global border-box reset applies app-wide, shrinking legacy
content-box components: most visibly, off-center checkboxes.
[#21349](https://github.com/twentyhq/twenty/pull/21349) missed a few;
this adds box-sizing: content-box to Checkbox, Radio, ColorSample,
MenuItemHotKeys, Tag, ImageInput, and OnboardingModalCircularIcon.
 2026-06-09 15:32:19 +02:00
Weiko 55cbd3bfbf perf(ai): lazy-load agent chat runtime so it doesn't fetch/diff threads until opened (#21331) 
## Problem

On workspaces with a sizeable AI chat history, the whole app was
freezing during navigation, including Settings (one navigation click
measured ~6.5s).

## Root cause

`AgentChatProvider` is mounted app-wide in `AppRouterProviders`, so its
effects run on every page.
On every render it would:
1. auto-select the most recently active thread
(`AgentChatThreadInitializationEffect`),
2. fetch that thread's **full message history**
(`AgentChatMessagesFetchEffect`),
3. run `AgentChatStreamingPartsDiffSyncEffect` →
`updateStreamingPartsWithDiff`, which loops over every message doing
`isDeeplyEqual(existing, incoming)` + `structuredClone`.

A large thread would produce multi-second freeze on every interaction,
app-wide. (Confirmed via a Chrome CPU profile)

 ## Fix

Don't run the agent-chat **message runtime** until the chat is actually
opened.

## Note
There is still room for improvement, opening AI chats would still be
very slow.
 2026-06-09 11:10:43 +02:00
Félix Malfait 8a3e6e645a fix(ui): restore content-box sizing for components broken by the global border-box reset (#21349) 
## Problem

Since the `twenty-ui` → `twenty-ui-deprecated` / `twenty-new-ui` →
`twenty-ui` rename (#21315), many deprecated components render with
**compacted height** — e.g. dropdown menu items collapse from 32px to
16px, and chips from ~24px to 16px.

## Root cause

The new `twenty-ui` (formerly `twenty-new-ui`) ships a global reset in
`packages/twenty-ui/src/styles/base/reset.scss`:

```css
*, *::before, *::after {
  box-sizing: border-box;
}
```

This is bundled into `twenty-ui/style.css`, which the app imports in
`index.tsx`. #21315 did not change the `import 'twenty-ui/style.css'`
line, but it changed what `twenty-ui` resolves to (old → new), so this
**global `border-box` reset now applies app-wide**.

Several deprecated components were authored against the **content box**,
e.g. `StyledMenuItemBase`:

```css
height: calc(32px - 2 * var(--vertical-padding));
padding: var(--vertical-padding) var(--horizontal-padding);
```

With `content-box` the padding sits *outside* the declared height → 32px
total. Under the new `border-box` reset the padding is folded *inside* →
16px total. (`Chip` uses `height: spacing[4]` + outside padding — same
failure mode.)

Verified in the running app: the collapsed menu item computes
`box-sizing: border-box`, matched by the rule `*, ::before, ::after {
box-sizing: border-box }`; `height` resolves to `calc(32px - 2 * 8px) =
16px`.

## Fix

Add `box-sizing: content-box` to the affected deprecated components. A
class selector outranks the universal `*` reset, so this restores their
intended sizing **without touching the global reset** (which the new
`twenty-ui` components rely on).

Affected: `StyledMenuItemBase` (and its hoverable variant),
`MenuItemSelect`, `MenuItemSuggestion`, `Chip`.
 2026-06-09 08:52:32 +02:00
Félix Malfait bfefcd3755 feat(twenty-front): generalize the page primary/secondary bars (flat redesign) (#21308) 
Replaces #21279 and #21282 with one clean PR from `main`.

Generalizes the settings primary-bar / secondary-bar card chrome to the
record index, record show and standalone pages via a shared
`PageCardLayout` + `PageCardHeader` (the side panel sits as a sibling of
the content card), and applies the new flat design direction: square
corners on the card, side panel and loading skeletons.

Iterating toward the new design (Figma node 102282-221623); the
confirmed direction and the explicit "remove rounded corners" change are
in, remaining designer specifics to follow.
 2026-06-08 22:47:05 +02:00
Félix Malfait cd13457a4a fix(twenty-front): match loading skeleton menu width to the nav drawer (#21278) 
## What

On the very first load (full browser refresh), the navigation skeleton
didn't match the real `NavigationDrawer` width: it rendered an 8px-wider
panel (an 8px wrapper padding on top of the 220px animated container)
and right-aligned 204/196px item rows, so the menu visibly shifted and
resized once the app finished loading.

This makes every navigation skeleton mirror the real drawer geometry: a
single `NAVIGATION_DRAWER_CONSTRAINTS.default`-wide (220px), border-box
panel with the drawer's own padding, left-aligned, and skeleton bars
that fill the content width like the real nav items (`width: 100%`). The
same fill-width fix is applied to the in-drawer section skeletons so
every navigation skeleton matches the real menu width.

## Verification

- `tsgo` typecheck, `oxlint`, and `oxfmt` all clean on the changed
files.

---------

Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>
 2026-06-08 18:38:17 +02:00
Raphaël Bosi c596a5e342 Rename twenty-ui to twenty-ui-deprecated and twenty-new-ui to twenty-ui to prepare package release (#21315) 
## Description

Promotes the next-gen UI library (formerly `twenty-new-ui`) to the name
**`twenty-ui`** (v0.1.0, publishable) and renames the old package to
**`twenty-ui-deprecated`**. Rewrites ~1,730 `twenty-ui` imports →
`twenty-ui-deprecated`, updates all configs/CI/Docker/deps, and migrates
twenty-front's `Toggle` to the new package (first consumer) as a
drop-in.

## Next steps
- Wire the `ui/v*` publish dispatch (`cd-deploy-tag.yaml` +
`.yarnrc.yml`), then tag `ui/v0.1.0` to publish.
- Continue migrating components from `twenty-ui-deprecated` →
`twenty-ui`.
 2026-06-08 18:12:28 +02:00
Charles Bochet 13e8e26d1c security: bump uuid 9 → 11 (server, shared, front) (#21326) 
Clears the `uuid` "missing buffer bounds check in v3/v5/v6" advisory —
patched in **11.1.1**. Bumps `twenty-server`, `twenty-shared`,
`twenty-front` from 9 → `^11.1.1`.

### Why 11 and not 13
uuid **11.1.x still ships a CommonJS build**, so jest loads it with **no
config changes**. uuid went **ESM-only at v12+**, which would otherwise
force `transformIgnorePatterns` workarounds across the jest projects
(and broke server/integration/storybook CI on the earlier 13 attempt).
11.1.1 is the actual patched version, so this is the minimal fix.

### Changes
- `uuid` → `^11.1.1` in the three workspaces (lockfile regenerated under
hardened mode)
- one test (`useCreateManyRecords.test.tsx`): pin the mocked `v4` to its
string-returning overload — uuid's types declare a `Uint8Array` overload
that `jest.mocked` resolves to (present in v11 too, unrelated to ESM).

All usages are named imports, so no source migration. typecheck passes
(server/shared/front); affected specs pass. **No jest config changes.**
 2026-06-08 17:42:19 +02:00
Marie 2151a414f5 Remove IS_WORKFLOW_RUN_STEP_LOGS_ENABLED feature flag (#21323) 2026-06-08 15:08:20 +00:00
Parship Chowdhury e04eef0461 fix: wrong record count on deleted and normal records (#21292) 
## Summary
- Resolves #11977 
- When looking into the deleted records from People tab (or any object
list), the record detail header showing 0/(total records) instead of the
correct position among deleted records only, e.g. 1/3 or 3/7. So, this
PR makes the count match what users see in the deleted-records list.
- Also normal records showing `0/N` in the header when opened from a
list view (e.g. `0/48` -> `2/48`).

## Approach
I tried to keep the change small and avoid extra server requests:
- when a user came from a deleted-records view, we tell our existing
queries to include soft-deleted records.
- for the position number, we use the record list the user already had
open (from the index view they came from) instead of apollo cache, which
didn’t include records, especially deleted ones, but also normal
records.
- normal list behavior is not changed on the server side.

## Test plan
- Open people/company, delete a record
- Use the side menu -> “see deleted records”
- open a deleted record’s details
- confirm the header showing the correct position and total (e.g. 1/2,
not 0/100)
- for normal list: open People (normal list, not deleted) -> click a
record -> open full page -> confirm header shows correct position and
total (e.g. `2/48`, not `0/48`)

## Screenshots
### Before:
<img width="1513" height="309" alt="Screenshot 2026-06-07 135204"
src="https://github.com/user-attachments/assets/4754f1a7-8315-4a7a-815f-dda977b09331"
/>
<img width="1514" height="261" alt="Screenshot 2026-06-07 141735"
src="https://github.com/user-attachments/assets/dd5b1834-5d84-49fe-8d20-633428d73502"
/>

### After:
<img width="1511" height="224" alt="Screenshot 2026-06-07 134946"
src="https://github.com/user-attachments/assets/9450af7d-84b9-40bb-95e9-5a8665cc0923"
/>
<img width="1514" height="288" alt="Screenshot 2026-06-07 135045"
src="https://github.com/user-attachments/assets/029ae632-ad7e-451e-8170-a4e4e71ac6f9"
/>
<img width="1512" height="229" alt="Screenshot 2026-06-07 141642"
src="https://github.com/user-attachments/assets/576f4cad-a9e9-4380-aa67-e5f0e976a193"
/>

---------

Signed-off-by: Parship Chowdhury <parshipchowdhury@gmail.com>
Co-authored-by: Charles Bochet <charles@twenty.com>
 2026-06-08 16:44:03 +02:00
Félix Malfait dfb3da1f8d feat(emailing-domain): add LOG driver for local development (#21286) 
## What

Adds a `LOG` driver to the emailing-domain feature, selected via a new
`EMAILING_DOMAIN_DRIVER` config variable (defaults to `AWS_SES`, so
production behavior is unchanged).

The LOG driver:
- resolves domains to `VERIFIED` instantly (no DNS / SES setup)
- logs each `sendEmail` and returns a synthetic `messageId` instead of
calling SES

It also dev-seeds a pre-verified domain per workspace
(`<workspaceId>.dev.twenty.local`) so the feature works out of the box.

## Why

The emailing-domain feature currently ships only the AWS SES driver, so
the verify → send flow can't be exercised locally (or in CI) without
real AWS credentials. This unblocks local development and review of
anything built on emailing domains.

## Usage

```
EMAILING_DOMAIN_DRIVER=LOG
```

The seeded `*.dev.twenty.local` domain is already verified; sends are
logged (`[log-driver] sendEmail ...`).

---------

Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>
 2026-06-08 14:59:11 +02:00