6125 Commits

Author	SHA1	Message	Date
Charles Bochet	fb4608e437	chore(deps): upgrade Tier-1 deps (googleapis 173, gaxios 7, express 5, jsdom 29, date-fns 4, stripe 20) (#21570) ... ## What Security-driven upgrade of the biggest-drift Tier-1 dependencies (staying on latest = staying patched). Bundled because they share the lockfile and the googleapis/gaxios pair must move together. | Package | From | To | Gap | |---|---|---|---| | googleapis | 105.0.0 | **173.0.0** | 68 majors | | gaxios | 5.1.3 | **7.1.5** | 2 majors | | express | 4.22.2 | **5.2.1** | 1 major | | jsdom | 26.1.0 | **29.1.1** | 3 majors | | date-fns | 2.30.0 | **4.4.0** | 2 majors | | date-fns-tz | 2.0.0 | **3.2.0** | 1 major | | stripe | 19.3.1 | **20.4.1** | 1 major | `yarn npm audit` reports **0 high/critical** advisories before and after. ## Code changes - **gaxios v7** — `GaxiosError.code` is now `string | number` (guard the calendar network-error check by `typeof`); `GaxiosError` config/response use `URL` + `Headers`; and crucially the v7 constructor drops `response.data` unless `bodyUsed` is set — updated the synthetic gmail error mocks accordingly (production gaxios sets it, so real error parsing is unaffected). - **google-auth-library / gaxios dedup** — `googleapis-common@8.0.2` exact-pins `google-auth-library@10.5.0` + `gaxios@7.1.3` while `googleapis` pulls `^10.2.0`; the two copies made `OAuth2Client`/`GaxiosError` type-identities diverge across every gmail/calendar service. Added two singleton `resolutions` (documented inline in root `package.json`). - **express 5** — no source changes. `@nestjs/platform-express@11.1.24` already resolves `express@5.2.1` internally; the old `4.22.2` pin was the override. - **jsdom 29** — no source changes, but it now pulls ESM-only transitive deps (`@csstools/*` `.mjs`, `parse5`, `entities`, `tough-cookie`, `@exodus/bytes`). Extended the server jest `transformIgnorePatterns` allowlist and added `.mjs` to the transform/extensions so jest can load jsdom. - **stripe 20** — `Subscription` gained a required `customer_account` field; added to mocks. No runtime changes. - **date-fns v4** — `Locale` is no longer ambient (import explicitly in 5 files); per-locale entrypoints dropped the typed `default` export (the locale loader now reads the single named export); fixed the default locale import in `formatTimeZoneLabel`. ## Tests - Full suites green locally: **twenty-server 5709 passed**, **twenty-front 4937 passed**, twenty-ui / twenty-ui-deprecated green; typecheck + builds (swc + vite) + lint all pass. - Added regression tests for the two runtime behaviors these upgrades touch and that had no coverage: - `getDateFnsLocale` — named-export locale resolution (date-fns v4). - `sanitizeFile` — jsdom 29 + DOMPurify still strips `<script>`/event handlers from uploaded SVGs (security guard). ## Deliberately deferred (not in this PR) - **stripe → 21/22**: stripe **21** bundles a runtime `Decimal` type for money fields **and** jumps the pinned API version to `2026-03-25.dahlia` (changes webhook/billing payload behavior) — too risky to fold into a deps bump on billing code. stripe **22** additionally drops the node10-resolvable `types` entry, which would force a repo-wide `moduleResolution` change. Capped at the latest clean **20.x**. - **openid-client → 6**: v6 is a full functional rewrite and its passport strategy manages the OAuth `state` internally, but our SSO flow uses `state` to carry `identityProviderId` across the shared `/auth/oidc/callback`. That needs an auth-flow redesign (session-carried provider id) on Enterprise SSO code with no integration harness — it deserves its own focused PR rather than riding along here. ## Tier-1 source Originated from a dependency-drift audit; remaining Tier-1 items (date-fns done here) plus Tier-2/3 follow-ups tracked separately. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21570?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-15 10:23:42 +02:00
Yash Singh	d7d4b36d5e	fix(front): keep the filename when a file has no extension (#21576) ... Closes #21575. ## Summary `getFileNameAndExtension` split filenames with `lastIndexOf('.')`. For an extensionless name (`README`, `Makefile`), `lastIndexOf` returns `-1` and `substring`'s negative-index clamping returned `{ name: '', extension: 'README' }` — losing the whole name into the extension. In the attachments UI this rendered an empty rename field and corrupted the name on edit. ## Changes - Early return `{ name, extension: '' }` when there is no dot - Correct the existing test that asserted the buggy output; add no-dot + trailing-dot cases ## Testing Pure, dependency-free function — verified deterministically (17/17 assertions, red-green proven: reverting the fix fails the corrected `README` assertion). Note: twenty's full nx lint/test wasn't run locally (repo wants Node ^24.5.0; this box is on Node 26), so CI is the authoritative check for lint/format. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21576?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-15 06:33:10 +00:00
dependabot[bot]	9d5561c96c	chore(deps): bump @xyflow/react from 12.10.0 to 12.11.0 (#21561) ... Bumps [@xyflow/react](https://github.com/xyflow/xyflow/tree/HEAD/packages/react) from 12.10.0 to 12.11.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/xyflow/xyflow/releases">@​xyflow/react's releases</a>.</em></p> <blockquote> <h2><code>@​xyflow/react</code><a href="https://github.com/12"><code>@​12</code></a>.11.0</h2> <h2>12.11.0</h2> <h3>Minor Changes</h3> <ul> <li><a href="https://redirect.github.com/xyflow/xyflow/pull/5677">#5677</a> <a href="https://github.com/xyflow/xyflow/commit/e6661de531212f9a209dba17dd63fbbd4ee16f62"><code>e6661de</code></a> - Add <code>autoPanOnSelection</code> to auto-pan when user drags a selection close to the edge of the viewport.</li> </ul> <h3>Patch Changes</h3> <ul> <li> <p><a href="https://redirect.github.com/xyflow/xyflow/pull/5791">#5791</a> <a href="https://github.com/xyflow/xyflow/commit/732c8eb8d5ff86ab1c057588724221e9b3b8553c"><code>732c8eb</code></a> - Adds a type error when <code>handleId</code> is used without <code>handleType</code> in <code>useNodeConnections</code></p> </li> <li> <p><a href="https://redirect.github.com/xyflow/xyflow/pull/5793">#5793</a> <a href="https://github.com/xyflow/xyflow/commit/c5c853d4a2f537caaea725ab9e7bd480e24b86fb"><code>c5c853d</code></a> - Dev Warnings now use library-specific messaging with the correct documentation links.</p> </li> <li> <p><a href="https://redirect.github.com/xyflow/xyflow/pull/5776">#5776</a> <a href="https://github.com/xyflow/xyflow/commit/0441e9f9471380b5ba057fc0a6a8cbdc6ff5ed7b"><code>0441e9f</code></a> - Export <code>NodeHandle</code> type</p> </li> <li> <p><a href="https://redirect.github.com/xyflow/xyflow/pull/5755">#5755</a> <a href="https://github.com/xyflow/xyflow/commit/88737f9713f3a6f99c6448e02b6518c7aeedae28"><code>88737f9</code></a> - Add <code>@types/react</code> and <code>@types/react-dom</code> as optional peer dependencies to prevent issues with pnpm strict mode (<code>hoist: false</code>)</p> </li> <li> <p><a href="https://redirect.github.com/xyflow/xyflow/pull/5105">#5105</a> <a href="https://github.com/xyflow/xyflow/commit/076ad3893725f654641f7b8c39e7a4e7935eb702"><code>076ad38</code></a> - Fix type for event passed to onNodeDrag</p> </li> <li> <p><a href="https://redirect.github.com/xyflow/xyflow/pull/5784">#5784</a> <a href="https://github.com/xyflow/xyflow/commit/7055140e66e4aebb08ce512bdff34add7e115472"><code>7055140</code></a> - Fix node resizing possible beyond absolute extents</p> </li> <li> <p><a href="https://redirect.github.com/xyflow/xyflow/pull/5769">#5769</a> <a href="https://github.com/xyflow/xyflow/commit/ad4d547724a1c2debf8eb7c6e117aabbfd601934"><code>ad4d547</code></a> - Use <code>useEffect</code> for StoreUpdater to restore previous behaviour</p> </li> <li> <p>Updated dependencies [<a href="https://github.com/xyflow/xyflow/commit/732c8eb8d5ff86ab1c057588724221e9b3b8553c"><code>732c8eb</code></a>, <a href="https://github.com/xyflow/xyflow/commit/c5c853d4a2f537caaea725ab9e7bd480e24b86fb"><code>c5c853d</code></a>, <a href="https://github.com/xyflow/xyflow/commit/e6661de531212f9a209dba17dd63fbbd4ee16f62"><code>e6661de</code></a>, <a href="https://github.com/xyflow/xyflow/commit/737194d571894dd84ce7cbab02f2a4d0b779d018"><code>737194d</code></a>, <a href="https://github.com/xyflow/xyflow/commit/40660cdb054fb1a110799a3ad7cecbf51371727f"><code>40660cd</code></a>, <a href="https://github.com/xyflow/xyflow/commit/4806e7cde6d69cd7570098ecca86523666b80175"><code>4806e7c</code></a>, <a href="https://github.com/xyflow/xyflow/commit/7055140e66e4aebb08ce512bdff34add7e115472"><code>7055140</code></a>]:</p> <ul> <li><code>@​xyflow/system</code><a href="https://github.com/0"><code>@​0</code></a>.0.77</li> </ul> </li> </ul> <h2><code>@​xyflow/react</code><a href="https://github.com/12"><code>@​12</code></a>.10.2</h2> <h3>Patch Changes</h3> <ul> <li> <p><a href="https://redirect.github.com/xyflow/xyflow/pull/5735">#5735</a> <a href="https://github.com/xyflow/xyflow/commit/a6c938fb2e5ed030512ef75d665ac80dc3a66bc6"><code>a6c938fb2</code></a> Thanks <a href="https://github.com/nvie"><code>@​nvie</code></a>! - Allow <code>type</code> field to be missing in <code>BuiltInNode</code> (no <code>type</code> field is the same as <code>type: &quot;default&quot;</code>)</p> </li> <li> <p><a href="https://redirect.github.com/xyflow/xyflow/pull/5722">#5722</a> <a href="https://github.com/xyflow/xyflow/commit/8c9b7e726e0bb79871c85017dace0f1ccf1b478c"><code>8c9b7e726</code></a> Thanks <a href="https://github.com/dfblhmm"><code>@​dfblhmm</code></a>! - Add <code>snapGrid</code> to <code>screenToFlowPosition</code> options</p> </li> <li> <p><a href="https://redirect.github.com/xyflow/xyflow/pull/5723">#5723</a> <a href="https://github.com/xyflow/xyflow/commit/82249517a3338d7bd0d6d499abecfaa6bca8c339"><code>82249517a</code></a> Thanks <a href="https://github.com/moklick"><code>@​moklick</code></a>! - Pass options to useReactFlow/useSvelteFlow viewport helper functions correctly</p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/xyflow/xyflow/blob/main/packages/react/CHANGELOG.md">@​xyflow/react's changelog</a>.</em></p> <blockquote> <h2>12.11.0</h2> <h3>Minor Changes</h3> <ul> <li><a href="https://redirect.github.com/xyflow/xyflow/pull/5677">#5677</a> <a href="https://github.com/xyflow/xyflow/commit/e6661de531212f9a209dba17dd63fbbd4ee16f62"><code>e6661de</code></a> - Add <code>autoPanOnSelection</code> to auto-pan when user drags a selection close to the edge of the viewport.</li> </ul> <h3>Patch Changes</h3> <ul> <li> <p><a href="https://redirect.github.com/xyflow/xyflow/pull/5791">#5791</a> <a href="https://github.com/xyflow/xyflow/commit/732c8eb8d5ff86ab1c057588724221e9b3b8553c"><code>732c8eb</code></a> - Adds a type error when <code>handleId</code> is used without <code>handleType</code> in <code>useNodeConnections</code></p> </li> <li> <p><a href="https://redirect.github.com/xyflow/xyflow/pull/5793">#5793</a> <a href="https://github.com/xyflow/xyflow/commit/c5c853d4a2f537caaea725ab9e7bd480e24b86fb"><code>c5c853d</code></a> - Dev Warnings now use library-specific messaging with the correct documentation links.</p> </li> <li> <p><a href="https://redirect.github.com/xyflow/xyflow/pull/5776">#5776</a> <a href="https://github.com/xyflow/xyflow/commit/0441e9f9471380b5ba057fc0a6a8cbdc6ff5ed7b"><code>0441e9f</code></a> - Export <code>NodeHandle</code> type</p> </li> <li> <p><a href="https://redirect.github.com/xyflow/xyflow/pull/5755">#5755</a> <a href="https://github.com/xyflow/xyflow/commit/88737f9713f3a6f99c6448e02b6518c7aeedae28"><code>88737f9</code></a> - Add <code>@types/react</code> and <code>@types/react-dom</code> as optional peer dependencies to prevent issues with pnpm strict mode (<code>hoist: false</code>)</p> </li> <li> <p><a href="https://redirect.github.com/xyflow/xyflow/pull/5105">#5105</a> <a href="https://github.com/xyflow/xyflow/commit/076ad3893725f654641f7b8c39e7a4e7935eb702"><code>076ad38</code></a> - Fix type for event passed to onNodeDrag</p> </li> <li> <p><a href="https://redirect.github.com/xyflow/xyflow/pull/5784">#5784</a> <a href="https://github.com/xyflow/xyflow/commit/7055140e66e4aebb08ce512bdff34add7e115472"><code>7055140</code></a> - Fix node resizing possible beyond absolute extents</p> </li> <li> <p><a href="https://redirect.github.com/xyflow/xyflow/pull/5769">#5769</a> <a href="https://github.com/xyflow/xyflow/commit/ad4d547724a1c2debf8eb7c6e117aabbfd601934"><code>ad4d547</code></a> - Use <code>useEffect</code> for StoreUpdater to restore previous behaviour</p> </li> <li> <p>Updated dependencies [<a href="https://github.com/xyflow/xyflow/commit/732c8eb8d5ff86ab1c057588724221e9b3b8553c"><code>732c8eb</code></a>, <a href="https://github.com/xyflow/xyflow/commit/c5c853d4a2f537caaea725ab9e7bd480e24b86fb"><code>c5c853d</code></a>, <a href="https://github.com/xyflow/xyflow/commit/e6661de531212f9a209dba17dd63fbbd4ee16f62"><code>e6661de</code></a>, <a href="https://github.com/xyflow/xyflow/commit/737194d571894dd84ce7cbab02f2a4d0b779d018"><code>737194d</code></a>, <a href="https://github.com/xyflow/xyflow/commit/40660cdb054fb1a110799a3ad7cecbf51371727f"><code>40660cd</code></a>, <a href="https://github.com/xyflow/xyflow/commit/4806e7cde6d69cd7570098ecca86523666b80175"><code>4806e7c</code></a>, <a href="https://github.com/xyflow/xyflow/commit/7055140e66e4aebb08ce512bdff34add7e115472"><code>7055140</code></a>]:</p> <ul> <li><code>@​xyflow/system</code><a href="https://github.com/0"><code>@​0</code></a>.0.77</li> </ul> </li> </ul> <h2>12.10.2</h2> <h3>Patch Changes</h3> <ul> <li> <p><a href="https://redirect.github.com/xyflow/xyflow/pull/5735">#5735</a> <a href="https://github.com/xyflow/xyflow/commit/a6c938fb2e5ed030512ef75d665ac80dc3a66bc6"><code>a6c938fb2</code></a> Thanks <a href="https://github.com/nvie"><code>@​nvie</code></a>! - Allow <code>type</code> field to be missing in <code>BuiltInNode</code> (no <code>type</code> field is the same as <code>type: &quot;default&quot;</code>)</p> </li> <li> <p><a href="https://redirect.github.com/xyflow/xyflow/pull/5722">#5722</a> <a href="https://github.com/xyflow/xyflow/commit/8c9b7e726e0bb79871c85017dace0f1ccf1b478c"><code>8c9b7e726</code></a> Thanks <a href="https://github.com/dfblhmm"><code>@​dfblhmm</code></a>! - Add <code>snapGrid</code> to <code>screenToFlowPosition</code> options</p> </li> <li> <p><a href="https://redirect.github.com/xyflow/xyflow/pull/5723">#5723</a> <a href="https://github.com/xyflow/xyflow/commit/82249517a3338d7bd0d6d499abecfaa6bca8c339"><code>82249517a</code></a> Thanks <a href="https://github.com/moklick"><code>@​moklick</code></a>! - Pass options to useReactFlow/useSvelteFlow viewport helper functions correctly</p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/xyflow/xyflow/commit/6970ded32ff745e8fb6ecc97eb6b78956d7cc016"><code>6970ded</code></a> chore(packages): bump</li> <li><a href="https://github.com/xyflow/xyflow/commit/c9db70d050830fa1b06703ef775b12120a0662e2"><code>c9db70d</code></a> Merge branch 'main' of <a href="https://github.com/xyflow/xyflow">https://github.com/xyflow/xyflow</a> into 5780-svelte-flow...</li> <li><a href="https://github.com/xyflow/xyflow/commit/af23aef9de095f68fc893b8d18296398c54329bf"><code>af23aef</code></a> chore: cleanup error messages</li> <li><a href="https://github.com/xyflow/xyflow/commit/9d58ab9d2ff1bbf1dc79bb556cc9eed725d116d6"><code>9d58ab9</code></a> fix: make error messages framework-specific</li> <li><a href="https://github.com/xyflow/xyflow/commit/e52bb557888fbae0237432300142180aaca1774f"><code>e52bb55</code></a> Merge pull request <a href="https://github.com/xyflow/xyflow/tree/HEAD/packages/react/issues/5105">#5105</a> from thedanchez/xydrag-type-generics</li> <li><a href="https://github.com/xyflow/xyflow/commit/03e3dc0ae6ac64d77ab9281a3dbf629ee8b75d4e"><code>03e3dc0</code></a> Merge pull request <a href="https://github.com/xyflow/xyflow/tree/HEAD/packages/react/issues/5755">#5755</a> from nielskaspers/fix/issue-5738-react-types-peer-dep</li> <li><a href="https://github.com/xyflow/xyflow/commit/caebfd681b997020fe20444c181113d161ff7aa0"><code>caebfd6</code></a> Merge pull request <a href="https://github.com/xyflow/xyflow/tree/HEAD/packages/react/issues/5784">#5784</a> from xyflow/fix-node-resizer-again</li> <li><a href="https://github.com/xyflow/xyflow/commit/9dc7ec938bed30b59417bade64473cb8f795e039"><code>9dc7ec9</code></a> chore(react): fix util function</li> <li><a href="https://github.com/xyflow/xyflow/commit/c4e783308c2adb022a431a4eb0fb8e46706e27c7"><code>c4e7833</code></a> Merge pull request <a href="https://github.com/xyflow/xyflow/tree/HEAD/packages/react/issues/5785">#5785</a> from xyflow/fix-useless-promises</li> <li><a href="https://github.com/xyflow/xyflow/commit/01fb1f1524d6b514145c1c906e1e5b2b8bb359bb"><code>01fb1f1</code></a> chore(system): add UseNodeConnectionsParams type</li> <li>Additional commits viewable in <a href="https://github.com/xyflow/xyflow/commits/@xyflow/react@12.11.0/packages/react">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~GitHub%20Actions">GitHub Actions</a>, a new releaser for <code>@​xyflow/react</code> since your current version.</p> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21561?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. --> --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-14 23:34:43 +02:00
Charles Bochet	965ff4337f	fix(front): mass update targets explicitly selected records (#21548) ... ## Problem Mass update silently does nothing for explicitly-selected records in a filtered view (reported in [quality-feedbacks](https://discord.com/channels/1130383047699738754/1515444299934728213) — "Mass update does not work (for boolean?)", high severity). When you select specific records (selection mode) and run **Update records**, the action built its target filter with `computeContextStoreFilters`, which intersects the selected record ids with the **current view filters**: ```ts // selection mode (before) queryFilter = makeAndFilterVariables([ anyFieldFilter, { id: { in: selectedRecordIds } }, computeRecordGqlOperationFilter({ ...view filters... }), // ← intersect with view ]); ``` `useIncrementalUpdateManyRecords` first **fetches** the ids matching that filter, then updates them: ```ts if (firstPageRecordIds.length > 0) { await mutateRecordsBatch(...); // never runs when the fetch returns 0 } ``` So any selected record that doesn't match the view filter is silently dropped. When *none* of the selected records match, the fetch returns 0 → the `updateMany` mutation never fires → only the trailing refetch/aggregate queries run, and nothing changes. The confirmation modal still says "Update N records" (it reads `selectedRecordIds.length`), and the side-panel header shows "0 selected" (it reads the find result) — the exact symptoms in the report. This is especially easy to hit when updating the very field a view is filtered on (e.g. a view filtered "QA Done = false" and you set "QA Done = true" on the selected rows). ## Fix In **selection mode**, target exactly the selected ids — the user picked those records, so the action must act on them regardless of the active view filter / any-field search: ```ts // selection mode (after) return { id: { in: contextStoreTargetedRecordsRule.selectedRecordIds } }; ``` Exclusion mode (select-all) is unchanged — it still needs the view filter to define "all matching except N". This also makes the side-panel "N selected" count and other selection-mode actions (delete, export, …) consistent with the explicit selection. ## Reproduction (deterministic) 1. Companies view filtered **QA Done = false**. 2. Select 3 rows individually. 3. Change those rows so they no longer match the filter (set `qaDone = true`) without refetching the view — they stay selected. 4. Open **Update**, set **Employees = 100**, confirm "Update 3 records". **Before:** `Employees` stays `NULL`; side panel shows "0 selected". **After:** `Employees = 100` on all 3; side panel shows "3 selected". ## Tests - Updated `computeContextStoreFilters` selection-mode test to the new shape. - Added a regression test asserting selection mode targets only the selected ids and ignores active view filters / any-field search. `nx lint:diff-with-main`, `nx typecheck twenty-front`, and the unit tests pass. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21548?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-14 19:11:46 +00:00
Félix Malfait	adfef5c830	fix(twenty-front): prevent stale transition page from blocking scroll (#21551) ... ## Problem Switching from the app to Settings sometimes makes every settings page unscrollable until a full page reload. ## Cause `MainAppLayoutOutlet` cross-fades between the app and settings with `AnimatePresence`, rendering both pages into the same grid cell (`grid-area: 1 / 1`). When an exit animation doesn't clean up, the outgoing page stays mounted on top of the active one. With the default `pointer-events: auto`, that (now invisible) stale node intercepts wheel/scroll events before they reach the page underneath — so the page won't scroll even though its own scroll container is fine. The node lives in the always-mounted layout, which is why it survives in-app navigation and only a reload clears it. A broken vs. working DOM snapshot differs only in the number of children in the transition grid cell (2 vs 1) and which element sits under the cursor; the scroll container, its CSS, and the whole flex/height chain are identical. ## Fix Set `pointer-events: none` on exiting pages so a stale exit node can't capture input from the active page. Tested by reproducing the stale-node-on-top state and confirming `pointer-events: none` lets wheel/scroll reach the live page across the content area, while the entering page stays interactive. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21551?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-14 20:46:22 +02:00
Sri Hari Haran Sharma	53de4c557b	Fix record index sync when view fields arrive via SSE (#19069) ... Fixes #19023 ## What changed This updates the record index/view field state flow so the current view can react to late-arriving `viewFields` coming from SSE without requiring a page refresh. Changes: - extracted a narrower `syncRecordIndexViewFields` path in `useLoadRecordIndexStates` - kept the initial full record-index load for first entry into a view - added a follow-up sync in `RecordIndexLoadBaseOnContextStoreEffect` when the same view receives updated `viewFields` - updated `ViewBarRecordFieldEffect` so it re-syncs current record fields when `currentView.viewFields` changes instead of only initializing once ## Why There is a race when a user navigates to a custom object while AI is still creating metadata. In that case, the record index can initialize from a partial view, and later SSE `viewFields` updates were not being applied to the active view state. That could leave the table visually empty or incomplete until a refresh. ## Impact This should allow: - record index columns to update live when view fields arrive via SSE - view bar field state to update live as well - the current view to stay usable without a refresh while AI-created metadata is still streaming in ## Validation Validated locally with: - `npx prettier --check` on modified files - `npx oxlint --type-aware` on modified files Manual verification: - confirmed live record creation appeared without refresh - manual AI/SSE testing was partially limited by Groq TPM/token caps on the selected model, but the state-sync path was verified in code and local behavior checks <img width="3024" height="1964" alt="image" src="https://github.com/user-attachments/assets/f71c7490-bf57-4357-9d5f-087b2424b53b" /> --------- Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-14 19:25:06 +02:00
Arun	f45c54679c	[Fix] : fix: Allow label identifier system fields in view creation and fix resulting duplicate header columns (#19009) ... fixes #18994 After : <img width="767" height="230" alt="Screenshot 2026-03-26 at 7 11 04 PM" src="https://github.com/user-attachments/assets/73de0154-7da1-48fa-92fc-d51a3ef5b06e" /> Before : <img width="905" height="314" alt="Screenshot 2026-03-26 at 6 56 38 PM" src="https://github.com/user-attachments/assets/89b1249b-8889-4034-a6c8-d41330154c1a" /> --------- Co-authored-by: Arun kumar <arunkumar@Aruns-MacBook-Air.local> Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-14 14:45:28 +00:00
Charles Bochet	7c0136b97b	feat(deps): migrate frontend to React 19 (#21531) ... ## What Migrates the frontend stack from **React 18.3 → 19.2**. The website, sdk, companion and emails packages were already on React 19; this brings the remaining holdouts (`twenty-front`, `twenty-ui`, `twenty-ui-deprecated`, `twenty-front-component-renderer`) and `twenty-server`'s email rendering onto 19, and pins a single React version repo-wide. ## Why React 18.x is now the legacy line. Staying current keeps us on the patched/maintained branch and unblocks downstream library majors (react-router 7, mantine 9, etc.) that require React 19 peers. ## Dependency bumps (required by React 19 peers / removed APIs) | Package | From | To | Reason | |---|---|---|---| | react / react-dom | 18.3.1 | 19.2.3 | core | | @hello-pangea/dnd | 16 | 18 | peer `^18 \|\| ^19` | | react-datepicker | 6 | 9 | v<7 used removed `findDOMNode`; drops `@types/react-datepicker` | | react-data-grid | beta.13 | beta.59 | peer `^19.2`; new render API | | graphiql (+ @graphiql/react, plugin-explorer) | 3 / 0.23 / 1 | 5 / 0.37 / 5.1 | peer `^18 \|\| ^19` | | react-helmet-async | 1.3 | **@dr.pogodin/react-helmet** 3.2 | upstream caps peer at `^18`; drop-in React 19 fork | A `resolutions` pin enforces a single React (19.2.3) + `@types/react` (19.2.14) across the monorepo to avoid duplicate copies / type-identity splits. Versions are the aged lockfile patches (clears the `npmMinimalAgeGate`). ## Code changes - **Global `JSX` shim** (`react-jsx-global.d.ts` per package): React 19 moved the `JSX` namespace under `React.JSX`; several deps' published types (notably `@linaria/react`'s `styled.d.ts`, which types every `styled.x` via `keyof JSX.IntrinsicElements`) still reference the global namespace. Without the shim, every styled component degrades to `any` props. - **Ref nullability**: `useRef<T>(null)` now returns `RefObject<T | null>`; widened consumer prop/hook ref types accordingly (incl. the shared `useListenClickOutside`). - **react-datepicker v9**: `onChange`/`onSelect` accept `Date | null`, `calendarStartDay` typing, `ReactDatePickerProps`→`DatePickerProps`, relaxed the dynamic `selectsMultiple` discriminated union. - **react-data-grid beta.59**: `formatter`→`renderCell`, `editor`→`renderEditCell`, `headerRenderer`→`renderHeaderCell`, `components`→`renderers`, `onRowClick`→`onCellClick`, object-shaped `useRowSelection`, Set-based selection. - **dnd style cast**: `@radix-ui/react-popper` augments `CSSProperties` with a `--radix-*` index signature that dnd's closed `DraggingStyle` doesn't satisfy → cast at the spread. ## Status / testing - ✅ `typecheck` green: twenty-front, twenty-ui, twenty-ui-deprecated, twenty-front-component-renderer, twenty-server - ⏳ build / lint / unit tests / storybook+argos / runtime smoke-test in progress Draft until local + CI verification completes. Notable behavior to QA manually: spreadsheet import (data-grid), date pickers, drag-and-drop boards/lists, GraphQL playground, page titles/favicon. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21531?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-14 15:42:22 +02:00
Thomas des Francs	d06e687b77	Fix settings UI polish pass 2 (#21540) ... ## Summary This PR groups the requested second UI polish pass across the app shell, settings pages, data model, community, AI tools, and developer setup surfaces. ### Shell and navigation polish - Lets the app content card fill the available viewport and removes the bottom-left radius on the main container. - Uses an outside-looking container border treatment so the rounded top-left edge matches the Figma frame without a double border. - Restores the separator between the AI chat side panel and the record container. - Updates navigation drawer background/skeleton tones to use gray/3 consistently. - Simplifies the full-screen backend error fallback so the white screen fills the viewport. ### Settings page polish - Moves the layout customization action from the settings navbar into a settings card under the hero. - Tightens layout page copy now that the customization surfaces are not directly manageable yet. - Aligns role detail title sizing and hover treatment with other settings headers. - Supports settings card brand icon colors, then restores Discord and X brand logos on the Community page. - Adds the Community discovery cover, moves community/social content to the top, and reorganizes Partners and Features. - Keeps setting card subtitle and separator behavior available for the updated settings cards. ### Data model and object settings polish - Adds a shared data-model table body wrapper so object, field, and relation tables all keep the expected bottom border. - Displays the object icon in the object settings navbar. - Shares the new-field wizard parent object icon wrapper and keeps the object icon at 64% opacity in wizard headers. - Updates the new-field type selector icon treatment to match the wizard header opacity behavior. ### Integrations, tools, and API polish - Reworks the MCP setup config card with light syntax coloring and a top-right copy icon button instead of the bottom copy section. - Fixes email import icons to match the Figma asset shape. - Ensures AI tool table icons and chevrons never fall back to black. ## Validation - `npx nx lint:diff-with-main twenty-front` - `npx tsc -p packages/twenty-front/tsconfig.json --noEmit` - `git diff --check` - Manual local visual pass on `apple.localhost:3001` for companies, settings/community, data model, object settings, new-field wizard, layout settings, account import, MCP setup, AI tools, and role detail pages. ## Visual QA ### Shell and settings frame <img width="1308" height="1397" alt="Shell and settings frame before/after board" src="https://raw.githubusercontent.com/twentyhq/twenty/pr-assets/ui-fixes-2/visual-qa/ui-fixes-2/shell-settings-frame.png" /> ### Community and data model <img width="1308" height="1806" alt="Community and data model before/after board" src="https://raw.githubusercontent.com/twentyhq/twenty/pr-assets/ui-fixes-2/visual-qa/ui-fixes-2/community-data-model.png" /> ### Integrations and tools <img width="1308" height="1397" alt="Integrations and tools before/after board" src="https://raw.githubusercontent.com/twentyhq/twenty/pr-assets/ui-fixes-2/visual-qa/ui-fixes-2/integrations-tools.png" /> <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21540?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-14 06:15:49 +02:00
Marc Bickel	5d0a4b8db4	fix(twenty-front): keep paging record board columns past the second page (#21348) ... Fixes #21355 ## Problem On a Record Board (Kanban) view, columns that contain more than 20 records stop loading at exactly 20. The initial query loads the first page, one automatic fetch brings the column to 20, and then the loading placeholder at the bottom of the column **spins forever** — scrolling all the way down triggers no further requests. Every column is permanently capped at `2 * RECORD_BOARD_QUERY_PAGE_SIZE` (20) records. ### Steps to reproduce 1. Open any object in board view, grouped by a field where at least one group has > 20 matching records. 2. Wait for the board to load — the first 20 cards in the large column appear. 3. Scroll that column to the bottom. **Expected:** more cards load as you approach the bottom, until the column is exhausted. **Actual:** the placeholder stays forever; no additional group-by request is fired. ## Root cause An **edge-triggered consumer reading a level signal that is stuck high.** The fetch-more trigger (`RecordBoardFetchMoreInViewTriggerComponent`) is an `IntersectionObserver` sentinel that writes its `inView` state into the board-level `recordBoardShouldFetchMoreComponentState`. Its `rootMargin` is: ```ts const rootMargin = `${estimatedCardHeight * RECORD_BOARD_QUERY_PAGE_SIZE * 2}px`; ``` With `estimatedCardHeight ≈ 130px` and `RECORD_BOARD_QUERY_PAGE_SIZE = 10`, that's ~2600px — roughly two pages, i.e. as tall as the entire already-loaded board. So the sentinel reports `inView = true` across the whole loaded board, and the boolean **latches `true` after the first auto-fetch and never toggles back**. The consumer in `RecordBoardQueryEffect` only reacts to the **false→true edge** of that boolean, and `triggerRecordBoardFetchMore` is a stable `useCallback`. Once the boolean is stuck `true` and the dependency array stops changing, the effect never re-runs — so it fetches exactly once. The signal is *level* ("the bottom is in view, keep loading") but it's consumed as an *edge* ("the bottom just appeared, load once"), and the oversized `rootMargin` guarantees the level is permanently high so the single edge never repeats. The large `rootMargin` is intentional prefetch buffering and is not the bug; the consumer simply needs to keep paging while the signal is high. ## Fix Make the consumer **re-arm** the trigger after every page that actually returned records: 1. `useTriggerRecordBoardFetchMore` now returns a `boolean` — `true` only once at least one column received records this round, `false` on every early-exit / empty result. 2. `RecordBoardQueryEffect` resets `recordBoardShouldFetchMoreComponentState` to `false` after a **productive** fetch. The sentinel is still inside the inflated `rootMargin`, so the observer immediately re-asserts `true`, which re-runs the effect and fetches the next page. The loop terminates naturally and never spins: - **Buffer filled** — enough cards load that the sentinel finally leaves the `rootMargin` → observer reports `false` → loop stops. As the user scrolls, it re-arms (normal infinite scroll). - **Columns exhausted** — `triggerRecordBoardFetchMore` returns `false` (per-column `shouldFetchMore` flags already get set `false` when a page returns `< PAGE_SIZE`), so the boolean is not reset and no further fetch fires — no busy-loop on a fully-loaded board. The existing `recordBoardIsFetchingMore` re-entrancy guard prevents any overlapping/double fetch during the round-trip. ## Test - `npx nx typecheck twenty-front` → passes - `npx nx lint twenty-front` (oxlint --type-aware + oxfmt) → 0 warnings, 0 errors, formatting clean - Manually verified on a board with columns of 38 and 74 records: pre-fix both froze at 20; post-fix they page to completion on scroll, and a fully-loaded board issues no extra requests. ## Notes / alternatives considered - **Shrinking `rootMargin`** would mask the bug for tall boards but defeat the intended prefetch buffering and reintroduce it whenever the buffer is smaller than the loaded content. The level/edge mismatch is the real defect. - **Moving the loop into the trigger component** was rejected — it only knows `inView`, not whether a fetch was productive or whether columns are exhausted, so self-looping there would increase coupling. The query effect is the right owner of fetch orchestration. --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: Félix Malfait <felix@twenty.com> Co-authored-by: Félix Malfait <felix.malfait@gmail.com>	2026-06-14 06:10:24 +02:00
Alexandre Ribeiro	fefb6cdb94	feat(page-layout): add number format option to aggregate chart widget (#21521) ... ## Context Closes #21522 Large values in the dashboard **Number** widget are always abbreviated (e.g. `1300090` → `1.3m`) with no way to display the full number. Following a discussion with the core team who were interested in this feature (https://discordapp.com/channels/1130383047699738754/1509604545381142649) , this adds a **Format** option in the **Style** section of the Number (aggregate chart) widget, letting users choose between **Short** (abbreviated, current behavior) and **Full** (complete number with thousand separators). Only the displayed value of the Number widget is affected — axes, labels and tooltips of other chart types are intentionally left untouched. ## What's inside **Server** - New `ChartNumberFormat` GraphQL enum (`SHORT` / `FULL`), following the `AxisNameDisplay` pattern - The existing — and previously unused — `format` field on `AggregateChartConfigurationDTO` is now typed with this enum and validated with `@IsEnum` - The dashboard AI tool schema (`widget.schema.ts`) accepts the new `format` option - Regenerated GraphQL types and the `twenty-client-sdk` metadata client to reflect the enum **Front** - New **Format** setting in the Style section of the Number widget settings, with a Short/Full selection dropdown (same pattern as the Axis name setting) - `transformAggregateRawValueIntoAggregateDisplayValue` takes an optional `numberFormat`: - `FULL` → full number via `formatNumber` (currency values keep up to 2 decimals) - `SHORT` → abbreviated via `formatToShortNumber` - not set → behavior unchanged (currency short, number full), so existing widgets and the record table/board footers render exactly as before ## Screenshots | Full UI Look | <img width="1917" height="955" alt="Twenty_Showcas_FullShort" src="https://github.com/user-attachments/assets/05d05779-395d-4e1a-8ff0-964f6fbef182" /> | Menu UI Look | <img width="291" height="308" alt="Screenshot_2" src="https://github.com/user-attachments/assets/82b5a1de-32fe-46ec-a9b8-add11ab4c6cd" /> ## Tests - Extended `transformAggregateRawValueIntoAggregateDisplayValue` unit tests with SHORT/FULL cases for currency and number fields - Updated the page-layout-widget creation/update integration tests and snapshots to use `ChartNumberFormat.SHORT` <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21521?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-13 23:32:41 +02:00
Félix Malfait	f869ce87b1	[Experiment] perf(front): cache-first currentUser bootstrap (#21532) ... ## Experiment — not for merge as-is A perf experiment for discussion. Opening as a draft to gather feedback and let CI run. ## Problem On a warm (returning) load, the app gate ([`MinimalMetadataGater`](https://github.com/twentyhq/twenty/blob/main/packages/twenty-front/src/modules/metadata-store/components/MinimalMetadataGater.tsx)) blocks first paint until **both** object/view metadata **and** `currentUser` are ready. The metadata store is already cache-first: it persists each entity (including `status: 'up-to-date'`) to `localStorage` with `getOnInit`, opens from cache, and revalidates in the background via collection hashes. 👏 `currentUser` (and `currentWorkspace` / `currentWorkspaceMember` / `currentUserWorkspace`) is **not** — it lives in an in-memory atom, so every load fires a blocking `GetCurrentUser` round-trip before the gate opens. That round-trip is the one remaining network hop on the warm-load critical path; everything else the first screen needs is already in `localStorage`. ## Approach Generalize the pattern the metadata store already proves out, to the user bootstrap — **without adding any new `useEffect`**: - Persist the four bootstrap atoms (`currentUser`, `currentWorkspace`, `currentWorkspaceMember`, `currentUserWorkspace`) via the existing `createAtomState({ useLocalStorage, localStorageOptions: { getOnInit: true } })`. - The gate opens from cache on its own: the existing `IsMinimalMetadataReadyEffect` already derives readiness from the `currentUser` atom alongside metadata status, so persisting the atoms is enough — no new effect. - Keep firing `GetCurrentUser` (now `network-only`, no longer skipped when a user is present) so it **revalidates in the background** and the existing write-through effect updates the atoms with the fresh result. - Clear the cached identity on sign-out by adding the four keys to `clearSessionLocalStorageKeys` (already invoked by `clearSession`, which then hard-reloads). Net effect: warm loads no longer wait on `GetCurrentUser`; the shell paints from cache and corrects within one round-trip. Cold loads (no cache) are unchanged. ## Risks to validate - **Permission staleness** — `currentUserWorkspace` carries `objectsPermissions` / `permissionFlags`. Cache-first means a brief stale-permission window before revalidation. Not a security boundary (the server authorizes every request), but it can momentarily show a menu item the user no longer has; worst case it 401s and corrects on the next paint. - **Feature-flag / workspace staleness** — `currentWorkspace.featureFlags` may be one round-trip stale on warm load. - **`X-Schema-Version` header** — sourced from `currentWorkspace.metadataVersion`; caching it actually makes the header *consistent* with the already-cached metadata rather than absent, but worth confirming against the server's mismatch handling. - **Test isolation** — these atoms now persist; tests relying on the default `null` could see cross-test leakage if `localStorage` isn't reset. The directly-affected suites pass locally (`useAuth`, `useDefaultHomePagePath`, `useSetNextOnboardingStatus`); CI's full run is the real check. ## Validation - [ ] Full CI (types/lint/unit) green - [ ] Manual: throttle network, hard-reload a logged-in workspace, confirm the shell paints before `GetCurrentUser` resolves and that fresh data writes through - [ ] Sign out → sign in as a different user on the same browser; confirm no stale identity flashes	2026-06-13 18:38:45 +02:00
neo773	5d892bdfd0	[WIP] Feat/marketing emails (#21173) ... Marketing/campaign emails on top of the emailing-domain (SES) feature: send a broadcast to a hand-picked list, with per-customer-domain unsubscribe links and opt-out-only **unsubscribe topics**. ## Model Standard objects (workspace schema, flat-metadata): - `messageCampaign` — a campaign send (subject, body template, from address, status, list, optional unsubscribe topic). - `messageList` + `messageListMember` — the hand-picked audience (person ↔ list join). A campaign's recipients are its list's members; everyone is sendable unless suppressed. Core entities (`core` schema, workspace-scoped — readable by the public unsubscribe flow without a workspace context): - `unsubscribeTopic` — an opt-out-only category (name, description, visibility). There is no opt-in subscription state. - `messageSuppression` — the single consent store: a row with `unsubscribeTopicId` NULL is a global block; a row with an `unsubscribeTopicId` and reason `UNSUBSCRIBE` is a per-topic opt-out. Two partial unique indexes dedupe global vs per-topic rows (Postgres treats NULLs as distinct). - `emailingDomain` — the workspace's SES sending domain, auto-provisioned when an email channel is added (and cleaned up when its last channel is removed), with verification status + DNS records. Campaign messages reuse the existing `message` / `messageThread` / `messageParticipant` model — one outbound `message` per recipient with a `deliveryStatus` state machine. ## Sending - `sendMessageCampaign` resolves the audience **under the caller's permissions**, creates the campaign, and enqueues a single fan-out job (the request never materializes per-recipient rows or jobs). - The fan-out job materializes one QUEUED message per recipient (deterministic ids → idempotent re-runs, reconciles crash-orphaned rows) and fans out per-recipient send jobs carrying **only ids**. - Each send job renders per-recipient `{{variable}}` merge fields and sends via `EmailingDomainSenderService`, which applies suppression (global + per-topic) and the unsubscribe footer/headers. Suppressed recipients are recorded `SKIPPED`. - The campaign finalizes `SENT`, or `SENT_WITH_ERRORS` if any recipient terminally failed. - `previewMessageCampaignAudience` returns a pre-send breakdown (total / without-email / duplicate / globally-unsubscribed / topic-unsubscribed / sendable), shown as a hint under the composer pickers. ## Unsubscribe - Encrypted (AES-256-GCM) token carrying workspaceId, address, optional `unsubscribeTopicId`, `issuedAt`, and a `preview` flag. - One-click POST (RFC 8058) + `mailto:` — topic-scoped when the token carries a topic, global otherwise. - Preferences page: a checkbox per visible topic (checked = still receiving); submitting creates per-topic opt-outs for unchecked topics and lifts re-checked ones (UNSUBSCRIBE only — never `BOUNCE`/`COMPLAINT`, never a global block). - A **Preview** action in settings opens the live page via a preview-claim token; opt-out POSTs are no-ops for preview tokens, so previewing never mutates state. - SES webhooks: inbound unsubscribe + outbound bounce/complaint → suppression (race-safe against at-least-once delivery, with reason escalation that never downgrades). - Per-customer unsubscribe hostname (Cloudflare DNS); sends are gated on it being active, except in LOG/demo mode. ## Architecture Campaign orchestration, suppression, the sender, the unsubscribe controller, and the SES webhook handlers live in `src/modules/emailing` + `src/modules/messaging-webhooks` (the workspace-feature layer). `core-modules/emailing-domain` keeps the SES driver, domain provisioning, the `unsubscribeTopic` / `messageSuppression` core entities, and the unsubscribe token/hostname plumbing. Domain creation is validated (`CreateEmailingDomainInput` — domain-format regex, lowercased) before any value reaches SES or the unsubscribe hostname. ## Frontend - Campaign composer side panel (from / list / unsubscribe topic / subject / body) with a live audience-preview hint. - Email settings: email channels each showing their auto-provisioned sending domain in a single section (status + DNS records + a "Check verification" action), plus an **Unsubscribe Topics** section to create/manage topics and preview the recipient page. A demo-mode banner is shown when the LOG driver is active. --------- Co-authored-by: Félix Malfait <felix@twenty.com> Co-authored-by: Félix Malfait <felix.malfait@gmail.com>	2026-06-13 18:37:39 +02:00
Félix Malfait	2c5da39dc5	perf(front): load Front chat during browser idle time (#21533) ... ## Context The Front support chat bundle (`chat-assets.frontapp.com/v1/chat.bundle.js`, ~2.3s in a profiling trace) was being injected only `500ms` after auth + client-config + workspace-member resolved (`useInstantiateSupportChat.ts`). Because the effect's gating conditions are themselves network-bound, that `500ms` still lands the fetch + execute **inside the critical boot window** (metadata load + first render), where the bundle competes for bandwidth and main-thread time. Two pre-existing issues: - The `500ms` delay was too short to clear the critical window. - The injected `<script>` already had `defer = true`, but `defer` is a no-op on dynamically-inserted scripts (they're `async` by default), so it contributed nothing. - The `setTimeout` was never cleared, so an effect re-run within the delay could schedule duplicate loads. ## Change - Add a small `scheduleIdleCallback(callback, { timeout })` helper (`src/utils/`) that runs work during a browser idle period via `requestIdleCallback`, capped by `timeout`, and returns a canceller. - Use it in `useInstantiateSupportChat` with a `2000ms` cap, and **return the canceller from the effect** so a pending load is cancelled on re-run/unmount. ### Why not gate on first interaction? The launcher must appear proactively to surface an unread-reply badge, so it has to load without user action. `requestIdleCallback` keeps it proactive while yielding to the critical path. ### Safari / iOS `requestIdleCallback` is disabled by default in all shipping Safari/iOS versions (not Baseline). The helper falls back to a plain `setTimeout` of the same duration there. Because `requestIdleCallback`'s `timeout` is a *maximum* (it fires earlier at the first idle gap) while `setTimeout` fires *at* that value, a single `2000ms` value gives: - **Chrome/Firefox/Edge/Android**: loads at first idle, guaranteed within 2s. - **Safari/iOS**: loads at 2s (a fixed, longer delay — 4× the old 500ms). Both paths are strictly better than the previous behavior. ## Testing - `scheduleIdleCallback` unit tests (both the `requestIdleCallback` and the fallback path, plus cancellation) — 4/4 pass. - `npx nx typecheck twenty-front` — passes. - `oxlint --type-aware` + `oxfmt` on changed files — clean. https://claude.ai/code/session_013YXr5yNGFH1NYUe4ysmiEy --- _Generated by [Claude Code](https://claude.ai/code/session_013YXr5yNGFH1NYUe4ysmiEy)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21533?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Claude <noreply@anthropic.com>	2026-06-13 17:53:09 +02:00
Félix Malfait	76f69efb43	Keep synced messages and events when removing a workspace member (#21443) ... ## Context Removing a workspace member deletes their connected accounts, which cascades into deleting every message and calendar event those accounts synced. For a CRM, losing the email history of departed teammates is a big deal. ## What this does Connected accounts are now kept and reassigned instead of deleted when a member is removed: - Ownership moves to the acting user (whoever removed the member). When members remove themselves (leave workspace, account deletion), it falls back to the oldest admin. - OAuth tokens are revoked, credentials wiped, message/calendar channels get `isSyncEnabled = false`, and the account is stamped with a new `archivedAt` column (fast instance command included). - Synced messages, threads and calendar events stay in the workspace. Channel visibility settings keep applying as before, since channels and associations survive. - The reassigned account appears in the new owner's Settings → Accounts, where it can still be deleted (with its data) like any other account. The transfer happens synchronously during removal, while the member's userWorkspace row still exists. This also removes `DeleteWorkspaceMemberConnectedAccountsCleanupJob` and its listener: the async job had to reconstruct the account-owner link from rows the removal flow had just deleted, which was race-prone (see 2181fb541e). Archived accounts are excluded from the workflow send-email default account resolution, and both removal confirmation modals now mention what happens to synced data. --------- Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>	2026-06-13 15:52:13 +02:00
Weiko	f63f053444	CommandMenuItem overridable entity (#21486) ... ## Context Second PR of the overridable-entities track (after #21436 for views): command menu items become overridable so that edits on non-owned items are stored as overrides instead of mutating the row, and deletion/deactivation becomes reversible. ## What this does - `CommandMenuItemEntity` now extends `OverridableEntity<CommandMenuItemOverrides>` (adds `isActive` + `overrides`). All editable properties are overridable for now (to discuss). - **Update**: mutations on a command item not owned by the caller (standard items) are written into `overrides`; reads merge them in the DTO. The command palette edit mode (pin, reorder, shortLabel) now preserves standard values, "Reset label to default" gains true post-save semantics. - **Delete**: protected items are deactivated (`isActive = false`) instead of deleted; custom items still hard-delete. - **Object deactivate/enable toggle**: now flips `isActive` on the command item (merged into the main migration call) instead of delete/recreate; a create-if-missing fallback covers legacy deactivated objects. - **Front**: inactive command items are filtered out of the palette selector. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21486?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-13 14:21:27 +02:00
Félix Malfait	036d9a2bcf	feat: gate record creation on isUICreatable only, decoupled from isSystem (#21527) ... ## Context The generic "create a record" UI affordance previously required `!isSystem`, conflating two distinct concerns: **"hidden from Data Model"** and **"not user-creatable"**. This blocked legitimately creatable system objects (e.g. marketing message lists kept `isSystem: true` only to stay out of the Data Model). This PR makes creatability depend on `isUICreatable` alone, so visibility (`isSystem`) and creatability (`isUICreatable`) become independent. ## Changes - **Front gate** (`canCreateRecordsForObjectMetadataItem.ts`): drop the `!isSystem` clause — creatability is now `isUICreatable && !readOnly`. Updated comment + unit test. - **Command menu** (`standard-command-menu-item.constant.ts`): drop the matching `not objectMetadataItem.isSystem` clause from the `createNewRecord` availability expression so the "Create new X" command mirrors the front gate. Existing workspaces get this via the already-present `SyncCreateRecordCommandAvailabilityExpressionCommand`, which re-syncs from the live definition. - **Standard object audit** (`create-standard-flat-object-metadata.util.ts`): the 15 sync/system-created standard objects that relied on `!isSystem` to stay non-creatable now set `isUICreatable: false` (attachment, blocklist, calendar*/message*/note/task targets, message, messageThread, messageParticipant, timelineActivity, callRecording, workflowAutomatedTrigger, …). `workflowRun`/`workflowVersion`/`workspaceMember` were already `false`. Non-system objects (company, person, note, opportunity, dashboard, task, workflow) are untouched. - **Backfill**: new fast instance command (`2-13-…-1781277480000-backfill-non-ui-creatable-standard-system-objects.ts`) runs `UPDATE core.objectMetadata SET isUICreatable = false` for those standard system objects (symmetric `down`), registered in `instance-commands.constant.ts`. `isSystem` and Data-Model visibility logic are unchanged. ## Verification - Front gate unit test (7 pass), standard-application suite incl. callRecording (10 pass) - `oxlint` clean on all changed files - `twenty-server` and `twenty-front` typecheck green 🤖 https://claude.ai/code/session_01TF4kjD56hHjP31wkHPxPv3 --- _Generated by [Claude Code](https://claude.ai/code/session_01TF4kjD56hHjP31wkHPxPv3)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21527?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Claude <noreply@anthropic.com>	2026-06-13 14:05:42 +02:00
Thomas des Francs	b14195428a	Fix navigation and settings UI polish (#21523) ... ## Summary This PR groups the requested UI polish pass across navigation, settings, AI settings, data model, community/lab, and dashboard chips. ### Navigation and drawer polish - Smooths app/settings route switching with a 300ms content transition. - Smooths app menu/settings menu drawer swaps with a fade transition while preserving the existing drawer dimensions. - Keeps navigation and AI chat history panes mounted to avoid flicker when switching tabs. - Aligns the first app/settings section with the AI chat history section title. - Removes the main app navigation "Other" section. - Aligns the settings exit header with the workspace switcher header. - Sets the settings exit icon gap to 8px, uses the small icon stroke token, and keeps the icon color on text-secondary. - Makes the workspace switcher button 28px high inside its 32px container, moves the dropdown up so the workspace name does not jump, and keeps a 2px gap between header icon buttons. - Moves Settings below Support in the workspace switcher menu. - Pins the Advanced toggle to the bottom of the settings drawer and aligns its right padding with nav items. ### Settings surface polish - Fixes vertically cropped dropdown menu headers. - Makes wizard parent titles tertiary when a nested wizard title is visible. - Places danger-zone buttons side by side. - Uses a 32px Visualize button. - Restores 8px top/bottom padding on settings tables. - Separates AI overview counts into three columns like layout overview. - Adds separators inside setting cards, including the Smart Model / Fast Model card. - Groups lab/early-access toggles into one card with separators and full-width row backgrounds. - Replaces deprecated Enterprise adornment tags with the Organization adornment on gated AI/security/settings surfaces. - Uses the Discord brand icon in Community while keeping the standard icon component rendering pattern. - Tightens Skills/Tools search-to-table spacing so switching tabs does not shake the table top. - Fixes the small gap in nested navigation breadcrumbs between Emails and Calendars. ### Dashboard/data table polish - Fixes vertically cropped "Not shared" chips on dashboards. - Keeps table row/header spacing stable after the settings table padding restoration. ## Validation - `npx nx lint:diff-with-main twenty-front` - `npx tsc -p packages/twenty-front/tsconfig.json --noEmit` - Manual Chrome pass on `apple.localhost:3001` for profile, app navigation, workspace switcher, AI overview/models/skills/tools/usage, community/lab, data model, new-field wizard, and dashboards. ## Visual QA ### Settings surface fixes <img width="1324" height="2668" alt="Settings surface fixes before/after board" src="https://github.com/user-attachments/assets/312131fa-3922-4724-9460-46fd373754d1" /> ### Navigation drawer fixes <img width="1324" height="1816" alt="Navigation drawer fixes before/after board" src="https://github.com/user-attachments/assets/ca0b29e5-e393-46c0-81f7-e6bed2557b59" /> ### Tables, wizards, gates and chips <img width="1324" height="2242" alt="Tables, wizards, gates and chips before/after board" src="https://github.com/user-attachments/assets/5f358240-c31c-4c15-8ca8-04ed761fbf85" />	2026-06-13 13:13:55 +02:00
Charles Bochet	869680a5a1	fix(deps): esbuild ^0.28.1 floors + vite 7→8 (rolldown) upgrade (#21517) ... ## What this does Resolves the remaining esbuild security alerts on packages we own, and upgrades the repo to **Vite 8** (which drops esbuild entirely in favour of rolldown/oxc). ### 1. esbuild → `^0.28.1` (security) - Raised the declared `esbuild` floor in `twenty-sdk` and the logic-function common-layer (both were `^0.25.0`, which can only resolve to a vulnerable version). These are our packages, so this is just declaring the patched version — clears Dependabot **#1467** and **#1468**. ### 2. Vite 7 → 8 - Bumped `vite` to `^8` in the 5 packages that declare it, and `@vitejs/plugin-react-swc` to `^4.3.1` (the only plugin that needed a bump for Vite 8; everything else already supports it). - `twenty-front` keeps esbuild minification, so esbuild is now an explicit (patched) devDependency there — Vite 8 no longer ships it. ### Two Vite-8 fallout fixes (bundler internals changed) - **Storybook tests:** added React to `optimizeDeps.include` so Vite's dep optimizer doesn't re-bundle React mid-run and break in-flight imports in browser-mode tests. - **`hex-rgb`:** it's ESM-only and broke rolldown's CJS interop (a default import resolved to the wrong thing under jest). Replaced its one use with a tiny inline hex→rgb parse and dropped the dependency. ## Verified Vite resolves to a single `8.0.16` with no esbuild in its tree. Builds pass on Vite 8/rolldown: `twenty-front` production build, the SDKs, and Storybook; the previously-failing front and storybook test jobs now pass; `yarn install --immutable` is clean. ## Note This doesn't close root alert **#1469** — esbuild is still pulled by other third-party tools (storybook, tsx, lingui, zapier, etc.) that haven't shipped a patched release. The vulnerable code path (esbuild's dev server) isn't used here, so that one is best dismissed as not-affected.	2026-06-13 10:44:22 +00:00
Félix Malfait	1efa3567ef	Rename isUIReadOnly to isUIEditable, add isUICreatable, expose both to app developers (#21504) ... <!-- CURSOR_AGENT_PR_BODY_BEGIN --> # UI capability flags: `isUIEditable` + `isUICreatable` ## Per-verb capability model This PR replaces the negative `isUIReadOnly` metadata flag with positive, per-verb capability flags (à la Salesforce `createable`/`updateable`): - **`isUIEditable: boolean`, default `true`** — rename of `isUIReadOnly` with inverted polarity, on **both** `objectMetadata` and `fieldMetadata`. It is one concept ("can the user edit this through the generic UI?") at two altitudes, so it carries one name at both levels. - **`isUICreatable: boolean`, default `true`** — new, **object-level only** (fields have no create verb). When `false`, no generic UI affordance to create a record of this object appears anywhere (table "+" buttons, board column add, calendar add, relation-section "Add new", record picker "Add new", command-menu create action and its keyboard shortcut). Both flags are **UI-affordance flags only**: the server does not block create/edit mutations based on them, so the system, API, and workflows continue to mutate these records freely. They are orthogonal statements about the object's nature with no implication rule in the data model. Because today's inline creation UX creates a blank record the user must then edit, the frontend create predicate currently requires both `isUICreatable` and effective editability. There is no CREATE permission in `ObjectPermissions`; the frontend keeps gating creation on `canUpdateObjectRecords` as a proxy, ANDed with the new flags. ## Unified create predicate All generic creation entry points now flow through one predicate, `canCreateRecordsForObjectMetadataItem` (`isUICreatable` && not `isSystem` && not effectively read-only, where effective read-only covers `isUIEditable`, `isRemote`, and the `canUpdateObjectRecords` proxy via `isObjectMetadataReadOnly`). This deletes the previously hardcoded suppression lists: - `isRecordTableCreateDisabled.ts` and its hardcoded `WorkflowRun`/`WorkflowVersion` list — deleted; those objects (plus `workspaceMember`) now declare `isUICreatable: false` in the standard application instead. - The hardcoded `workspaceMember` guard inside `useAddNewRecordAndOpenSidePanel.ts` — deleted. - The `CREATE_NEW_RECORD` command menu item's availability expression now checks `objectMetadataItem.isUICreatable`, `isUIEditable`, `isSystem`, and `isRemote`; a workspace upgrade command re-syncs the expression in existing workspaces. Component-local conditions (soft-delete filter active, layout customization mode) stay in their components. ## GraphQL compatibility and removal plan The schema delta versus main is **purely additive plus deprecations — zero breaking changes**: - `isUIReadOnly` remains on both the ObjectMetadata and FieldMetadata GraphQL output types for **one release** as a deprecated field computed as `!isUIEditable` (`deprecationReason: 'Use isUIEditable'`). The Twenty frontend no longer queries it. - `isUIReadOnly` also remains on the **input side** for one release (`CreateFieldInput`, `UpdateFieldInput`, `FieldFilter`, `ObjectFilter`), keeping the schema shape identical to main for those members. On create it acts as a legacy alias mapped to `!isUIReadOnly` (`isUIEditable` wins when both are provided); on update it is ignored, exactly as on main (it was never an editable property). Filtering on the deprecated member keeps working until the column is dropped at upgrade time; after that it is a deprecated no-op surface kept only for schema compatibility. **Removal plan for next release: drop `isUIReadOnly` from the output DTOs (and resolvers' `@ResolveField`s), from the input/filter types, from the create-input mapping, and the `@WasRemovedInUpgrade`-retained entity columns and decorators.** ## ⚠️ Webhook / database-event payload shape change The `database-event-payload` type in `twenty-shared` got a clean rename (no alias): metadata snapshots in webhook and database-event payloads now carry `isUIEditable` (and `isUICreatable` at object level) **instead of** `isUIReadOnly`, with inverted polarity. Consumers of these payloads that read `isUIReadOnly` must switch to `isUIEditable`. ## New manifest properties (app-developer DX) Application developers can now set these flags in their app manifests (purely additive — existing manifests and older `twenty-sdk` versions are unaffected, defaults apply when omitted): - `objects[].isUICreatable?: boolean` (default `true`) - `objects[].isUIEditable?: boolean` (default `true`) - `fields[].isUIEditable?: boolean` (default `true`) The manifest converters previously hardcoded `isUIReadOnly: false`; they now read the manifest values with `?? true` defaults. The types are re-exported through `twenty-sdk` from `twenty-shared`. ## Migration & backfill - One fast instance command: adds `isUIEditable` (NOT NULL default `true`) on `core."objectMetadata"` and `core."fieldMetadata"`, backfills `isUIEditable = false` exactly where `isUIReadOnly = true`, drops `isUIReadOnly`, and adds `isUICreatable` (default `true`) on `objectMetadata`. The `down` is the exact inverse. Uses `ADD/DROP COLUMN IF (NOT) EXISTS`, matching the 2-12 drop-`isCustom` precedent. Verified up and down in separate transactions against a dev database with exact backfill counts. - **Cross-version upgrade safety (multi-version self-hosted jumps):** the upgrade sequence interleaves per version (instance → workspace commands), so pre-2.13 workspace commands run **before** the 2.13 rename when an old instance jumps several versions. Following the `isCustom` precedent: `isUIEditable`/`isUICreatable` are marked `@WasIntroducedInUpgrade` and `isUIReadOnly` stays on both entities as `@WasRemovedInUpgrade`, so the upgrade-aware entity metadata adapter hides the not-yet-existing columns (and keeps the legacy column live) at pre-2.13 cursors. **No committed upgrade command outside the 2-13 directory is modified**: the old 1-21/2-8/2-9 commands keep their original `isUIReadOnly: true` inputs, which still compile (entity property retained, deprecated create-input alias mapped) and still produce the correct legacy column writes pre-rename. - A 2-13 workspace command (`sync-standard-ui-capability-flags`) re-syncs `isUICreatable` **and** `isUIEditable` on standard objects and `isUIEditable` on standard fields from the standard-application definitions. This backfills `isUICreatable: false` on `workflowRun`/`workflowVersion`/`workspaceMember` and heals fields created mid-cross-upgrade by pre-2.13 commands (whose hidden `isUIEditable` value cannot reach the insert). Both 2-13 sync commands pass `isSystemBuild: true` — the flat metadata validator otherwise rejects direct updates to system objects (verified against a deliberately drifted dev database; the run is idempotent). - A second 2-13 workspace command re-syncs the create-record command availability expression. ## Testing - Unit tests for `canCreateRecordsForObjectMetadataItem` (flag/permission/system combinations) and for the manifest converters (flags set / omitted → defaults). - Full `upgrade --dry-run` boots the sequence (107 steps) and validates the upgrade-aware decorator references; both 2-13 sync commands verified end to end against real drift and re-run idempotently. - Schema verified by live introspection after the input-alias restore: all four input/filter members match main, output deprecations intact; frontend metadata types and `twenty-client-sdk` schema regenerated from the running server. - Read-only-related and touched jest suites pass on both packages; typecheck and lint pass on `twenty-server` and `twenty-front`. <!-- CURSOR_AGENT_PR_BODY_END --> <div><a href="https://cursor.com/agents/bc-0f3e04cb-b04a-40be-8330-5609c4538e8a"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-web-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-web-light.png"><img alt="Open in Web" width="114" height="28" src="https://cursor.com/assets/images/open-in-web-dark.png"></picture></a>&nbsp;<a href="https://cursor.com/background-agent?bcId=bc-0f3e04cb-b04a-40be-8330-5609c4538e8a"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-cursor-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-cursor-light.png"><img alt="Open in Cursor" width="131" height="28" src="https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a>&nbsp;</div> <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21504?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com>	2026-06-13 07:10:22 +02:00
Charles Bochet	ee6fcdbec2	fix(front): show readable targets in morph relation picker (#21513) ... ## Problem The **morph relation picker is broken** when the user does not have read permission on *every* object a morph relation can point to. A morph (polymorphic) relation can target several objects. The single-record picker passed **all** of those target objects to the `search` query via `includedObjectNameSingulars`. The backend runs the per-object searches inside a single `Promise.all`, so if **one** target object is forbidden, the whole search rejects and the picker shows **"No records found"** — even for the target objects the user *can* read. This makes the morph relation picker unusable in any workspace where a role restricts read access to one of the morph targets (e.g. the demo workspace's `Object-restricted` role, which denies reading `Rocket` — the picker for a Pet's polymorphic owner then shows nothing, hiding the readable `Survey result` records too). ## Fix Filter the searched target objects down to the ones the current user is allowed to read before querying, in `useSingleRecordPickerPerformSearch`. This mirrors what the multiple-record picker (`useMultipleRecordPickerPerformSearch`) already does via `filteredSearchableObjectMetadataItems`. For a normal (single-target) relation this is a no-op; for a morph relation the picker now lists records from every target the user can read and silently skips the forbidden ones. ## Test Added `useSingleRecordPickerPerformSearch.test.tsx`: - excludes morph target objects the user cannot read from the search - keeps all targets when the user can read all of them ## Verification Reproduced locally on a Pet's "Polymorphic Owner" morph relation (targets `Rocket` + `Survey result`) with `Rocket` read denied: - **Before:** picker shows "No records found". - **After:** picker lists the readable `Survey result` records and omits the `Rocket` ones. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21513?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-12 23:28:50 +02:00
Charles Bochet	d22fa377e7	fix(front): store auth tokenPair in localStorage instead of a cookie (#21507) ... ## Problem A client hit an AWS S3 `RequestHeaderSectionTooLarge` error (`MaxSizeAllowed 8192`) when opening a `https://<workspace>.twenty.com/verify?loginToken=<JWT>` link — the request to load the `/verify` SPA page is served from S3, which rejects it before the app loads. The dominant cause is the **`tokenPair` cookie**. The auth tokenPair (access + refresh JWTs, ~2–5KB) was persisted in a host-scoped, JS-readable cookie. Nothing server-side ever reads it — the access token is sent to the API via an `Authorization: Bearer` header set in the Apollo auth link (`ExtractJwt.fromAuthHeaderAsBearerToken()` on the backend; no `cookie-parser`). Yet the browser attached that cookie to **every** request to the origin, including static assets and the `/verify` page. Combined with the `loginToken` in the URL, the request header section exceeds S3's 8192-byte limit. ## Fix Move `tokenPair` from cookie storage to **localStorage**, which is never transmitted in request headers. - `tokenPairState` now uses `useLocalStorage` (with `getOnInit: true`). - `getTokenPair` (the synchronous read used by the Apollo auth link) reads from localStorage under the same key. - A one-time migration (`migrateTokenPairCookieToLocalStorage`) runs before React renders: it ports any existing `tokenPair` cookie into localStorage and **deletes the cookie**, so already-authenticated users aren't logged out and the oversized cookie stops being sent. ## Why this is safe **Behavior:** equivalent. The cookie was host-scoped (no `domain` attribute), so it never provided cross-subdomain sharing — cross-workspace auth already re-establishes the token per-origin via the `loginToken`-in-URL → `/verify` handoff. localStorage has identical origin scoping. **Security:** neutral-to-positive. - No XSS protection lost — the cookie was **not** `httpOnly` (it can't be; JS reads it to build the Bearer header), so it was already XSS-exposed exactly like localStorage. - No CSRF surface change — the token was never sent as a cookie credential (no `credentials: 'include'`). - **Reduced exposure** — the token no longer leaks into CDN/proxy/server access logs or request headers, which is the actual bug. - Server-side revocation (`revokedAt`) and the 60-day refresh-token JWT expiry govern validity, so localStorage's lack of auto-expiry is moot. ## Testing - `getTokenPair` unit tests updated to localStorage. - New unit tests for the migration util (port, no-op, no-clobber, error-safety). - `nx test twenty-front` auth + apollo suites: 125 passing. - `lint:diff-with-main` clean; changed files typecheck clean. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21507?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-12 22:39:20 +02:00
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
Charles Bochet	462dd3b0e9	security: uuid CVE — bump bullmq/msal/blocknote + scoped resolutions for the rest (Dependabot alert 1289) (#21441) ... Closes the uuid Dependabot alert — [1289](https://github.com/twentyhq/twenty/security/dependabot/1289) — by **upgrading the parents that bump cleanly** and **scope-resolving only the ones that genuinely can't**. `uuid < 11.1.1` (buffer-bounds check in v3/v5/v6) is pulled by ~9 transitives. ### Bumped (parent upgrade — drops uuid<11, no behavior change; typecheck verified) - **bullmq** 5.40.0 → 5.78.0 — also aligned **ioredis** 5.6.0 → 5.10.1 (bullmq pins it) and fixed the renamed `Job.returnValue→returnvalue` / `stackTrace→stacktrace` (now `string[]|null`) in `admin-panel-queue.service.ts`. - **@azure/msal-node** ^3.8.4 → ^5.2.3 (5.2.4 was age-gate-quarantined). - **@blocknote/** ×5 ^0.47.3 → ^0.51.4. ### Scope-resolved to uuid 11.1.1 (no clean bump exists) - **sockjs** (latest; pinned by webpack-dev-server) and **@ptc-org/nestjs-query-typeorm** (9.4.0 *is* latest, pins `^10`) — no version drops uuid. - **typeorm** — a `patch:` dep / ORM core, too risky to bump. - **node-ical** 0.26 (type-model overhaul → caldav-parser rewrite) and **googleapis** 173 (Gmail/OAuth, 105→173) — large breaking migrations; **deferred to dedicated PRs**. - **@cypress/request** — transitive (cypress isn't a direct dep). Resolutions are **per-package** and preserve the intentional **uuid 13.x** (twenty-sdk / create-twenty-app). ### Verification - `twenty-server` typecheck ✓ (0 errors), `twenty-front` typecheck ✓ (0 errors). - `yarn install --immutable` ✓; every uuid resolves to **11.1.1** or **13.0.2**. - bullmq/msal/typeorm runtime exercised by the **server integration tests**; @blocknote by the **storybook tests** in CI.	2026-06-11 12:26:26 +02: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
Charles Bochet	232ca8eec2	security: clear happy-dom High alerts by upgrading wyw-in-js 0.7 → 1.1 (#21394) ... ## What Clears the 2 High `happy-dom` alerts (GHSA-w4gp-fjgq-3q4g, GHSA-6q6h-j7hj-3r64) via a parent bump — **no resolution**. `happy-dom@15.11.7` came from **`@wyw-in-js/transform@0.7.0`** (Linaria's CSS transform), pinned by a root resolution + a local `.yarn` patch and requested by `@wyw-in-js/vite@^0.7.0` in twenty-front + twenty-ui-deprecated. - `@wyw-in-js/vite` `^0.7.0` → `^1.1.0` (twenty-front, twenty-ui-deprecated) - `@wyw-in-js/babel-preset` `^0.6.0` → `^1.1.0` (twenty-ui-deprecated) - **drop the `@wyw-in-js/transform` 0.7.0 resolutions + the `.yarn` patch** — the patch added a `visited` cycle-guard to `TransformCacheCollection.invalidateIfChanged`, which is **already upstream** in transform 1.1.0, so it's obsolete. `@wyw-in-js/transform` now resolves to **1.1.0** (→ happy-dom 20.10.2) and 0.8.1 (website, unchanged, → happy-dom 20.8.9). The vulnerable 0.7.0/15.11.7 are gone. ## Required config change wyw-in-js 1.x resolves modules in its CSS pre-build via vite's `resolve.alias` instead of `vite-tsconfig-paths`. So twenty-front's `@/` and `~/` tsconfig path aliases are mirrored into `vite.config` `resolve.alias` — otherwise the CSS evaluator throws `Cannot find module '@/...'` for aliased imports used inside `styled` definitions. ## Verification - happy-dom now **20.8.9 + 20.10.2** (both patched); no 15.x left - `nx build twenty-front` — CSS extraction works (**1018 files transformed**) + `typecheck` - `nx build twenty-ui`, `twenty-ui-deprecated` (Linaria CSS extraction) - website's Linaria transform runs fine (local build only stops on a missing `TWENTY_PARTNERS_API_URL` env var, unrelated) - `yarn install --immutable` clean	2026-06-10 11:24:38 +02: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
Charles Bochet	0d8d463a44	security: clear all High minimatch Dependabot alerts via parent bumps (#21373) ... ## What Clears **all 14 High `minimatch` ReDoS alerts** (GHSA-7r86-cg39-jmmj, GHSA-23c5-xmqv-rm74, GHSA-3ppc-4f35-3m26) in the root tree — **by bumping the actual parent dev tools, with no `resolutions`/overrides**. Each parent that pinned a vulnerable minimatch is upgraded so the patched version resolves naturally. | Vulnerable minimatch | Pinned by | Fix | |---|---|---| | 10.0.3 | `@microsoft/api-extractor` 7.55.1 | → 7.58.7 (in-range refresh) → minimatch 10.2.3 | | 3.1.2 | `@stoplight/spectral-core` 1.20.0 | → 1.23.0 (in-range refresh) → minimatch ^3.1.4 | | 3.0.8 | `vite-plugin-dts` 3.8.1 → api-extractor 7.43.0 | bump to `^4.5.4` (already used elsewhere here) → minimatch 10.2.3 | | 4.2.3 | `graphql-config` 4.5.0 via `@graphql-codegen/cli` ^3.3.1 | bump cli to `^5.0.7` → graphql-config 5.1.6 → minimatch ^10 | | 9.0.3 | `zapier-platform-cli` ^15.4.1 | bump to `^19.0.0` | | 7.4.6 | `verdaccio` 6.5.2 → `@verdaccio/core` 8.0.0-next | refresh to 6.7.2 → core 8.1.1 → minimatch 7.4.9 | All six are **build/test tooling** — the ReDoS exposure is build-time, never shipped to users. ## Verification - ✅ Every resolved `minimatch` in `yarn.lock` is now ≥ its patched floor (3.1.5 / 7.4.9 / 9.0.9 / 10.2.3+). No `resolutions` added. - ✅ `nx build`: twenty-shared, twenty-ui, twenty-ui-deprecated, twenty-emails (validates vite-plugin-dts v4) - ✅ twenty-zapier: typecheck + build + `zapier validate` (35/35 checks pass; cli 19 + core 15.5.1) - ✅ twenty-front: typecheck; `graphql:generate` with codegen cli 5 produces **byte-identical** output (no generated-file changes in this PR) - ✅ `yarn install --immutable` clean ## Notes - The large `yarn.lock` diff is expected: major bumps to codegen (3→5), zapier-cli (15→19), and vite-plugin-dts (3→4) cascade through dev-tree transitives (net −1244 lines after dedup). - `zapier-platform-core` (runtime) intentionally left at 15.5.1 — only the CLI (dev tool) carried the vulnerable minimatch; `zapier validate` flags only a non-blocking "consider upgrading core" suggestion. - codegen plugins (`typescript`/`typescript-operations`) left at v3: they run fine under cli 5 and produce identical output, so the minimal change is just the cli bump.	2026-06-09 18:08:14 +02:00