## What
Import `react-data-grid/lib/styles.css` in `SpreadsheetImportTable`, the
single component that renders the import grid (used by the Validate Data
and Select Header steps).
## Why
The React 19 migration (#21531) bumped `react-data-grid` from
`7.0.0-beta.13` to `7.0.0-beta.59`. The old beta auto-injected its
layout CSS; beta.59 ships it as a separate
`react-data-grid/lib/styles.css` export that must be imported manually.
It was never imported, so the grid lost its base layout (grid template,
row heights, cell positioning): rows stacked at full height and columns
no longer aligned. The library scopes its styles under `@layer rdg`, so
the existing Linaria theme overrides still take precedence.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21867?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. -->
## Before
<img width="2540" height="1448" alt="CleanShot 2026-06-19 at 17 43
58@2x"
src="https://github.com/user-attachments/assets/a208b518-9088-4988-8245-4fdc4f8bc8de"
/>
## After
<img width="2454" height="1392" alt="CleanShot 2026-06-19 at 18 02
36@2x"
src="https://github.com/user-attachments/assets/e0b30d71-8244-4363-86aa-60b12a2dfdd9"
/>
## Context
Closes#21773
<img width="448" height="301" alt="Capture d’écran 2026-06-19 à 16 33
56"
src="https://github.com/user-attachments/assets/4efc637e-3361-4108-86b6-92ffc2e84252"
/>
When a workflow's variable picker (the `+` button next to a field) is
disabled — e.g. on a step whose only trigger is a global manual trigger
that produces no record variables — the button just shows a
`not-allowed` cursor with no explanation of *why*.
## Change
Add an `AppTooltip` to the disabled state of `WorkflowVariablesDropdown`
explaining the reason:
> No variables are available yet. Variables come from the workflow
trigger and previous steps.
The disabled state is reached via `disabled === true ||
noAvailableVariables`. In practice the callers hide the picker entirely
in read-only mode (it's rendered only when `!disabled`/`!readonly`), so
the meaningful trigger is **no available variables** — hence a single
message rather than separate copy per reason.
The tooltip is anchored with a `data-*` attribute selector instead of an
`#id`, because the picker's `instanceId` comes from React's `useId()`
(values like `:r1:`) which are invalid in a CSS `#id` selector that
`AppTooltip` runs through `querySelectorAll`.
## Testing
- `nx lint:diff-with-main twenty-front` — passes (lint + format).
- Verified the component resolves/renders on a local instance running
this branch.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21862?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
## What & why
Lets users resize the columns of a Kanban (record board) view. Requested
by a user; the design avoids the "ragged board" problem by making the
width a **single shared value**.
## Behaviour
- A drag handle appears on the right edge of every column header.
- Because all columns read **one** width value, dragging any handle
resizes **every** column together — they can never end up mismatched.
- Width is clamped between **150px** and **400px** (default **200px**).
- The width is **persisted per view** and restored on reload.
## Approach
**Backend** — a new nullable `View.kanbanColumnWidth` field, threaded
through the existing view-level setting pattern (the same one
`kanbanAggregateOperation` / `shouldHideEmptyGroups` use), so it gets
create/update/manifest/override support for free:
- entity column + `ViewOverrides` + `@WasIntroducedInUpgrade`
- `CreateViewInput` / `UpdateViewInput` (`Int`, `@Min(150)`/`@Max(400)`)
+ `ViewDTO`
- flat-view editable properties, entity-properties config, compare-type,
standard-view + manifest converters
- a fast instance command adding the `core.view` column
**Frontend** — the value hydrates into a view-scoped atom and drives a
single CSS variable set on the board container, which both column
headers and bodies read. Live dragging only writes that CSS variable (no
per-move React re-render); the final width is committed to the atom and
persisted via `updateView` on pointer-up.
## Nullability / defaults
`kanbanColumnWidth` is nullable — `null` means "never resized" and the
UI falls back to the 200px default, so existing rows need no backfill.
## Validation
- `nx typecheck twenty-server` ✅ and `nx typecheck twenty-front` ✅
- `nx lint:diff-with-main twenty-server` ✅; frontend lint fixes applied
(split constants to one-per-file, removed `useRef`-for-state in favour
of `useState`).
- Draft pending a final green CI run (the dev container reclaimed
`node_modules` mid-session; re-running locally).
## Test plan
- [ ] Drag a kanban column edge → all columns resize together, clamped
150–400px
- [ ] Reload → width persists for that view; other views unaffected
- [ ] A view that was never resized still renders at 200px
https://claude.ai/code/session_016Qe6oDBkhVbrq2QkXBJ5nE
---
_Generated by [Claude
Code](https://claude.ai/code/session_016Qe6oDBkhVbrq2QkXBJ5nE)_
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21828?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>
Builds on twenty-ui's existing runtime axe gate by adding a static
enforcement layer and fixing accessibility gaps in shared components.
Color contrast is intentionally out of scope (still deferred via
`A11Y_DEFER_COLOR_CONTRAST`).
## What changed
- **Static guardrails:** enabled oxlint's `jsx-a11y` plugin
(keyboard-operability rules at `error`), and added a custom
`twenty/no-storybook-a11y-disable` rule that blocks `a11y: { test: 'off'
| 'todo' }` so the axe gate can't be silently disabled again.
- **Focus visibility:** wired the existing `focus-ring` mixin into all
buttons for real `:focus-visible` rings (was `outline: none`).
- **Decorative icons:** `aria-hidden` on icons inside labeled buttons
(added to `IconComponentProps` + render sites).
- **Inputs:** accessible-name support on `SearchInput` and `Checkbox`.
- **Interactive components:** `Tag` renders a real `<button>` when
clickable; the non-semantic clickable `div`s (`Avatar`, `Status`,
`ColorSchemeCard`, `NavigationBarItem`, etc.) are now keyboard-operable
via a shared `handleClickableElementKeyDown` helper, role and accessible
name.
## Notes for reviewers
- Two `oxlint-disable` lines remain on genuine non-interactive capture
wrappers (`CodeEditor`, `OverflowingTextWithTooltip`).
- 8 lint warnings remain by design: conditional-interactivity
`no-static-element-interactions` and legitimate `autoFocus` on
`SearchInput`.
- `NavigationBarItem` gained a required `ariaLabel`; its only consumer
(`MobileNavigationBar`) is updated with translated labels.
## Follow-ups (separate PRs)
- Enforced accessible names on icon-only buttons
(`IconButton`/`LightIconButton`) — breaking, ~128 call sites.
- `aria-activedescendant` wiring for the dropdown/listbox keyboard
layer.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21848?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
The rebuilt-site cutover dropped several `next.config.ts` blocks the
previous twenty-website had:
- **`deploymentId`** — required by `open-next.config` skew protection;
deploys were failing with *"Deployment ID should be set in the Next
config when skew protection is enabled"*.
- **Security headers** (HSTS, CSP `frame-ancestors`, X-Frame-Options, …)
+ immutable asset `Cache-Control`.
- **Redirects** — www→apex canonicalization and content redirects (docs,
legal, case-studies, partners, why-twenty).
Legacy raw locale-code redirects were intentionally not restored (the
site only serves en/fr/es; those URLs never existed for other locales).
Pairs with twentyhq/twenty-infra#741, which builds twenty-ui before the
worker build.
## Context
Fixes#21765.
<img width="1439" height="961" alt="Capture d’écran 2026-06-19 à 15 03
46"
src="https://github.com/user-attachments/assets/07104099-19de-45f9-9cca-eaaacbc326af"
/>
When a page-level information banner is visible on a record table (e.g.
the mailbox **"Sync lost with mailbox … Please reconnect"** banner), the
table footer / bottom edge was hidden behind the card boundary. As a
side effect, drag-select **auto-scroll never triggered** near the
bottom, because the cursor could not reach the scroll wrapper's real
bottom edge.
## Root cause
In `PageCardLayout`, the `InformationBannerWrapper` and the page
children are siblings in a flex column. The record index child
(`StyledIndexContainer`) used `height: 100%`, so it demanded the
**full** body height regardless of the banner. With a banner present,
banner height + 100% exceeded the card, and since the container's
content (the table) has a large min-content height it would not shrink —
so the bottom (the footer) was pushed past `StyledCard`'s `overflow:
hidden` and clipped.
`useDragSelectWithAutoScroll` only scrolls when the cursor is within
`AUTO_SCROLL_EDGE_THRESHOLD_PX` (20px) of `containerRect.bottom`. With
the bottom edge clipped off-screen, that zone was unreachable, so
auto-scroll appeared broken.
## Fix
Replace `height: 100%` with `flex: 1; min-height: 0;` so the container
takes the space **remaining** after the banner — the same flex idiom its
parent `StyledBodyContent` already uses. When no banner is shown, the
banner wrapper collapses to `height: 0`, so the table fills the full
height exactly as before (no behaviour change in the common case).
## Testing
- Verified locally: with the mailbox reconnect banner forced visible on
the Companies table, the footer (aggregate row) stays visible and
drag-select auto-scroll reaches the bottom.
- No change when no banner is present.
This is a layout fix, not a drag-select threshold change — as suggested
in the issue, raising the threshold would only mask the layout problem.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21852?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. -->
# Introduction
On a logic function deletion also remove the driver entry
On a app uninstall also remove the sdk layer ( keeps the dep one as it
can be shared across several lambda )
| Resource | Scope | Before this PR | After |
|---|---|---|---|
| DB metadata (functions, objects, fields…) | per-app | deleted |
deleted |
| Source folder (`FileFolder.Source`) | per-function | deleted | deleted
|
| Built handler file (`FileFolder.BuiltLogicFunction`) | per-function |
deleted | deleted |
| **Lambda function** | per-function | **leaked** | **deleted** (driver
`delete`) |
| **SDK layer** `sdk-<wsId>-<appId>` (all versions) | per-app |
**leaked** | **deleted** (driver `deleteApplicationResources` →
`deleteSdkLayer`) |
| Deps layer `deps-<checksum>` | shared across apps/workspaces | not
deleted | **intentionally not deleted** (content-addressed, GC'd) |
## What I don't like about all that
Right now there's some non reversible side effect inside the workspace
migration transaction
- If the transaction fails we're facing data loss
- It also slows down everything
I'm about to create a new PR that allow population post transaction
commit side effect / cleanup to be run later
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21749?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
## Problem
Closes#21780.
When editing a **Phones** field in Settings → Data Model, changing the
**Default Country Code** does not enable the Save button — the form
becomes dirty but never valid, so the change can't be saved.
## Root cause
The settings form validates `defaultValue` with the record-value
`phonesFieldValueSchema`, which requires non-null strings:
```ts
primaryPhoneNumber: z.string(),
primaryPhoneCountryCode: z.string(),
```
But a Phones default value can legitimately have **null** subfields — a
default country code with no default number. The backend normalizes
empty subfields to `null`
(`nullify-empty-phones-default-value.util.ts`), and the shared contract
`FieldMetadataDefaultValuePhones` is `string | null`. So an existing
field whose stored default has `primaryPhoneNumber: null` makes the form
**permanently invalid**: changing the country code preserves the null
number → `isValid` stays `false` → `canSave = isDirty && isValid` keeps
Save disabled.
The sibling **address** field doesn't have this bug because
`addressFieldValueSchema` already makes every subfield `.nullable()`.
Phones was simply inconsistent.
## Fix
Add a dedicated `phonesFieldDefaultValueSchema` with nullable subfields
(mirroring the address pattern and matching
`FieldMetadataDefaultValuePhones`) and use it in the Phones settings
form. The stricter record-value `phonesFieldValueSchema` is left
untouched, so record input/persistence/empty-checks are unaffected.
## Test plan
- [x] Unit test covering the partial-null default value (and asserting
the record-value schema still rejects it)
- [x] `nx typecheck twenty-front` clean
- [x] `nx lint:diff-with-main twenty-front` clean
- Manual: open a Phones field, set a Default Country Code and save,
re-open, change the country code → Save now enables.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21847?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 Opus 4.8 <noreply@anthropic.com>
## What & why
After sign-up, users are redirected to `/sync/emails` and the page loads
forever; a full refresh fixes it. This blocks production deploy.
**Root cause** — a GraphQL field resolver returns an unrefreshed (stale)
workspace:
- `@AuthWorkspace()` (`request.workspace`) is read from the per-instance
core entity cache and can still be `PENDING_CREATION` /
`ONGOING_CREATION` right after `activateWorkspace`.
- The `currentUser` query resolver and the `onboardingStatus` field
already guard against this by calling
`refreshWorkspaceIfPendingOrOngoingCreation(...)`.
- But the `currentWorkspace` `@ResolveField` returned the raw
`@AuthWorkspace()` workspace. Because a field resolver takes precedence
over any value the query resolver attaches to its returned object, the
client receives that stale workspace.
So right after activation the client got an inconsistent payload:
- `onboardingStatus: SYNC_EMAIL` (fresh — computed from a direct DB
read)
- `currentWorkspace.activationStatus: ONGOING/PENDING_CREATION` (stale)
On the frontend, metadata loading is gated on
`isWorkspaceActiveOrSuspended(currentWorkspace)`, and
`MinimalMetadataGater` does **not** exclude `/sync/emails`. So the
workspace looked inactive → metadata never loaded (no metadata GraphQL
request was even issued) → the gater's loader showed indefinitely. A
full refresh worked because the cache had since refreshed to `ACTIVE`.
## Why it surfaces on staging but isn't caught by tests
The stale window only opens on a real fresh sign-up followed by
immediate activation, against a workspace cache that hasn't refreshed
yet (multi-instance / cache TTL). Single-instance local dev and the
existing `successful-user-and-workspace-creation` integration test
exercise `activateWorkspace` + `getCurrentUser` against one consistent
cache, so `currentWorkspace` already looks `ACTIVE` and they pass —
which is why this reproduces on staging/production but not locally, and
why a manual refresh recovers.
## How
Refresh the workspace in the `currentWorkspace` field resolver too, so
it is consistent with `onboardingStatus`. For active workspaces this is
a no-op (no extra DB read).
```ts
async currentWorkspace(@AuthWorkspace({ allowUndefined: true }) workspace) {
if (!isDefined(workspace)) return workspace;
return this.userService.refreshWorkspaceIfPendingOrOngoingCreation(workspace);
}
```
This is preferred over the frontend alternative (excluding
`/sync/emails` from `MinimalMetadataGater`), which would only hide the
symptom while every other consumer still received a wrong
`activationStatus`.
## Verification
- `nx typecheck twenty-server` and `nx lint:diff-with-main
twenty-server` (oxlint + oxfmt) are green.
https://claude.ai/code/session_018c1X6CwDgttMXA5tB797yS
---------
Co-authored-by: Claude <noreply@anthropic.com>
## What
The People Data Labs enrichment logic functions (`enrich-person`,
`enrich-company`, `enrich-people`, `enrich-companies`) now expose an
**`Update fields`** select instead of the `overrideExistingValues`
boolean, and always return the enriched data in their output.
`Update fields` options:
- **Yes and overwrite**: persist, overwriting existing standard fields
- **Yes and don't overwrite** (default): persist, filling standard
fields only when empty
- **No**: write nothing to the record (no CRM fields, no PDL metadata,
no company creation)
## Why
The functions previously only persisted data. With `No`, they can now
fetch from PDL and return the result without modifying the record, so
downstream workflow steps can consume it. Every matched result now
carries a `data` object with the mapped record fields (standard + `pdl*`
values), and the bulk functions also declare their `results[]` array in
the output schema.
Billing is unchanged: a successful PDL match is still charged in all
modes, since the API cost is incurred regardless of persistence.
## Notes
- Default behavior is preserved (unset input means fill-empty +
persist).
- Typecheck, lint, and the full unit suite (368 tests) pass.
## Summary
The Getting Started pages on the docs site (docs.twenty.com) were only
ever available in English, never translated into the other supported
languages.
**Root cause:** The Getting Started section (added in #19728) was never
added to the Crowdin source config (`crowdin-docs.yml`), so its `.mdx`
files were never uploaded for translation. Only `user-guide`,
`developers`, and `twenty-ui` were configured.
This also surfaced a related bug: because the pages had no translations,
the navigation generator fell back to the English page path for every
language, duplicating paths like `getting-started/introduction` across
all 14 language navs. Mintlify treats duplicate cross-language paths as
undefined behavior, which broke the language switcher (it always
redirected to `/getting-started/introduction`).
## Changes
- `.github/crowdin-docs.yml` — add `getting-started/**/*.mdx` as a
translation source so the pages get sent to Crowdin.
- `packages/twenty-docs/scripts/fix-translated-links.sh` — add
`getting-started` link-rewriting rules to match the other sections.
- `packages/twenty-docs/scripts/generate-docs-json.ts` — only include a
page in a non-default language when its translated file exists; drop
empty groups/tabs (removes the duplicate cross-language paths that broke
the switcher).
- `packages/twenty-docs/docs.json` — regenerated.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21842?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 <cursoragent@cursor.com>
## Problem
On a self-hosted instance, an AI Agent workflow action fails at run time
with an opaque model error:
```
The model returned the following errors: tools.0.custom.input_schema.properties:
Property keys should match pattern '^[a-zA-Z0-9_.-]{1,64}$'
```
This is Anthropic's validation on tool `input_schema` **property keys**.
An AI Agent's structured **Output** fields are turned into a JSON schema
and passed to the model as a tool; each output **variable name** becomes
a property key. Anthropic rejects any key that does not match
`^[a-zA-Z0-9_.-]{1,64}$` — most commonly a name containing a **space**
(e.g. `meetings brief`), but also names over 64 characters or with other
symbols.
Until now nothing validated this: `fieldsToSchema` writes
`properties[field.name]` verbatim, so a bad name only failed once the
workflow executed, with an error that gives the user no idea what to
fix. It doesn't reproduce on every instance — it depends purely on how
the workflow's output variables happen to be named.
## Fix
Introduce a single shared check,
`isValidAgentResponseSchemaPropertyKey`, and enforce it in two places:
- **Backend** — `validateAgentResponseFormat` now rejects invalid output
field names at agent **save time** with a clear `userFriendlyMessage`,
instead of letting the broken schema reach the model. This also gates
agents created via the API and re-saves of existing bad data.
- **Frontend** — the output schema builder shows an inline error on the
Variable Name field as soon as an invalid name is entered.
## Tests
- Unit test for the shared validity check (valid + invalid cases:
spaces, leading space, empty, > 64 chars, symbols, unicode).
- Unit test for `validateAgentResponseFormat` covering text/json
formats, valid names, a space in a name, an over-length name, and
reporting multiple invalid names at once.
## Notes for the reporter
The immediate unblock for an affected workflow is to rename the output
variable to remove the space (e.g. `meetings brief` → `meetings_brief`)
and retry the run. With this change the bad name is caught up front with
an explanation rather than failing mid-run.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21834?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
## Summary
Relation field cells in the record table render their chips through
`ExpandableList`, which measured how many chips fit only once (during
the
children ref pass) and cached the cutoff. It recomputed on item-count
and
hover changes, but never when the cell's available width changed — so a
cell
measured while narrow stayed stuck on that count even after the column
grew
wider. This is the "only ~3 items shown even when the cell is larger"
bug.
This PR adds a `ResizeObserver` on the outer container that resets the
first
hidden child index whenever the available width changes, so the list
reveals
as many chips as fit (and re-trims when narrowed). The outer container
is
observed because its width tracks the available width independently of
how
many chips are currently rendered, which avoids a
measure → trim → shrink → re-measure feedback loop. The observer is
cleaned
up on unmount.
## Test plan
- [x] Added a Storybook interaction test
(`RecomputesVisibleChipsOnResize`)
that renders the list in a narrow container, widens it, and asserts more
chips become visible.
- [x] Verified the test fails without the fix and passes with it.
- [x] `oxfmt` and `oxlint` pass on the changed files.
- Manual: open a record table with a to-many relation field that has
several
linked records, widen the column, and confirm more chips appear.
Fixes#12039
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
## Summary
- Fixes https://github.com/twentyhq/core-team-issues/issues/2460
- Engine/headless commands always skipped closing the menu
(`closeSidePanelOnCommandMenuListExecution: false`), even when the item
was not pinned. Edit Layout is `isPinned: false`, so the menu should
close like other list-only actions.
## Approach
- Option 1 (I chose this one): Derive close behavior from
`item.isPinned` -> pinned commands keep the menu open; non-pinned ones
close it.
- Option 2 (not chosen): remove the engine command override totally and
use the default close behavior for all commands.
Option 1 is more targeted: it fixed Edit Layout without changing pinned
commands (e.g. Export progress in the menu list). Option 2 is simpler
but widens the blast radius to every engine command clicked from the
side panel list.
## Screenshots
### Before
https://github.com/user-attachments/assets/70b8dc75-af00-4917-81a1-646381f571d5
### After
https://github.com/user-attachments/assets/f733d696-9330-4e6c-993b-8a8133c53e0d
---------
Signed-off-by: Parship Chowdhury <parshipchowdhury@gmail.com>
Co-authored-by: Charles Bochet <charles@twenty.com>
## What
The [Filters & Sorting user
guide](https://docs.twenty.com/user-guide/views-pipelines/capabilities/filters-and-sorting)
lists a **Between** operator for **Number** fields, but it does not
exist in the product and we do not plan to implement it. This removes it
from the operators table.
| Field Type | Before | After |
|---|---|---|
| Number | Equals, Greater than, Less than, **Between**, Is empty |
Equals, Greater than, Less than, Is empty |
The **Date** row is intentionally left untouched.
## Why
Avoids documenting a capability that does not exist (the same gap that
prompted #20932). Closing the external PR that attempted to add it for
numbers; the docs should reflect what we actually ship.
## Notes
- Only the canonical English source is edited; localized copies under
`packages/twenty-docs/l/*` are regenerated by the existing i18n
docs-translation workflow.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21838?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
## Summary
Clicking **Create Workspace** in the multi-workspace dropdown did
nothing.
The handler closed the dropdown right before redirecting:
```ts
const createWorkspace = () => {
closeDropdown(MULTI_WORKSPACE_DROPDOWN_ID); // unmounts this component
redirectToDefaultDomain({ ... }); // schedules window.open ~1ms later
};
```
`redirectToDefaultDomain` → `useRedirect` wraps the navigation in
`useDebouncedCallback(..., 1)`. `closeDropdown` flips the dropdown
content to `{isDropdownOpen && ...}` → `false`, unmounting
`MultiWorkspaceDropdownDefaultComponents` — the component that owns that
debounced callback. `use-debounce` drops the pending call on unmount, so
the queued `window.open` never fires. React commits the unmount before
the 1ms timer, so it loses every time. Regression from #21723, which
added the `closeDropdown` call.
## Fix
Remove the `closeDropdown` call. The redirect navigates the whole page
away, so closing the dropdown first is unnecessary — and it mirrors the
sibling "switch workspace" handler, which already redirects without
closing.
## Why not reorder, or drop the debounce?
The 1ms debounce in `useRedirect` is intentional (#9079, "sleep before
redirect"). Callers set cookie-backed state immediately before
redirecting — e.g. `redirectToDefaultDomain` clears the
`lastAuthenticateWorkspaceDomain` cookie via `useCookieStorage`.
Deferring the hard navigation by one macrotask lets that cookie write
flush before the page tears down; removing it risks dropping the write.
Reordering wouldn't help either, since the unmount still beats the
timer. So the debounce is left untouched.
## Logout is not affected
`signOut` → `clearSession` navigates with `window.location.assign(...)`
directly (synchronous, not debounced) and never calls `closeDropdown`,
so it can't hit this race.
## Testing
- Before: clicking Create Workspace → `window.open` called 0 times, page
unchanged.
- After: navigates to
`<defaultDomain>/welcome?action=create-new-workspace` and renders the
"Create your workspace" form.
- Switch-workspace and Log out both still work.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21835?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
## What
The manual trigger output schema exposed the triggering record(s) under
a node labeled **Payload**. Relabels it to match what the node actually
contains:
- **Single-record** availability → **Record**
- **Bulk-records** availability → **Records**
## Why
"Payload" was a misnomer — the node holds the record(s) that triggered
the workflow. This is a display-label-only change.
## Notes for reviewers
- **No migration.** The persisted output schema key stays `payload`, so
existing variable references (`{{trigger.payload.x}}`) are unaffected.
- The front recomputes the output schema on the fly
(`computeStepOutputSchema`), so the variable picker shows the new labels
immediately, including for existing triggers.
- The backend (`workflow-schema.workspace-service`) is updated to match
for newly persisted/re-saved schemas. Previously persisted schemas keep
"Payload" until re-saved.
- Added `WORKFLOW_TRIGGER_RECORD_LABEL` /
`WORKFLOW_TRIGGER_RECORDS_LABEL` and removed the now-unused
`WORKFLOW_TRIGGER_PAYLOAD_LABEL`.
- Unit tests updated for both single and bulk cases (55/55 passing).
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21832?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
## Problem
On the **Record is updated** (and **upserted**) workflow trigger,
picking a record type under the **Advanced** submenu (i.e. a *system*
object) showed an empty "Fields (Optional)" list — you couldn't select
any field to watch.
## Root cause
The trigger's field picker (`WorkflowFieldsMultiSelect`) was called with
`actionType="UPDATE_RECORD"`, which runs each field through
`shouldDisplayFormField`. For `UPDATE_RECORD` that predicate requires
`(isUIEditable ?? true)` — correct for the *Update Record action* (you
can't write to a read-only field), but wrong for a *trigger*, where
you're choosing which fields to **watch for changes** and editability is
irrelevant.
System objects define their fields with `isUIEditable: false`, so every
field failed the gate and the list rendered empty.
## Fix
Add DATABASE_EVENT trigger type to separated from action type.
The `UPDATE_RECORD` / `UPSERT_RECORD` action paths are untouched.
## fix(security): bump tar to 7.5.16 in seed-dependencies (PAX file
smuggling)
Resolves [Dependabot Alert
#1500](https://github.com/twentyhq/twenty/security/dependabot/1500).
### What
`tar` (`node-tar`) `<= 7.5.15` applies a PAX size override to
intermediary GNU long-name/long-link headers, causing a tar-parser
interpretation differential (file smuggling) —
[GHSA-vmf3-w455-68vh](https://github.com/advisories/GHSA-vmf3-w455-68vh).
Patched in `7.5.16`.
This is the **seed-dependencies holdout** deferred from the main tar PR
(#21813): that lockfile + its checksum constants were also touched by
the form-data PR, so it was carved out to avoid a conflict. The
form-data PR has since merged, unblocking it.
### How
- Refreshed `tar` `7.5.13 -> 7.5.16` in `seed-dependencies/yarn.lock`
(transitive via `^7.5.4`, which already permits it) — an in-range
refresh, no override.
- Regenerated `DEFAULT_YARN_LOCK_CHECKSUM` in
`get-default-application-package-fields.util.ts` so the row-stored
checksum matches the value recomputed from file content in
`application.service.ts` (the deps-layer cache key;
`logicFunctionCreateHash` = SHA-512, first 32 hex). `package.json` is
unchanged, so `DEFAULT_PACKAGE_JSON_CHECKSUM` is unaffected.
### Verification
- No `tar <= 7.5.15` remains in the seed lockfile.
- Both checksum constants verified to match the canonical recompute of
the current seed files.
- Lint + format pass on the changed `.ts` file.
## What & why
Replaces the hosted Stripe Checkout redirect on the onboarding "Choose
your plan" step (credit-card trial) with an inline Stripe **Payment
Element**, so users never leave the app to enter card details.
## How it works
- **Frontend:** a deferred `<Elements mode="setup">` renders the Payment
Element, themed via the Appearance API. On Continue: `elements.submit()`
→ `checkoutSession` mutation creates the trialing subscription
server-side and returns its pending SetupIntent `clientSecret` →
`stripe.confirmSetup()` confirms the card (handling 3DS) → redirect to
the existing `/plan-required/payment-success`.
- **Backend:** new `BILLING_STRIPE_PUBLISHABLE_KEY` config var exposed
via `/client-config`; the card path creates the subscription with
`payment_behavior: default_incomplete` + a free trial (so Stripe
attaches a `pending_setup_intent`) and returns its client secret. The
hosted-Checkout code path is removed.
- The **no-credit-card** trial path is unchanged.
- Billing address collection is **disabled** in the Payment Element to
reduce friction; `automatic_tax` is correspondingly disabled (tax needs
an address — collect it later, e.g. at conversion / via the billing
portal).
## Required before this works
1. Set `BILLING_STRIPE_PUBLISHABLE_KEY` (`pk_…`) on the server (infra
change pending).
2. Run `nx run twenty-front:graphql:generate --configuration=metadata`
against a server exposing the updated schema (see inline note on the
hand-authored document).
3. Verify in Stripe test mode: happy path, 3DS (`4000 0025 0000 3155`),
a decline.
## Verified
typecheck (front + server), oxlint + oxfmt clean,
`client-config.service.spec` passing. Not run here: the app end-to-end /
Stripe test mode and `graphql:generate` (no server/DB in the dev
container).
I've left self-review comments inline flagging cleanup opportunities
plus a couple of architectural/tech-debt items.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01TxCfinXq7abSrbF7aTw2cA
---
_Generated by [Claude
Code](https://claude.ai/code/session_01TxCfinXq7abSrbF7aTw2cA)_
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21759?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>
## Fixes#20940
### Problem
The "Move Left" / "Move Right" actions in the table column header menu
were unreliable. Clicking them often produced no visible change, or
appeared to move the column an inconsistent number of positions.
### Root cause
`useMoveRecordField` computed the swap target from **all** record fields
(`currentRecordFieldsComponentState`) sorted by position — including
hidden and non-readable columns. As a result, a move frequently swapped
positions with an *invisible* neighbor, leaving the visible column order
unchanged.
This was also inconsistent with the drag-and-drop reorder path
(`useReorderVisibleRecordFields`), which already operates only on the
visible field set, and with the dropdown's own Move enable/disable
logic, which is based on `visibleRecordFields`.
### Fix
`useMoveRecordField` now sources the neighbor from
`visibleRecordFieldsComponentSelector` — the same selector that drives
the table display and the Move menu items (`isVisible && isReadable &&
isActive`, sorted by position). The real `position` values are still
swapped, so hidden columns keep their positions and only the visible
order changes.
### Tests
Added `useMoveRecordField.test.tsx`, which seeds real object metadata
with a hidden column interleaved between visible ones (by position) and
asserts that the visible selector reorders correctly after a move. The
test fails against the previous implementation and passes with this
change.
### How to verify
1. Open any table view.
2. Open a column header menu and click "Move Right" / "Move Left".
3. The column now moves reliably by one visible position each click,
regardless of hidden columns.
---------
Co-authored-by: Harsh Singh <harsh@Harshs-MacBook-Air.local>
Co-authored-by: Charles Bochet <charles@twenty.com>
## Summary
https://discord.com/channels/1130383047699738754/1517429151328374896
- The GraphiQL playground's automatic introspection query was firing
without an `Authorization` header, causing "GraphQL introspection has
been disabled" errors in production
- `defaultHeaders` only pre-fills the GraphiQL headers editor UI — it
does not inject headers into actual fetch requests
- Added `headers` to the `createGraphiQLFetcher` config so all requests
(including auto-introspection on load) are authenticated
## Test plan
- [x] Open Settings > API & Webhooks, select Core schema + GraphQL,
click Launch
- [x] Verify the introspection query in the network tab now includes the
`Authorization: Bearer ...` header
- [x] Confirm the schema explorer loads successfully in a production
environment (or with `NODE_ENV=production`)
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21821?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. -->
handleTokenRenewal returned rxjs EMPTY when there was no token pair or
token renewal failed, so the operation's link chain completed without
emitting a value. Apollo Client v4 treats that as an invariant violation
("The link chain completed without emitting a value"), which surfaces as
an uncaught error during auth/token transitions (e.g. the
workspace-token swap in onboarding). Re-emit the original error so the
operation rejects cleanly instead.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21822?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. -->
Renaming the package so any further PRs directed to the website are
targeted to the reworked code instead of diverging. Once merged, I will
start preparing this for deployment to dev to test before releasing to
prod. Any improvements will also be applied to this package.
I avoided making significant changes to API routes so nothing breaks,
but will test it thoroughly today to confirm. That said, everything is
ported - double checked.
Big diff PR, impossible to review, but last one! No more rebuilds.
The Create Profile step was skipped whenever the user already had a
first or last name (e.g. provided during sign-up or via SSO), because
the create-profile-pending flag was only set when both were empty.
Always set it so the step is presented during onboarding and the user
can review/confirm their profile; submitting it still clears the flag
and advances.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21823?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. -->
hardcoded activate_after -- 0 on everyone_left_timeout was getting
rejected by recall with a 400 (activate_after can't be 0). pulled it
into a named const, set to 1.
its weird -- recall doc says default is 0 -- but its erroring out for us
if we send zero. looks like the 0 default only applies when you leave
the field out, not when you pass it explicitly(did not verify). keeping
it as lowest possible value (1) for now.
what the property does -- after the meet starts, how long before the bot
starts watching the "everyone left" timeout. 1s is basically immediate,
which is what we wanted with 0 anyway.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21820?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
## What
Adds two Twenty partner-pipeline skills to
`twenty-partners/src/skills/`, plus a patch version bump.
### `twenty-partner-application-triage`
Ranks the partner-application backlog by net-new value and surfaces a
short chase-list of high-value applicants who haven't booked a call.
Read-only against the live partners workspace. Ships `rank.py` as its
scoring helper.
### `twenty-partner-meeting-recap`
After partner calls, pulls Fireflies meetings, matches each to an
existing Partner by attendee email/domain, writes a recap
(transcript-first, Fireflies summary as fallback), and injects it as a
Note linked to the partner via `NoteTarget`. Skips leads/discovery calls
(no Partner match) and meetings whose content isn't ready yet. Optional
`--prune` deletes the Fireflies recording once its recap is safely in
the CRM (confirmed first).
## Version
`twenty-partners` 0.5.4 → **0.5.5** (patch: additive skill docs, no app
behaviour change).
## Notes
- Both skills read credentials from `~/.twenty/credentials.env`; no
secrets committed.
- All GraphQL queries/mutations are the proven ones used against the
live workspace.
## Context
Logic functions can declare workflow inputs typed as records or arrays
of records (e.g. the People Data Labs enrichment functions), but the
workflow builder rendered those as a plain text input with a variable
picker, which is not usable.
## What this does
- Adds an `objectUniversalIdentifier` link on input schema properties,
so a record-typed input is tied to a workspace object.
- The SDK build infers it from a
`TwentyRecord<'objectUniversalIdentifier'>` marker type in the handler
signature, reading the object's universal identifier straight from the
source; explicit input schemas can still set the field directly.
- The workflow builder renders these inputs as a single record picker or
a record multi-select with the variable picker on the right. Selected
records are stored as record ids; `TwentyRecord<UID>` is a branded
`string`, so the handler signature reflects that it receives ids (a
bound variable resolves to whatever the referenced step produced).
- The multi-select collapses overflowing chips into a `+N` badge
(reusing `ExpandableList`) and its variable picker offers both record
objects and fields.
- Updates the People Data Labs enrichment inputs as the reference
implementation.
<img width="802" height="824" alt="CleanShot 2026-06-12 at 16 54 10@2x"
src="https://github.com/user-attachments/assets/a0896d74-0aab-49bd-a173-14c578a2e533"
/>
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21494?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. -->
Port of #21660 into the redone's enterprise backend.
- Extract getLicenseeFromStripeCustomer into the platform/enterprise
barrel, replacing the inline licensee-from-Stripe-customer block in the
activate route; cover its branches with a unit test.
- Add POST /api/enterprise/reissue: a support endpoint that re-signs an
enterprise key from a subscriptionId, guarded by a timing-safe compare
against ENTERPRISE_ADMIN_API_SECRET. Adapted to the redone — barrel
imports, node:crypto named imports, and the sibling routes' 503
configured-check guard — while keeping the original's generic
non-leaking 500.
- Document ENTERPRISE_ADMIN_API_SECRET in .env.example.
## fix(security): bump tar to 7.5.16 across lockfiles (PAX file
smuggling)
Resolves [#1472 1474 1476 1479 1481 1483 1485 1487 1489 1491 1493 1496
1498 1505](https://github.com/twentyhq/twenty/security/dependabot/1472
1474 1476 1479 1481 1483 1485 1487 1489 1491 1493 1496 1498 1505).
### What
`tar` (`node-tar`) `<= 7.5.15` applies a PAX size override to
intermediary GNU long-name/long-link headers, causing a tar-parser
interpretation differential (file smuggling). Patched in `7.5.16`.
### Why these alerts
The advisory is scanned across many independent Yarn projects, so it
surfaced as one alert per lockfile: the root `yarn.lock` plus 13
`packages/twenty-apps/**` lockfiles (each pulls `tar` transitively).
### How
- Refreshed `tar` to `7.5.16` in the root and all 13 app lockfiles —
they hold `tar` via `^7.5.x` ranges that already permit it, so this is
an in-range lockfile refresh (no override) via `yarn up -R tar`.
- The root additionally had `tar@7.5.15` exact-pinned by
`@mintlify/previewing`, which has **no upstream fix** (latest `4.0.1163`
still pins `7.5.15`). Added a scoped resolution
`@mintlify/previewing/tar -> ^7.5.16`, **extending the existing scoped
tar resolutions** already used for `@electron/rebuild` and
`@electron/node-gyp`.
### Not included
`seed-dependencies/yarn.lock` (alert #1500) is intentionally excluded:
that lockfile and its checksum constants are already modified by the
open form-data PR, so its `tar` bump will follow separately to avoid a
conflict.
### Verification
- No `tar <= 7.5.15` remains across the root or any app lockfile.
- `yarn install --immutable` passes.
## fix(security): remove vulnerable lodash 4.17.23 (code injection +
prototype pollution)
Resolves [Dependabot Alert
#824](https://github.com/twentyhq/twenty/security/dependabot/824) and
[#823](https://github.com/twentyhq/twenty/security/dependabot/823).
### What
`lodash` `<= 4.17.23` is affected by:
- **Code injection via `_.template`**
([#824](https://github.com/twentyhq/twenty/security/dependabot/824),
High)
- **Prototype pollution via `_.unset`/`_.omit`**
([#823](https://github.com/twentyhq/twenty/security/dependabot/823),
Medium)
Both are patched in `4.18.0`. The repo already resolved lodash to
`4.18.1` everywhere **except** one copy held at `4.17.23` by
`@stoplight/spectral-functions@1.10.1`, whose `~4.17.21` range capped
lodash below `4.18.0`.
### How
Instead of a standing `resolutions` override, this bumps the parent that
imposed the cap: **`@stoplight/spectral-functions` 1.10.1 → 1.10.3**
(pulled transitively via `@asyncapi/parser` ← `@mintlify/common`,
accepted through `^1.7.2`). 1.10.3 widened its lodash dependency to
`^4.18.1`, so the capped bucket collapses into the existing `4.18.1`
resolution and the vulnerable copy is removed — leaving the dependency
graph honest with no lingering override.
### Also
Refreshes `@types/lodash` to the latest **4.17.24**: bumps the
`twenty-client-sdk` pin `^4.17.15 → ^4.17.24` and dedupes the stale
transitive `*` bucket (4.17.15) into a single `4.17.24` resolution.
Type-stub only.
### Verification
- The only real `lodash` resolution is now `4.18.1` (remaining `4.17.x`
entries are `@types/lodash` type stubs, not the library);
`@types/lodash` resolves to a single `4.17.24` bucket.
- Lockfile-only dependency change; `yarn install --immutable` passes;
`twenty-client-sdk` typecheck passes.
`formatToShortNumber`
(`packages/twenty-shared/src/utils/format/formatToShortNumber.ts`)
picked the unit suffix from the **raw** value but printed the
**rounded** figure, so `999999` rendered as `"1000k"` instead of `"1m"`,
and `999999999` as `"1000m"` instead of `"1b"`. This affects
number/currency cells, column-footer aggregates, and dashboard charts.
The fix replaces the hard-coded band branches with a promotion loop that
derives the suffix from the rounded display value, so the suffix and
figure always agree at boundaries. Adds boundary, just-below-boundary,
and negative-boundary tests.
Red-green proven: the two new boundary tests fail on the original source
(`expected "1m" but got "1000k"`); the 11 pre-existing tests still pass;
all 13 pass with the fix. Verified with a standalone strict `tsc` (0
errors) and oxlint on both changed files.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21591?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
## Summary
Closes#20139.
In a workflow **Create / Update / Upsert Record** action, the field
input for a `SELECT` field always offered a **"No value"** option.
Selecting it clears the field — even when that field is **not nullable**
(for example an opportunity `Stage`). The maintainer asked in the issue
to *"not allow to put a 'No stage' if the field is not nullable"*.
### Root cause
`FormSelectFieldInput` unconditionally builds a `defaultEmptyOption` and
passes it as the `<Select>`'s `emptyOption`, regardless of the field's
nullability:
```tsx
const defaultEmptyOption = {
label: label ? t`No ${label}` : t`No value`,
value: '',
icon: IconCircleOff,
};
// ...
<Select ... emptyOption={defaultEmptyOption} />
```
The nullability is already available on the field metadata
(`FieldSelectMetadata.isNullable`), and the regular (non-workflow)
record input already gates its clear affordance on it in
`SelectFieldInput.tsx` (`fieldDefinition.metadata.isNullable &&
canSelectEmpty ? handleClearField : undefined`). The workflow form input
just wasn't using it.
### Fix
- Add an optional `isNullable` prop to `FormSelectFieldInput` and only
build the empty option when the field is nullable (`isNullable !==
false`). `emptyOption` is already optional on `<Select>`, so omitting it
cleanly removes the choice.
- Pass `isNullable={field.metadata?.isNullable}` from `FormFieldInput`'s
`isFieldSelect` branch.
The prop is optional and defaults to the previous behaviour, so the
other `FormSelectFieldInput` call sites (country, calling code,
currency, cron, etc.) are unaffected.
Scope is intentionally limited to single `SELECT`:
`FieldMultiSelectMetadata` has no `isNullable` field and the
multi-select input has no equivalent empty option, so it is left
untouched.
## 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] Added a `NonNullable` Storybook interaction test asserting the "No
value" option is not rendered when `isNullable={false}`
- [ ] Manual: in a workflow Update Record step on Opportunity, the
**Stage** field no longer shows a "No value" option; a nullable select
still does
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
Raphaël Bosi
