5959 Commits

Author	SHA1	Message	Date
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
martmull	84a8504473	Add Enter HotKey to aAuth authroize screen (#21512) ... as title <img width="1263" height="834" alt="image" src="https://github.com/user-attachments/assets/73dbfca2-8c7f-469d-8273-6adec5472abd" /> <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21512?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 19:10:38 +00: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:  ## 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
Charles Bochet	868cb02e45	security: close lodash CVEs (#824/#823/#385) via parent upgrades, no resolution (#21414) ... Closes the remaining lodash Dependabot alerts **without any `resolutions` override** — by upgrading the parent packages that pinned the vulnerable lodash. Every `lodash` in the tree now resolves to **4.18.1**. ### Closes - **#824 — `_.template` code injection (HIGH)** - #823 / #385 — prototype pollution in `_.unset` / `_.omit` ### What changed (4 parents pinned vulnerable lodash 4.17.x; all upgraded, no override) - **`@stoplight/spectral-functions`** → 1.10.2 (in-range; now uses `lodash ^4.18.1`) - **`zapier-platform-core`** 15.5.1 → 19.0.0 — aligns with the already-present `zapier-platform-cli ^19` (they were mismatched). v19 tightened the `Bundle` types, so 3 call sites now type their bundle as `Bundle<InputData>` and the test bundle includes the new `meta` fields. - **`@graphql-codegen`** → `cli 6.3.1`, `typescript 5.0.10`, `typescript-operations 5.1.0`, `typed-document-node 6.1.8`. These depend on `@graphql-codegen/plugin-helpers ^6.3.0`, the release that dropped lodash. (Stayed on the 6.x/5.x line on purpose — 7.x changes generated output far more.) ### About the generated-file changes — they are cosmetic, not real changes The codegen bump touches one generated file. **Verified there is zero semantic change:** - Only `src/generated-metadata/graphql.ts` changes. `src/generated/graphql.ts` (data) and `src/generated-admin/graphql.ts` (admin) are **byte-identical**. - Same 1,638 type declarations before and after — none added, none removed. - After stripping whitespace and union pipes, the file is **byte-for-byte identical** — no type, field, or union member changed. The entire diff is one formatting change from `typescript-operations@5.x`: multi-member union types are now printed multi-line with a leading `|` instead of on one line — which TypeScript treats identically: ```ts // before payload?: { …ObjectMetadata… } | { …Path… } | null // after payload?: | { …ObjectMetadata… } | { …Path… } | null ``` Only metadata is affected because only its operations select GraphQL union types. To keep generated types otherwise behavior-identical, `defaultScalarType: 'any'` was added to the three codegen configs (codegen 6 would otherwise default unmapped scalars to `unknown`). ### Verification - `twenty-front` typecheck ✓, `twenty-zapier` typecheck ✓ - `yarn install --immutable` ✓ (passes the hardened 3-day age gate) - CI green — including the `graphql:generate` freshness check, which regenerates against the canonical schema and confirms the committed output is exactly what codegen produces - No `lodash@4.17.x` remains anywhere in `yarn.lock` Supersedes #21411 (which closed these via a one-line resolution).	2026-06-10 18:12:46 +02: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
Charles Bochet	217e1f5ab3	security: clear immutable High alert via @graphql-codegen typescript plugins v4 (#21380) ... ## What Clears the High `immutable` alert (GHSA-wf6x-7x77-mvgw) via a parent bump — **no resolution**. `immutable@3.7.6` was pulled by `@ardatan/relay-compiler@12.0.0` (→ `immutable ~3.7.6`), reached through `@graphql-tools/relay-operation-optimizer` inside the `@graphql-codegen` visitor plugins. The fix lives in `relay-operation-optimizer@7.1.4` → `relay-compiler@13.0.1` → `immutable@^5.1.5` — but the old codegen typescript plugins (v3) pinned a 6.x optimizer stuck on relay-compiler 12. **Fix chain:** - `@graphql-codegen/typescript` `^3.0.4` → `^4.1.6` - `@graphql-codegen/typescript-operations` `^3.0.4` → `^4.6.1` - refresh `@graphql-tools/relay-operation-optimizer` (within its existing `^7.0.0` range) → 7.1.4 → `relay-compiler@13.0.1` → `immutable@5.1.6` ## Heads-up: this is effectively a codegen v4 plugin upgrade The codegen typescript plugins v4 change the generated **scalar shape** (`Scalars['X']` → `Scalars['X']['input'|'output']`), so the committed `generated*/graphql.ts` are regenerated (~7.8k lines). The diff is **purely type-level** — no runtime/enum/document changes — and was regenerated against the current schema (verified: **no schema-content drift**). ## Verification - `immutable@3.7.6` gone (now 5.1.6); `relay-compiler@13.0.1` - `nx typecheck twenty-front` passes against the regenerated types (0 errors) - `yarn install --immutable` clean - Generated files regenerated against a clean origin/main schema (no drift markers)	2026-06-10 10:37:00 +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
Parship Chowdhury	4f87ea5a9a	fix: firefox blank import validation screen and center toggles (#21266) ... ## Summary Resolves #20182 and also centered toggles (e.g. under ICP) vertically in validation cells. ## Screencasts In Firefox: Before: https://github.com/user-attachments/assets/cd837733-6f4c-4bd4-9b08-723f22a5c9ba After: https://github.com/user-attachments/assets/d180a2f3-ee40-46f9-8db2-ecd341878fc6 ## Screenshots Before: <img width="156" height="160" alt="Screenshot 2026-06-05 215835" src="https://github.com/user-attachments/assets/a228fea8-7f3d-43f1-88bd-d6e198f8cac0" /> After: <img width="191" height="148" alt="Screenshot 2026-06-05 215815" src="https://github.com/user-attachments/assets/a419bf29-9925-44f2-a6c7-c11af6401806" /> --------- Signed-off-by: Parship Chowdhury <parshipchowdhury@gmail.com> Co-authored-by: Charles Bochet <charles@twenty.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-08 10:59:48 +00:00
Mani bharadwaj	79c9c75776	fix: use correct userWorkspaceId for navigation menu comparisons (#21299) ... ## What does this PR do? Fixes a bug where `NavigationMenuItem.userWorkspaceId` was being compared/set to `WorkspaceMember.id` instead of the correct `UserWorkspace.id`, causing the favorites functionality to not work correctly. Fixes #21291 ## Problem The `isFavorite` check in `ViewPickerOptionDropdown` and `createManyNavigationMenuItems` calls in multiple files were using `currentWorkspaceMemberId` (which is `WorkspaceMember.id` from the `workspace_*` schema) instead of the correct `UserWorkspace.id` (from the `core` schema). This caused: - `isFavorite` to always return `false` for user favorites - Navigation menu items to be created with incorrect `userWorkspaceId` ## Root Cause In `useNavigationMenuItemsData.ts`: - `currentWorkspaceMemberId` was derived from `currentWorkspaceMember?.id` (WorkspaceMember.id) - But `NavigationMenuItem.userWorkspaceId` expects a `UserWorkspace.id` - These are two different entities from different schemas (core vs workspace) ## Solution 1. Added `currentUserWorkspaceId` to the `useNavigationMenuItemsData` hook return type 2. `currentUserWorkspaceId` is derived from `currentWorkspaceMember?.userWorkspaceId` 3. Updated all comparisons and assignments to use `currentUserWorkspaceId` when dealing with `userWorkspaceId` ## Files Changed - `packages/twenty-front/src/modules/navigation-menu-item/display/hooks/useNavigationMenuItemsData.ts` - Added `currentUserWorkspaceId` to return type - `packages/twenty-front/src/modules/views/view-picker/components/ViewPickerOptionDropdown.tsx` - Fixed `isFavorite` check and `createManyNavigationMenuItems` call - `packages/twenty-front/src/modules/command-menu-item/engine-command/record/single-record/components/AddToFavoritesSingleRecordCommand.tsx` - Fixed `createManyNavigationMenuItems` call - `packages/twenty-front/src/modules/navigation-menu-item/edit/hooks/useNavigationMenuItemEditController.ts` - Fixed `targetUserWorkspaceId` assignment ## Testing - No existing tests directly cover the `useNavigationMenuItemsData` hook - The fix is a simple type/field correction that should not affect other components - CI will verify TypeScript compilation and linting ## Checklist - [x] I have read the [CONTRIBUTING.md](https://github.com/twentyhq/twenty/blob/main/.github/CONTRIBUTING.md) file - [x] Changes are tested locally (TypeScript compilation) - [x] Commit message follows repository conventions - [x] PR is linked to the relevant issue (#21291) --------- Co-authored-by: Mani bharadwaj <Manibharadwaj@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>	2026-06-08 09:17:07 +00:00
Yiyang Pan	6bfbe036f6	fix(settings): gate APIs & Webhooks page on API_KEYS_AND_WEBHOOKS, not WORKSPACE (#21302) ... ## Summary The **APIs & Webhooks** settings page (`SettingsPath.ApiWebhooks`) is gated by the wrong permission flag. Its route sits in the `PermissionFlagType.WORKSPACE` group in `SettingsRoutes.tsx`, but everything else about the page is gated on `API_KEYS_AND_WEBHOOKS`: - The **nav item** is hidden behind `API_KEYS_AND_WEBHOOKS` (`useSettingsNavigationItems.tsx`). - All its **sub-routes** — new/detail API key, new/detail webhook, and the GraphQL & REST playgrounds — already live under the `API_KEYS_AND_WEBHOOKS` wrapper. So a role with **"API Keys & Webhooks"** enabled but **without "Workspace"** sees the nav item (and the **"Set up MCP"** button in *Settings → AI*, which links to `/settings/api-webhooks#mcp`), but on arrival `SettingsProtectedRouteWrapper` finds no `WORKSPACE` flag and redirects them to the **Profile** page. The entry points are visible; the destination is unreachable. ## Root cause The route was grouped under the `WORKSPACE` wrapper while its nav item and sub-pages are gated on `API_KEYS_AND_WEBHOOKS` — the page's route gate and its nav gate disagree. ## Changes - `SettingsRoutes.tsx` — move the `SettingsPath.ApiWebhooks` route out of the `WORKSPACE` group and into the existing `API_KEYS_AND_WEBHOOKS` group, alongside its own sub-routes. This is the same class of fix as #21239 (*gate the AI settings page on `AI_SETTINGS`, not the chat flag*). ## Test plan - [ ] Role with **only "API Keys & Webhooks"** (`API_KEYS_AND_WEBHOOKS`, no `WORKSPACE`): *Settings → APIs & Webhooks* is reachable; the nav item and the *Settings → AI* "Set up MCP" link both land on the page instead of redirecting to Profile. - [ ] Role with **"Workspace" but not "API Keys & Webhooks"**: the APIs & Webhooks nav item stays hidden and the route is not reachable (was previously reachable — now consistent with the nav). - [ ] Admin (both flags): unchanged.	2026-06-08 08:41:31 +00:00
Valeriy Proklov	011afa6011	Allow kanban cross-column drag when sorting is enabled (#21025) ... ## Summary This PR allows kanban cards to be dragged across columns while sorting is enabled. Previously, any board drag while a sort was active opened the “Remove sorting?” modal. That makes sense for same-column reordering, because manual reorder conflicts with the active sort. But for cross-column moves, the user is changing the grouped field, not trying to manually reorder the destination column. With this change: - Same-column drag with sorting enabled still opens the existing remove-sorting modal. - Cross-column drag with sorting enabled updates only the group field. - The destination column keeps using the active sort to determine where the card appears. - Unsorted board drag behavior continues to update `position` as before. ## Why On sorted kanban boards, moving a card to another column is a valid workflow even though manual reordering is not. The previous guard blocked both cases because it only checked whether sorting was active, not whether the card stayed inside the same column. ## Implementation The drop behavior now distinguishes between: - sorted same-column drops, which remain blocked - sorted cross-column drops, which are allowed without a position update - unsorted drops, which keep the existing position-update behavior A small helper captures that decision and has focused unit coverage. ## Validation - Manually verified sorted cross-column drag persists after refresh. - Manually verified sorted same-column drag still opens the remove-sorting modal. - Manually verified unsorted same-column drag still reorders cards. - Manually verified unsorted cross-column drag still moves cards. - Ran focused Jest coverage for the sorted board drop decision. - Ran formatting and oxlint checks on touched frontend files. - Ran `twenty-front` typecheck. - Ran `twenty-front` production build. Co-authored-by: Félix Malfait <felix.malfait@gmail.com> Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-06 14:22:57 +02:00
Félix Malfait	a2fa941ce3	chore(twenty-front): remove dead SettingsAiMCP component and covers (#21281) ... ## What `SettingsAiMCP` is dead code — nothing imports or renders it. The redesign moved MCP setup to the **APIs & Webhooks** page (`SettingsMcpSetup`, on the MCP tab), and the AI settings page now **deep-links** there (`ApiWebhooks#mcp`) instead of rendering this component. Removes the orphaned component and its two cover SVGs: - `src/pages/settings/ai/components/SettingsAiMCP.tsx` - `public/images/ai/ai-mcp-cover-{light,dark}.svg` ## Notes - Verified nothing references the component or the SVGs in source (only stale `.po` source-reference comments remain, which `lingui` extraction reconciles separately — not hand-edited here). - The hero on the APIs & Webhooks page (incl. its MCP tab) is unaffected; that's the `playground/cover` image.	2026-06-06 12:23:42 +02:00
Félix Malfait	4658d44d8b	fix(settings): ship borderless hero cover images (#21277) ... ## What The settings discovery hero images (AI, Applications, Page Layouts, Members, Data Model, APIs & Webhooks) baked the rounded border into the pixels — transparent rounded corners plus a 1px edge stroke. Rendered inside `Card rounded` — which already draws a 1px border + border-radius and clips children with `overflow: hidden` — this produced a doubled, slightly misaligned border. This replaces all 12 files (light + dark per section) with clean full-bleed exports (opaque square corners), so the border and rounding come entirely from CSS. ## Notes - Pure asset swap, no component changes. - The MCP section's `.svg` cover is untouched (no new export provided). Billing's unused cover is left as-is. ## Verification - Each new image confirmed 1388×300, opaque square corners (no baked border), correct light/dark variant. - `Card` (twenty-ui) provides `border` + `border-radius` + `overflow: hidden`, so the square images are clipped to the rounded card.	2026-06-06 11:21:06 +02:00
Félix Malfait	91f2f08995	feat(server): unify workspace-event ingestion behind one EventSink pipeline (#21197) ... ## Why The five event-log streams (`workspaceEvent`, `pageview`, `objectEvent`, `usageEvent`, `applicationLog`) each wrote to ClickHouse through their own fire-and-forget writer (`AuditService`, `UsageEventWriterService`, and the `application-logs` driver), with the per-type knowledge (table names, normalization, access rules) spread across several modules. Three of them reimplemented the same ClickHouse insert, and the read side, the live stream, and the producers lived in different modules under two different names. This consolidates them into one `core-modules/event-logs/` subsystem (emit, write, live, read), with the per-type config in a single registry so adding an event type is roughly one file. The base Logs settings tab and free application logs shipped separately in #21180 (merged). This PR adds the unified backend, the registry, and the viewer's live mode and entitlement gating. ## Pipeline ```mermaid flowchart TB subgraph PROD["Producers"] A["auth, billing, impersonation,<br/>webhook, custom-domain"] U["usage listener"] F["logic-function executor (app logs)"] R["record CRUD (entity events)"] end EM["EventLogEmitterService<br/>createContext().insert* / dispatch()"] EQ(["entityEventsToDbQueue<br/>(existing, shared with timeline)"]) CIE["CreateEventLogFromInternalEvent"] SINK["WorkspaceEventSinkService.ingest()"] C1["ClickHouseEventSink"] C2["ConsoleEventSink"] LIVE["EventLogLiveService.publishWatched()<br/>(presence-gated)"] CH[("ClickHouse, 5 tables, async_insert")] CHAN(["WORKSPACE_EVENTS_CHANNEL"]) RS["EventLogsService (registry-driven read)"] LR["EventLogsLiveResolver"] UI["Settings > Logs"] A --> EM U --> EM F --> EM EM -->|direct| SINK R --> EQ --> CIE -->|ingest| SINK SINK --> C1 --> CH SINK --> C2 SINK --> LIVE -.->|if a viewer is watching| CHAN --> LR --> UI CH --> RS --> UI ``` ## What it does - Producers call `EventLogEmitterService.createContext().insert*()`, which builds a typed `WorkspaceEventEnvelope` and writes it through `WorkspaceEventSinkService` to the configured sinks (ClickHouse, Console) plus a presence-gated live fan-out. Record/CRUD events reach the same sink through the existing `entityEventsToDbQueue`. There is no dedicated queue; ClickHouse `async_insert` batches server-side. Writes are best-effort, as on main today. - `EVENT_LOG_TYPES[table]` is the per-type source of truth: the ClickHouse table, the required entitlement, the free-text filter column, and the row-to-GraphQL mapping. Read row shapes derive from the write rows. - Four modules along their dependency boundaries: `EventLogEmitterModule` (producer API), `EventLogIngestionModule` (sink layer), `EventLogLiveModule` (fan-out), and `EventLogsViewerModule` (the entitlement-gated GraphQL read, which is where billing/enterprise/permissions stay so producers stay light). - Logs viewer: per-table columns, filters (text, date, record), live mode, and an upgrade card that points to Billing on Cloud or the Admin Panel on self-hosted. Application logs are free on every plan; the other four require the `AUDIT_LOGS` entitlement (with a `NO_ENTITLEMENT` fallback to the upgrade card). - Renames `AuditService` to `EventLogEmitterService`, and the generic `Monitoring` event to a typed `Impersonation` event (`level` + `action`). - Removes `UsageEventWriterService`, the `application-logs` driver/module, and `AuditService`'s direct inserts. ## Durability Writes are best-effort, the same as main today (the old writers were fire-and-forget). A dedicated queue was tried mid-PR and removed: `async_insert` already batches server-side, so the queue only added durability, which isn't a requirement right now. The `EventSink` seam keeps a durable transport (e.g. a Redis-Streams buffer) easy to add later without touching producers. ## Out of scope S3 peer sink (seam only), Postgres or any second read path, `ReplicatedMergeTree`, ClickHouse table-schema changes, and the record-data `EVENT_STREAM_CHANNEL` (unchanged, separate concern). ## Testing Unit tests cover the registry definitions and row normalization, the entitlement gating, the envelope builders, and the producers. Integration tests cover the write paths (record create produces an `objectEvent`; the track mutation produces a `workspaceEvent`) and the read/query path across all five tables. Verified with typecheck, lint, a server boot, and GraphQL/SDK codegen.	2026-06-06 10:32:56 +02:00