b602294f1dda96840fc891f0773f07399f3b0088
13993 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Félix Malfait
|
b602294f1d |
Hide the command menu button while the mobile side panel is open (#23471)
On mobile the side panel covers the page, but the page header stays mounted underneath. Its command menu button (`⌘K`, the `⋮` icon) sits at the same coordinates as the panel's own close button, so the two icons render on top of each other. Measured on a 390x844 viewport with the AI chat open: - `Command Menu` button at `x=346, y=8, 32x32` - `Close side panel` button at `x=358, y=14, 24x24` `SidePanelToggleButton` already hid itself for the command menu and search pages, but the AI chat pages (`AskAI`, `ViewPreviousAiChats`) are not in `COMMAND_MENU_SIDE_PANEL_PAGES`, so the button stayed and overlapped. ## Change Hide the button on mobile whenever the side panel is open, rather than enumerating pages — the header is not reachable behind a full-screen panel either way. Layout customization mode is the exception and keeps it: `alignWithSidePanelTopBar` deliberately repositions the button into the side panel top bar there, so that path is preserved. Desktop is unaffected. ## Testing Three cases added to `SidePanelToggleButton.test.tsx` (hidden on mobile with the panel open, kept on mobile in layout customization mode, kept on desktop with the AI chat open); the `useIsMobile` mock is now switchable per test. All 10 tests pass. Verified in the browser at 390x844: with the AI chat open only `Close side panel` remains in the top bar, and the button reappears once the panel is closed. --- _Generated by [Claude Code](https://claude.ai/code/session_018gcsCQbuTMsyFWv874p25Q)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23471?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. --> |
||
|
Félix Malfait
|
0859133774 |
Disable double-tap zoom while keeping pinch zoom (#23476)
Adds `touch-action: manipulation` on `body`. Context: #8477 disabled auto-zoom on iOS only, via `maximum-scale=1` behind a UA check. That leaves double-tap-to-zoom active everywhere, which is what makes taps feel laggy on mobile (the browser waits ~300ms to see if a second tap is coming) and what causes accidental zooms when tapping small targets twice in a row. `touch-action: manipulation` removes double-tap-to-zoom and the associated tap delay, and leaves pinch-to-zoom fully intact. So the page still zooms the way a website should, it just stops zooming when you didn't ask it to. This is deliberately not a revert of #8477 and not an extension of `maximum-scale` to Android: blocking pinch zoom fails WCAG 1.4.4, and being able to zoom is part of what makes this feel like a website rather than a native app. --- _Generated by [Claude Code](https://claude.ai/code/session_018gcsCQbuTMsyFWv874p25Q)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23476?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. --> |
||
|
Thomas Trompette
|
933ae9c20b |
fix(page-layout): render standalone rich text widget on record pages (#23435)
Fixes #21093 ## Problem A `STANDALONE_RICH_TEXT` widget can be created on a record page layout through the metadata API, and `getPageLayoutWidgets` returns it, but the record page renders nothing for it. `StandaloneRichTextWidget` only resolved a target id when `layoutType === PageLayoutType.DASHBOARD`, then bailed out with `return null` whenever that id was undefined. On a record page it never rendered. ## Why the guard was there It was correct when it was written. In #16437 the widget used the full `BLOCK_SCHEMA` and uploaded files: ```ts return await uploadAttachmentFile(file, { id: dashboardId, targetObjectNameSingular: CoreObjectNameSingular.Dashboard, }); ``` Without a dashboard id there was nowhere to attach an upload, and dashboards were the only layout type in play, so refusing to render was a coherent stance. #17934 then disabled file upload because the urls were not signed. It swapped in `DASHBOARD_BLOCK_SCHEMA`, dropped `useUploadAttachmentFile` and `prepareBodyWithSignedUrls`, and added `filterSupportedBlocks` to strip file blocks out of previously saved bodies. It left behind the attachments query, the `attachments` prop and the `useAttachmentSync` call. After that, `dashboardId` had one consumer left: a filter that could no longer match anything. The `return null` underneath it was guarding nothing. Record page layouts then made the widget reachable outside dashboards, and the stale guard blanked it. ## Fix The body lives on the widget configuration, not on the target record, so the widget needs no record id to display. The leftover attachment fetch has nothing to act on: - `DASHBOARD_BLOCK_SCHEMA` declares only paragraph, heading, lists, checklist, codeBlock, table and quote. No image, file, video or audio block. - The three sync utils all key off `ATTACHMENT_BLOCK_TYPES = ['image', 'file', 'video', 'audio']`, so they return empty for any body this editor can produce. - No `uploadFile` option, no `onPaste` handler, and `filterSupportedBlocks` strips unsupported blocks on load, so such a block cannot get in. So rather than generalise the attachment filter to every object type, this removes it: the `useFindManyRecords` call, the `attachments` prop, and the `useAttachmentSync` call in `StandaloneRichTextEditorContent`. It finishes the cleanup #17934 started. `useAttachmentSync` is untouched and still used by `RichTextFieldEditor`, which does support file blocks. Net result is a pure deletion, and the widget renders on every layout type. If image blocks are ever added back to `DASHBOARD_BLOCK_SCHEMA`, attachment sync will need to come back with them. ## Testing Local instance, widget created through `createPageLayoutWidget` on the default Company record page layout. - On the unpatched component the widget is absent from the page. - With the fix it renders read-only in the record page column. - Also verified with the payload shape from the issue (`markdown` set, `blocknote: null`); the server converts it to blocknote on write, so it renders too. - Verified on `calendarEvent`, an object with no `attachments` relation. Renders clean, no console or GraphQL errors. Generalising the old filter instead would have sent `targetCalendarEventId` and hit `Object attachment doesn't have any "targetCalendarEventId" field.` - Dashboard rendering unchanged, and editing still round-trips: typed into the widget in dashboard edit mode, hit Save, confirmed the new body in `core.pageLayoutWidget`. |
||
|
Félix Malfait
|
5d90fb33c0 |
Open records on a full page instead of a side panel on mobile (#23474)
On mobile the side panel covers the whole screen, so a record opened in
it arrives cramped behind an "Open" button offering the full page it
should have gone to in the first place.
`useResolveOpenRecordIn` already forces `RECORD_PAGE` on mobile via
`canDisplaySidePanel: !isMobile`, but it is a resolver callers have to
opt into, and only five do. Thirteen other call sites reach
`useOpenRecordInSidePanel` directly and get a panel on every device,
including:
- `TaskRow` and `NoteTile`, the activity lists inside a record's tabs
- `EventRowActivity`, `EventCardMessage`, `EventRowGenericLinked` on the
timeline
- `SidePanelSearchRecordsPage`, `EmailThreadPreview`,
`useOpenCreateActivityDrawer`, `useAddNewRecordAndOpenSidePanel`
## Change
Decide it inside `useOpenRecordInSidePanel` rather than at each call
site, so no caller can wedge a record into a panel by forgetting to ask.
On mobile it closes the panel and navigates to `AppPath.RecordShowPage`,
then returns before any of the side-panel setup runs.
Two details carried over so the redirect is not lossy:
- `setRecordPageActiveTabId` still runs first, so a caller passing `tab`
lands on the right tab.
- `isNewRecord` forwards `{ isNewRecord, objectRecordId,
labelIdentifierFieldName }` as navigation state, mirroring what
`useCreateNewIndexRecord` already does on its `RECORD_PAGE` branch, so a
freshly created record still opens its title for naming instead of
arriving untitled.
Side-panel-only effects are skipped rather than lost.
`runWorkflowRunOpeningInSidePanelEffects` ends in
`openWorkflowRunViewStepInSidePanel`, which auto-opens a step *in the
panel*; with no panel there is nothing for it to do, and the workflow
run's record page renders its own diagram.
The two hooks that already branch on `useResolveOpenRecordIn`
(`useOpenRecordFromIndexView`, `useCreateNewIndexRecord`) never call
into this path on mobile, so this is a no-op for them rather than a
double navigation.
Uses `useIsMobile` rather than `useIsTouchDevice`, matching
`useResolveOpenRecordIn`: this is a question of whether there is room
for a panel, not of how the user points.
## Testing
At 390x844, opening the search side panel and tapping a result now
navigates to `/object/person/<id>` with the panel closed, where it
previously stayed in the panel. Typecheck and lint clean.
---
_Generated by [Claude
Code](https://claude.ai/code/session_018gcsCQbuTMsyFWv874p25Q)_
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/23474?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. -->
|
||
|
github-actions[bot]
|
3e9e75e774 |
i18n - docs translations (#23466)
Created by Github action Co-authored-by: github-actions <github-actions@twenty.com> |
||
|
github-actions[bot]
|
75047f3237 |
i18n - translations (#23463)
Created by Github action --------- Co-authored-by: github-actions <github-actions@twenty.com> |
||
|
martmull
|
00e418a039 |
Show call recorders as calendar event participants (#23380)
Closes twentyhq/core-team-issues#2729 Call recordings attached to a calendar event are now displayed next to the human participants, in the timeline event card (`EventCardCalendarEvent`). They are rendered as the source app's `AppChip`, rounded so it sits in the participant avatar group, with the recording status in tooltip https://github.com/user-attachments/assets/e0c393c8-fd65-4468-8c4f-503dd22c13d5 ## Before No call recorder chip displayed TODO: add this in the calendar views (`CalendarEventRow`) |
||
|
github-actions[bot]
|
f84f242f9d |
i18n - docs translations (#23460)
Created by Github action <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23460?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: github-actions <github-actions@twenty.com> |
||
|
Félix Malfait
|
840c6d0129 |
Take openRecordIn from the view in scope instead of a global atom (#23422)
Stacked on #23424 (mobile chip navigation). Review that one first; the diff shown here is only the delta. ## Problem `recordIndexOpenRecordInState` was a global atom mirroring `view.openRecordIn`. It was written whenever any index view loaded and never reset, so a record chip behaved according to whichever view had been browsed last: - Companies view set to "record page". Open a Company, tap a related Opportunity chip. The Opportunities view says "side panel", but the chip reads the leftover Companies setting and opens a full page. - Visit the Opportunities index first, then the same Company page, and that same chip now opens a side panel. The setting is per view in the database, but the frontend kept it in one slot as though it were a user preference. ## Approach The value already lives on the view, so the mirror is deleted rather than scoped: - `useResolveOpenRecordIn` reads the current view of the surrounding context store. On a record index that is the view being displayed. On a record show page `MainContextStoreProvider` resolves a view for the object in the URL — the last visited view for that object, falling back to its index view — so chips there follow a view belonging to the object they sit on, rather than whatever was loaded last. - Where no context store is mounted at all (a mention inside a note, for instance) there is no view to take a setting from, so the hook falls back to `DEFAULT_VIEW_OPEN_RECORD_IN`. The instance lookup is non-throwing on purpose: `RecordChip` renders in a lot of places, and an existing test caught this crashing when the read was strict. - The options dropdown now reads and writes `currentView.openRecordIn` directly, the same way `isCompact` beside it already works, so `setAndPersistOpenRecordIn` only has to persist. - `useGetOpenRecordIn` is gone; every call site had the object name available at render, so the reactive hook covers all of them. ## Behaviour change A chip whose behaviour previously came from an unrelated view now follows the view in scope. That is the point of the change, but it does mean some chips will open somewhere different from before, always in the direction of "what this list is configured to do" rather than "what the last list was configured to do". ## Testing - New `useResolveOpenRecordIn` tests: falls back to the default with no context store, follows the context store's view when there is one. - Full frontend suite: 951 suites, 5598 tests passing. Typecheck and lint clean. - Not exercised in a running app: no database in this environment. The dropdown's optimistic behaviour in particular relies on the same view store refresh that `isCompact` already depends on, so it is worth a click-through before merge. |
||
|
github-actions[bot]
|
057468343f |
i18n - translations (#23459)
Created by Github action Co-authored-by: github-actions <github-actions@twenty.com> |
||
|
Félix Malfait
|
8990334cad |
Make record chips open records natively on touch devices (#23424)
Two mobile problems in the record table: tapping a chip in the first column takes two taps, and chips in every other column open a side panel where a full page is wanted. #23422 is stacked on this branch. ## Two taps to open a record The table's interactive layer lives in a hover portal mounted from `onMouseMove` on the table wrapper. Touch has no hover, so the browser fakes one, and the synthesised `mousemove` arrives *before* the `mousedown`. React commits the portal in the microtask between them, so the whole tap is hit-tested against a subtree that did not exist when the user aimed. Confirmed in Chromium with real touch input (`page.tap`, Pixel 5 emulation), mounting an overlay from the mousemove handler: ``` mousemove target=chip >>> overlay mounted <- the hover portal mousedown target=portalChip <- a node that did not exist when the finger went down mouseup target=portalChip click target=portalChip ``` The same test also ruled out `preventDefault` on the compat `mousedown` as a cause, and showed a `setTimeout`-deferred mount does *not* retarget — it is specifically React's sync flush timing that does. So hover state is now only tracked on hover-capable pointers. `useMoveHoverToCurrentCell` becomes the single writer and absorbs the deduplication `RecordTableContent` was duplicating inline. The interaction/layout split matters here: `useIsMobile` is a 768px width query, which answers "how much room is there to lay out", not "how does this person point". The new `useIsTouchDevice` uses `(hover: none) and (pointer: coarse)`. Layout keeps using width; interaction uses capability. ## Side panel on mobile "Where does a record open" was computed independently in six places and only `useOpenRecordFromIndexView` knew about mobile. `RecordChip` — every chip outside the first column, plus board cards and relation fields — had its own copy without that check. On mobile the side panel animates to `fullScreen`, so it is a full-page view with no URL and no back button. That decision now lives in one `resolveOpenRecordIn`: the view setting is an intent, and the side panel is only a real destination when there is room for it and the object supports it. Also here: `MOUSE_DOWN` navigation downgrades to `CLICK` on touch. It only buys a frame on a real pointer, since a tap synthesises its mouse events after the finger is already gone. ## Hover styling Separate layer, same root cause. A tap leaves CSS `:hover` applied until the next tap lands elsewhere, so a row you came back from keeps reading as selected. Nine `:hover` blocks across the record table, `Chip` and `Avatar` are now fenced behind `(hover: hover)` — the same media feature `useIsTouchDevice` branches on, via a new `hover-capable` SCSS mixin on the twenty-ui side and inline media queries in the Linaria components. Desktop rendering is unchanged, since Chrome matches `hover: hover`. Verified the built CSS emits the wrapper correctly, and checked the nested form through stylis directly for the Linaria side. ## Testing - New unit tests for `resolveOpenRecordIn` and for hover not being tracked on touch devices. - Full frontend suite: 951 suites, 5598 tests passing. Typecheck and lint clean. - Not observed end to end in a running app: no database in this environment, and the `RecordIndexPage` story renders an empty table under its msw mocks. The browser-level mechanism is verified and the fix removes the mid-gesture DOM change, but it is worth one pass on a real device before merge. ## Follow-ups not in this PR - The whole first cell navigates but only the chip-sized part of it gives tap feedback, and `isRecordTableRowActive` is only set on the side panel path — setting it on the navigate path too would keep the row lit while the page loads. - Rows are 32px against a 44px minimum touch target. - Giving the side panel a URL would make "panel vs page" a rendering decision on the same location, rather than something each call site has to branch on. --- _Generated by [Claude Code](https://claude.ai/code/session_019cDWPgWESbdRUhGxGb66j8)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23424?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. --> |
||
|
Félix Malfait
|
2d9582117b |
feat(front): preview highlighted record in the search command bar (#23413)
Previewing the highlighted record while searching. The preview is a card anchored to the highlighted result, and its fields come from the object's **index view** (the base list view), so what you see while searching matches the list you came from. ## Screenshots > Note: these were taken before the latest design pass (smaller header, field cap). The layout is otherwise unchanged. Highlighted result, showing the index view's columns:  Overflow and hidden columns sit behind the `More (N)` expander:  Arrowing to a Person re-anchors the card and renders that object's own index view fields:  ## Changes - `SidePanelSearchRecordPreviewCard.tsx` — the card: the shared `SidePanelPageInfoLayout` header (avatar + name + created-at), then read-only `FieldDisplay` rows, then the `More (N)` expander. - `useSidePanelSearchRecordPreviewFields.ts` — resolves the object's index view through `useViewOrDefaultView` and splits its `viewFields` into visible and hidden, sorted by position, dropping the label identifier since the card already shows the record name. - `useSidePanelSearchRecordPreviewItem.ts` — resolves the highlighted item from the selectable list, following the selection immediately. - `useSidePanelSearchRecordPreviewRecord.ts` — hydrates the record into the record store so field displays can read their values. The fetch is debounced 200ms so holding an arrow key doesn't fire a `findOne` per row crossed, and it reports whether the record is hydrated yet. - `SidePanelSearchRecordsPage.tsx` — anchors the card with `AppTooltip` (`place="left-start"`, controlled `isOpen`, `clickable` so the expander is reachable) against a per-result anchor id. ## How many fields show Collapsed, the card shows at most seven of the index view's visible columns. Everything past that, plus the columns hidden in that view, sits behind `More (N)`. So the expander appears whenever there are more fields than fit, not only when the view happens to have hidden columns. ## Keeping the card stable while it loads The first cut jumped: measuring it over time gave `288px → unmounted for ~200ms → 232px`. Two separate causes, both fixed. It was **unmounting between records** because the previewed item was debounced and briefly resolved to `null`. The selection is now followed immediately and the *fetch* is what's debounced instead, so the card is reused across records rather than remounted. Its **size was derived from the data**, so every value that arrived nudged the layout. The header, rows (24px) and width are fixed, with skeleton placeholders for values until the record is hydrated. The field list comes from view metadata, which is available synchronously, so the card is its final size on first paint. Measured after that change: a constant `360x328` across 13 consecutive records spanning Person and Workspace Member, and no unmount. The skeleton and loaded states are the same height, so values just fade in. The card still disappears briefly on a brand-new search. That tracks the results list turning over — the anchor row it attaches to is genuinely removed from the DOM — so following the list is the correct behaviour there rather than holding a stale card against a deleted anchor. ## Notes The preview is read-only (`FieldDisplay`, not `RecordInlineCell`) — a floating preview isn't the right place to start an inline edit, and it keeps the card out of the field hover/edit portal machinery. The `More` button is wrapped in a container that prevents the default mousedown focus shift. Without it, clicking the expander moved focus out of the search input and arrow keys started driving the record table behind the panel instead of the results list. The section heading still reads `Results`; the design says `Records`. Left as-is since it is out of scope here. ## Testing - `nx typecheck twenty-front` passes. - `oxlint --type-aware` and `oxfmt` clean on the changed files. - Verified manually against a seeded dev workspace: anchoring and re-anchoring on arrow navigation, Company vs Person rendering their own index view fields, the `More` expander, arrow keys still driving the results list after clicking it, and the card holding a constant size through load. |
||
|
Abdul Rahman
|
965e033f3f |
[breaking-change] fix(server): return runAgent execution failures as result errors (#23390)
## Summary
- When `executeAgent` throws, `runAgent` now returns `{ success: false,
error }` instead of a GraphQL exception
- Callers (workflows, Slack assistant, etc.) can surface the failure to
users instead of hanging or failing opaquely
Run agent exception response error format breaking-change, errors moved
from the GraphQL error channel into the response payload.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/23390?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. -->
|
||
|
github-actions[bot]
|
5b10869a2b |
i18n - docs translations (#23455)
Created by Github action Co-authored-by: github-actions <github-actions@twenty.com> |
||
|
Thomas Trompette
|
b6a4c635ee |
fix(workflow): rename the trigger step through the dedicated mutation (#23450)
## Bug Renaming the **trigger** step from the workflow side panel fails with: > Updating a workflowVersion through the generic mutation is restricted. steps, trigger, status, position, workflowId and coreWorkflowVersionId cannot be changed... Renaming a **regular** step works, which is why this is easy to miss: only the trigger branch is broken. ## Cause This is a regression from #23207. That PR added the server-side denylist on `updateOneWorkflowVersion` and switched `useUpdateWorkflowVersionTrigger` to the dedicated `updateWorkflowVersionTrigger` mutation, but missed the call site in `SidePanelWorkflowStepInfo`, which still did: ```ts if (isTrigger) { await updateOneWorkflowVersion({ // generic mutation, sends `trigger` updateOneRecordInput: { trigger: { ...stepDefinition.definition, name: title } }, }); } else { await updateWorkflowVersionStep({ ... }); // dedicated, unaffected } ``` The observed request confirms it: `UpdateOneWorkflowVersion` with `input.trigger`. ## Fix Route the trigger branch through `updateTrigger`, which already resolves the draft version, calls the dedicated mutation, marks the step for recomputation and updates the cache. `useUpdateWorkflowVersionTrigger` now accepts an **optional** `instanceId`. This matters here: the side panel computes the visualizer instance id explicitly (it already passes it to `useGetUpdatableWorkflowVersionOrThrow`), and without it the hook would resolve the updatable version from a different component instance. Being optional, the four existing callers are unaffected. Also removes the now-redundant `getUpdatableWorkflowVersion()` call on the trigger path, so a rename no longer risks resolving the draft twice. ## Verification - `nx typecheck twenty-front` green - `oxfmt` + `oxlint --type-aware` green on both changed files - `useUpdateWorkflowVersionTrigger` unit tests green (2/2) - Not yet clicked through locally; the reporter hit this on a dev instance and can confirm the rename now succeeds <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23450?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. --> |
||
|
github-actions[bot]
|
9acc5c192f |
i18n - docs translations (#23452)
Created by Github action <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23452?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: github-actions <github-actions@twenty.com> |
||
|
Charles Bochet
|
ea2de2dc2b |
ci(pr-review): label-only manual trigger, thin dispatcher (#23449)
Addresses the review feedback on #23418 (Paul + Copilot + cubic) and switches the manual trigger from comments to **labels**, consistent with the e2e labels. ## What changed - **Manual reviews are label-driven** — add `pr-review-security` / `pr-review-triage` / `pr-review-standard`. Labeling requires write access (team-only). The **`/pr-review` comment trigger is removed.** - Like the e2e labels, a check runs on every push **while its label is present** (the orchestrator reads the PR's current labels each run) — so `pr-review-standard` keeps the deep review current until removed. - **Dispatcher is now dumb** — it forwards only `pr_number`. All resolution + validation lives in the privileged orchestrator (Paul's suggestion: it fetches PR metadata, incl. labels, there anyway). This fixes the bot findings (regex allowlist bypass, `/pr-review`→standard default, delimiter edge cases) at the source. - `cancel-in-progress: true` (latest-push-wins, matching the previous dispatcher). Fires on non-draft PR events (the auto `security,triage` gate) and on `pr-review-*` label adds. ## Depends on A companion change to the privileged CI (reads labels + resolves/validates checks) — merge that first; it's backward-compatible, so nothing breaks in between. |
||
|
twenty-pr[bot]
|
4730542087 |
chore: bump version to 2.26.0 (#23451)
## Summary - Moves current version to previous versions array - Sets TWENTY_CURRENT_VERSION to the new version - Updates TWENTY_NEXT_VERSIONS with the next minor version - Bumps twenty-client-sdk, twenty-sdk, and create-twenty-app to the same version ## Checklist - [ ] Verify version constants are correct - [ ] Verify npm package versions match <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23451?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: Github Action Deploy <github-action-deploy@twenty.com> |
||
|
BOHEUS
|
e5ac9f5b8b |
Docs update (#23429)
Follow-up based on comments from https://github.com/twentyhq/twenty/pull/23266 <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23429?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Félix Malfait <felix@twenty.com> Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com> |
||
|
martmull
|
f5da810e59 |
feat(server): add application:install command (#23430)
Adds `application:install` to install an application on workspaces that do not have it yet, and moves both application commands onto `WorkspaceIteratorService`. ### Behavior - Iterates provisioned workspaces through `WorkspaceIteratorService` (workspace id resolution, workspace context, per-workspace success/fail report), or the ones passed with `-w`. - Workspaces where the application is already installed are skipped, with a log line pointing at `application:upgrade`. This command never upgrades. - Installed workspaces are detected by `universalIdentifier`, the same identity `ApplicationInstallService` uses to tell a fresh install from a version upgrade, checked per workspace on the `(universalIdentifier, workspaceId)` unique index. - `--workspace-count-limit` caps both the iterator's own selection and an explicitly targeted `-w` list. - Fails fast for `LOCAL` and `OAUTH_ONLY` registrations, which have no code artifacts to install. - Per-workspace failures are collected in the iterator report and never abort the run; the command ends with an installed / skipped / failed summary. ### Options | Flag | Description | | --- | --- | | `-u, --application-registration-universal-identifier` | Application registration universal identifier (required) | | `-w, --workspace-id` | Target a specific workspace, repeatable | | `--workspace-count-limit` | Cap the number of workspaces to iterate over (max 50) | | `-d, --dry-run` | Print the workspaces that would be installed without installing | | `-y, --yes` | Skip the confirmation prompt | ### Example ``` yarn command:prod application:install -u UNIVERSAL_IDENTIFIER --dry-run ``` ### Changes to application:upgrade - `ApplicationUpgradeService.upgradeApplications` iterates through `WorkspaceIteratorService` and returns its report, replacing the hand-rolled parallel batching. - `--batch-size` dropped from the command, and `batchSize` dropped from the service and from `UpgradeApplicationsJobData`, since `iterate()` is sequential. - `parseBoundedPositiveInteger` moved to `src/database/commands/utils/` and is shared by both commands. ### Files - `application-install/commands/install-application.command.ts` (new) - `src/database/commands/utils/parse-bounded-positive-integer.util.ts` (new) - `application-upgrade/application-upgrade.service.ts`, `application-upgrade/commands/upgrade-application.command.ts`, `jobs/upgrade-applications.job*`: iterator instead of batching - `application-install.module.ts` / `application-upgrade.module.ts`: register the command, wire `WorkspaceIteratorModule` - `database-command.module.ts`: import `ApplicationInstallModule` so the command is discovered by the CLI ### Testing - `npx jest src/engine/core-modules/application` (32 suites, 181 tests passing) - `npx nx typecheck twenty-server` - `oxlint --type-aware` and `oxfmt` on the changed files |
||
|
martmull
|
942755d0dd |
fix(applications): display the installed application icon (#23411)
## Problem
After installing an app, its icon is missing across the UI, while
application *registration* icons render fine.
`Application.logo` holds the manifest path (`public/logo.svg`), which is
package-relative and not displayable. The server exposes a `logoUrl`
resolve field that turns it into
`/public-assets/{workspaceId}/{applicationId}/{logo}`, but on the front
end:
- `APPLICATION_FRAGMENT` and `FIND_MANY_APPLICATIONS` never selected
`Application.logoUrl`.
- So the only source of a usable logo url was
`currentWorkspace.installedApplications`, which is fetched by
`GetCurrentUser` at bootstrap. Nothing refreshed it after
`installApplication`, so a freshly installed app was absent from that
list.
- `useApplicationChipData` then fell through to
`fallbackApplicationData`, which callers populated with the raw `logo`
path. `getAbsoluteImageUrl('public/logo.svg')` yields
`{serverUrl}/public/logo.svg`, which 404s, so the avatar rendered as a
letter placeholder.
## Before / After
An app installed while the applications page is open, so the workspace
snapshot loaded at bootstrap does not know about it yet:
| Before | After |
|---|---|
| <img
src="https://raw.githubusercontent.com/twentyhq/twenty/e27a817fd95c5e44c1fbb64fd4fd68525daeee61/.pr-assets/app-icon-before.png"
width="480"> | <img
src="https://raw.githubusercontent.com/twentyhq/twenty/e27a817fd95c5e44c1fbb64fd4fd68525daeee61/.pr-assets/app-icon-after.png"
width="480"> |
## Changes
- Select `logoUrl` on `Application` in `APPLICATION_FRAGMENT` and
`FIND_MANY_APPLICATIONS`.
- Drop `logo` from `ApplicationDisplayData` and from the `AppChip` /
subtable fallback props, so a package-relative path can no longer reach
an `img` src. Call sites that already passed a url under `logo` now pass
`logoUrl`.
- `SettingsApplicationDetails` and `SettingsApplicationsTable` pass the
application's own `logoUrl`.
- On install, add the returned application to
`currentWorkspace.installedApplications` instead of reloading the
current user, so the chips that resolve by `applicationId` only (nav
menu items, object/field tables, tool rows, workflow nodes) pick it up.
- Stop exposing `logo` on the `Application` GraphQL type: nothing
selects it anymore, and having both `logo` (package-relative path) and
`logoUrl` (display url) was the source of the bug. The column is still
read server-side to build `logoUrl`.
- Regenerated `generated-metadata/graphql.ts`.
## Verification
Ran the stack locally against a seeded workspace with an installed app
whose logo lives at `public/logo.png`:
- `findManyApplications` returns a `logoUrl` under `/public-assets/...`,
and that url serves `200 image/png`.
- Reproduced the bug and the fix in the browser with the scenario shown
above (screenshots taken on the base commit and on this branch).
- `npx nx typecheck twenty-front`, `npx nx typecheck twenty-server`,
`npx nx lint:diff-with-main` on both, and the application settings jest
suites pass.
---
_Generated by [Claude
Code](https://claude.ai/code/session_01N8r4z2dZ553nAnCNe7GxMH)_
[Review in
cubic](https://cubic.dev/pr/twentyhq/twenty/pull/23411?utm_source=github)
|
||
|
Félix Malfait
|
4f31265927 |
Fix 1px gap above the record table header (#23441)
## Problem A transparent 1px slit shows up between the view bar and the table header row, letting the scrolled records show through above the column names. The record table header is `position: sticky; top: 0` inside the table's scroll container. On fractional device pixel ratios (scaled displays, browser zoom) the compositor can land the sticky header half a device pixel below the top edge of the scroll container, so its topmost device pixel row is painted with the scrolled content behind it instead of the header background. ## Repro Reproduced locally on `/objects/companies` with `deviceScaleFactor` 1.25, 1.75 and 2.25 — the slit appears at specific vertical scroll offsets (e.g. `scrollTop` 47 at DPR 1.75), and never at integer ratios. Before (DPR 1.75, `scrollTop` 47) — the row underneath bleeds through above "Name": <img width="960" alt="before" src="https://github.com/user-attachments/assets/00000000-0000-0000-0000-000000000000"> ## Fix Extend the header background 1px upwards with a `box-shadow` on the sticky container, so whatever half-pixel the compositor exposes is always covered. The shadow is painted as part of the sticky layer, so it follows the header wherever it lands. Nothing changes visually otherwise: when the table is scrolled to the top the shadow sits above the scroll container's padding box and is clipped away. ## Verification Scripted pixel scan of the top device-pixel row of the header, over scroll offsets 1-60 at DPR 1.25 / 1.5 / 1.75 / 2.25 / 2.5: | | before | after | |---|---|---| | DPR 1.25 | 3 offsets with a visible slit | 0 | | DPR 1.5 | 0 | 0 | | DPR 1.75 | 2 | 0 | | DPR 2.25 | 3 | 0 | | DPR 2.5 | 0 | 0 | Also checked at rest (`scrollTop` 0) and while scrolled at DPR 1 and 2 that no extra line appears above the header. `oxlint`, `oxfmt` and `nx typecheck twenty-front` pass. --- _Generated by [Claude Code](https://claude.ai/code/session_014gaDhmeDSNjdBeRRepKPAr)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23441?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. --> |
||
|
Raphaël Bosi
|
9509c737e0 |
Replace the onboarding AI chat feature flag with an environment variable (#23439)
Follow-up to #23199. The AI-chat onboarding is an instance-level rollout decision, not a per-workspace experiment, so `IS_ONBOARDING_AI_CHAT_ENABLED` becomes an instance config variable (default `false`, editable from the admin panel) exposed to the frontend through `ClientConfig`. The workspace feature flag is deleted; leftover `featureFlag` rows are inert since the column is plain text. `IS_WORKSPACE_COMPANY_ENRICHMENT_ENABLED` is removed as redundant: the PDL client already skips everything when no API key is set. Enrichment now runs when the AI chat is on and `PEOPLE_DATA_LABS_API_KEY` is configured. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23439?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. --> |
||
|
Félix Malfait
|
884f470982 |
Remove grey corners around navigation menu items on mobile (#23425)
On mobile, folder items in the navigation drawer were wrapped in a faint grey rounded box, showing up as small grey corners around the item. It was not part of any design. ## Cause `NavigationDrawerItemsCollapsableContainer` renders each folder group inside a framer-motion div and animates its chrome through the `animate` object: - collapsed group: `border: '1px solid <2% black>'`, `borderRadius: md`, `backgroundColor: <2% black>` - expanded: `border: 'none'`, `backgroundColor: 'transparent'` `none` is not an animatable value for framer-motion, so once the collapsed border had been applied it was never cleared. `borderRadius` was never part of the expanded target at all, so it stuck too. The inline style on the group container ended up as: ``` width: auto; background-color: transparent; border: 1px solid color(display-p3 0 0 0 / 0.02); border-radius: var(--t-border-radius-md); ``` The drawer starts collapsed on mobile (`isNavigationDrawerExpandedState` defaults to `!isMobile`) and is expanded when the user opens it, so every folder group passed through the collapsed state and kept the hairline box. On desktop the drawer starts expanded, which is why it normally does not show there — but collapsing and re-expanding the sidebar reproduced the exact same leftover. Only folders were affected: the group chrome is applied when `isGroup` is true, which requires more than one folder in the section. ## Fix The group background, border and radius now live in the styled component and are driven by an `isCollapsedGroup` prop, with a CSS transition on the background. framer-motion only animates the width, which it handles correctly. ## Verification Ran the app locally against a seeded workspace with three folders, at 393px width and at 1280px. - Mobile: folder rows no longer carry a border or radius; the group container computes to `border: 0px none`, `border-radius: 0px`, transparent background - Desktop expanded: unchanged, no chrome - Desktop collapsed: group pill still renders as before (1px hairline, 16px radius, 2% black background, 24px wide) - Desktop collapse then re-expand: chrome is now cleared instead of sticking Lint, format and typecheck pass on the changed file. --- _Generated by [Claude Code](https://claude.ai/code/session_018wtVx6vj3ZbHT3vijBLwMW)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23425?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. --> |
||
|
nitin
|
7b81d9ab83 |
Fix call-recorder REC badge rendering as empty boxes (#23415)
## What was wrong The bot camera image draws a "REC" pill on top of the workspace logo. The label used an SVG `<text>` element, and sharp resolves SVG text through the host's fonts. The runtimes that execute app logic functions ship no fonts, so every character fell back to an empty box: the badge showed "▯▯▯" instead of "REC" in real meetings. It looked fine locally because dev machines have fonts. ## The fix Draw the label as vector outlines instead of text. "REC" is outlined once from Inter SemiBold and stored as an SVG path constant, so the badge renders the same on any host with no font lookup. The pill width is derived from its contents instead of hardcoded, and tests fail if `<text>` or `font-family` ever comes back. <img width="2120" height="1191" alt="CleanShot 2026-07-28 at 19 16 46" src="https://github.com/user-attachments/assets/c5fa0958-35ba-48da-be9c-a6af81ec2fa0" /> 1 -- the bug on prod 2 -- how it looks when its not bugged on prod 3 -- this branches changes <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23415?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. --> |
||
|
Paul Rastoin
|
1fb1232a17 |
Message campaign backfill method sort view field (#23433)
<!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23433?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. --> |
||
|
Charles Bochet
|
8211206187 |
ci(pr-review): single PR review dispatcher (#23418)
rm |
||
|
github-actions[bot]
|
8e5969ea55 |
i18n - translations (#23432)
Created by Github action <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23432?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: github-actions <github-actions@twenty.com> |
||
|
Raphaël Bosi
|
f15fabb5d9 |
Enrich workspace company via People Data Labs during onboarding (#23199)
https://github.com/user-attachments/assets/fb9001c4-195d-4735-898b-07ccbab01677 During onboarding, the workspace creator's work-email domain is enriched through People Data Labs and stored client-side. The stacked workspace-setup PR folds it into the invisible prompt that kicks off the setup chat, so the assistant knows the company from its first reply. - New `enrichWorkspaceCompany` mutation: throttled, creator-only, work domains only. Off by default: requires the `IS_WORKSPACE_COMPANY_ENRICHMENT_ENABLED` instance config variable (default false), a `PEOPLE_DATA_LABS_API_KEY`, and the `IS_ONBOARDING_AI_CHAT_ENABLED` workspace feature flag (the enrichment only feeds the AI-chat workspace setup). Every attempt past the throttle is recorded per workspace in a `keyValuePair`. - The frontend fetches once during onboarding and stores a matched result in localStorage. This PR does not deliver it to the model: the hidden-message plumbing it adds (`isHidden` on `agentMessage`, excluded from the chat UI, thread ranking and the admin transcript, included in the model conversation) is what the stacked workspace-setup PR uses to send the context and the setup prompt as one invisible first message. - The PDL wire protocol (base URL, wire types, envelope parsing, error extraction) is kept as a small self-contained copy inside the server `company-enrichment` module. The standalone people-data-labs app keeps its own copy; the two are intentionally not shared, since the app and the core-engine usage are expected to evolve independently. - `WorkspaceCompanyEnrichment` lives in `twenty-shared/workspace` so server and front share one shape. ## Flow ```mermaid flowchart LR effect[Onboarding effect] -- enrichWorkspaceCompany --> checks{creator + work domain?} checks -- no --> unavailable[unavailable] checks -- yes --> throttle{throttle 10/h/workspace} throttle -- limited --> transient[transientError] throttle -- ok --> pdl[PDL GET /company/enrich] pdl --> log[(keyValuePair attempt log)] pdl --> matched[matched] matched --> storage[(localStorage)] storage -- consumed by the stacked workspace-setup PR --> kickoff[hidden kickoff prompt] ``` 1. **Onboarding effect** — mounted app-wide, fires once per session while onboarding is in progress (before workspace activation), guarded by a sessionStorage attempt flag and the cached value. 2. **enrichWorkspaceCompany** — metadata-schema mutation returning a typed `WorkspaceCompanyEnrichmentResult` (`outcome` enum `matched`/`unavailable`/`transientError` + `enrichment` JSON). 3. **Creator + work domain checks** — only the workspace's earliest user, only non-consumer email domains, only when the config flag, API key and `IS_ONBOARDING_AI_CHAT_ENABLED` workspace flag are all on; anything else returns `unavailable` without consuming throttle quota. 4. **Throttle** — token bucket, 10 requests/hour per workspace, the sole cost bound on PDL calls; when limited the mutation returns `transientError` instead of surfacing an error. 5. **PDL call** — `GET /v5/company/enrich` with `website` + `min_likelihood` per the PDL spec; body-level statuses win over HTTP ones, 408/429/5xx map to `transientError`, other failures to `unavailable`. Every attempt past the throttle is recorded (`domain`, the pre-collapse PDL `outcome`, `httpStatus`/`message` when present, `attemptedAt`) in a workspace-scoped `keyValuePair`. 6. **matched** — the PDL payload is mapped to `WorkspaceCompanyEnrichment` through the same sanitizer as client input (all fields length-capped and control-character-stripped; summary 600 chars, 8 tags max) and returned. 7. **localStorage** — the frontend stores only a matched enrichment and never refetches it, making it the only cache; cleared on sign-out. Non-matched outcomes are not persisted; a sessionStorage flag caps retries at one attempt per browser session. 8. **Delivery** — out of scope here. The stacked workspace-setup PR reads the stored enrichment and combines it with the data-model proposal prompt into a single hidden `USER` message when the setup chat starts; it is never injected into the system prompt. Reviewer notes: sending the creator's email domain to a third party at signup is not yet disclosed in onboarding copy. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23199?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. --> |
||
|
Etienne
|
902bc6db63 |
fix(ai-node) - scope AI agent node database tools to explicitly granted objects (#23400)
## Context An AI agent node scoped to a single object was still loading CRUD tools for the whole workspace, inflating every run's prompt to ~200k tokens (~110k on a standard seed workspace: 146 tools across 19 objects, 18 of them system objects). Two mechanisms caused this: the roles permissions cache force-grants every system object to every role (`isSystem ? true`), and blanket role flags (`canReadAllObjectRecords`, ...) grant all remaining objects. The per-object rows written by the agent Permissions tab were additive on top of that, so scoping an agent had almost no effect on its tool payload. ## What **Backend: explicit grants only for the agent node** - New opt-in flag `requireExplicitObjectGrants` on `ToolProviderContext`, set only by the workflow agent executor. - With the flag, `DatabaseToolProvider` generates CRUD tools exclusively from the role's explicit `objectPermission` rows: no row means no tools, and each verb gate reads the row directly (`canReadObjectRecords` for find tools, `canUpdateObjectRecords` for create/update/upsert, `canSoftDeleteObjectRecords` for delete). A verb left null is not granted; composed defaults and the system force-grant can no longer leak through. Composed permissions are still used for `restrictedFields`. - Explicit rows are read from the `flatObjectPermissionMaps` workspace cache key, fetched in the same `getOrRecompute` call as `rolesPermissions`: no extra query. - Without the flag (chat, MCP, tool index, workspace stats), behavior is unchanged: composed permissions, verified live (`getToolIndex` for an Admin returns the same 245 CRUD tools as before). - Removed the `CANNOT_ADD_OBJECT_PERMISSION_ON_SYSTEM_OBJECT` guard on `upsertObjectPermissions` so system objects can be granted explicitly. **Frontend: grant system objects from the agent Permissions tab** - The objects picker in the workflow agent side panel ends with a new "System objects" submenu listing all active system objects; picking one opens the same CRUD grant flow as regular objects. - Permissions granted on system objects now resolve their labels in the existing permission list and can be deleted (both previously looked up non-system objects only, which would have hidden such grants). Result: an agent granted one object ships ~10 tools instead of 146, cutting the prompt from ~110k tokens to a few thousand and the per-run cost accordingly. ## Notes - Removing the system-object guard affects the whole upsert path: user roles can also receive explicit system object rows via the API. A `canRead: false` row on a system object now takes effect at the query layer for that role. - The agent role is resolved as the first role of the permission config, matching `getObjectsPermissionsFromRolePermissionConfig` (multi-role is not supported yet). ## Tests - `database-tool.provider.spec.ts`: three new cases for the flag (object without a row emits nothing, partial row emits only granted verbs, absent flag keeps composed behavior even with zero rows, which guards the chat regression). - `object-permission.service.spec.ts`: the system-object case now asserts a successful upsert. - Integration: dropped the failing "system object" upsert case and its snapshot, added a successful system object upsert case. Both suites pass against a live server. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23400?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. --> |
||
|
Etienne
|
dfea3af778 |
fix(ai-chat): enrich zero-output stream captures and keep client-error exceptions out of Sentry (#23426)
## What & why Two related fixes that clean up Sentry reporting for the AI chat flow. ### 1. Enriched zero-output stream captures The AI chat stream's rejection handler previously skipped only `AbortError` and captured everything else to Sentry as-is. Two problems: - The SDK's bare `NoOutputGeneratedError` carries no troubleshooting context, so the Sentry issues were unactionable (no model, provider, workspace, or conversation size). - Expected interruptions (user abort, `STREAM_INTERRUPTED`) still generated noise. The rejection handler now handles three cases inline: - `AbortError` and `STREAM_INTERRUPTED` are expected interruptions and are not captured. - `NoOutputGeneratedError` is replaced with a single error whose message carries the full context as plain JSON: model, provider, workspace, thread, stream, turn, message count, conversation size, elapsed time, and the underlying stream error - recorded via a new `onError` handler, which also keeps stream-level errors visible in the worker logs. - Anything else is captured unchanged. The stable message prefix and single capture site keep zero-output events grouped separately from raw provider errors in Sentry. ### 2. Keep client-error domain exceptions out of Sentry `BILLING_CREDITS_EXHAUSTED` (a 402, i.e. an expected "user out of credits" condition) was landing in Sentry. Root cause: `CustomException` carries no HTTP status, so the worker/BullMQ path hands the raw exception to `shouldCaptureException`, which can't tell a 4xx client error from a 5xx server error and captures everything. The GraphQL/REST edges convert exceptions first, but background jobs bypass those converters. Fix, mirroring how `HttpException.getStatus()` already works: - `CustomException` gains an intrinsic `statusCode`. - `shouldCaptureException` skips a `CustomException` whose `statusCode < 500`, as a branch symmetric to the existing `HttpException` check. This covers every path, including the worker. - `BillingException` populates `statusCode` from the existing `getBillingExceptionStatusCode` mapping, so credits-exhausted (402) stays out of Sentry while the 500-mapped billing codes are still captured. Exceptions that don't set `statusCode` default to undefined and are captured exactly as before, so other domains are unaffected until they opt in. ## Tests - ai-chat unit suite passes (13 suites, 76 tests). - Existing billing exception handler tests pass. - `typecheck` passes. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23426?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. --> |
||
|
Paul Rastoin
|
ceb699c43f |
Message campaign backfill search field metadata (#23428)
<!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23428?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. --> |
||
|
Raphaël Bosi
|
b8e2a6e910 |
Unify remote element style declarations (#23263)
Front components run in a Web Worker with a fake DOM. Until now the worker had a hand-rolled `style` object for remote elements and the host had its own separate CSS-string parser: two implementations of the same parsing that kept drifting apart (several review rounds fixed edge cases in one copy but not the other). What changed: - One shared `createStyleProxy` now backs `element.style` in the worker, and one shared `parseCssDeclarations` feeds both the worker proxy and the host's `parseCssString`. Most of the diff is existing logic split out of `installStylePropertyOnRemoteElements` into small single-purpose utils (`splitCssDeclarations`, `stripImportantPriorityFromCssValue`, `normalizeCssPropertyName`, `formatCssValue`, ...), not new behavior. - `!important` is stripped from values instead of tracked. Nothing ever read priorities back, and the host applies styles through React inline styles, which cannot express `!important`. Rendering note: `color: red !important` used to reach React as an invalid value (property silently not applied); it now applies, without the priority. - Style writes flush to the host synchronously, exactly as on main. - The parser handles quotes, escapes and parentheses; CSS comments inside hand-written `cssText` are not supported. This shared proxy is also the base for the worker `getComputedStyle` stub in the geometry PR. Second of three PRs splitting the geometry mirror work. |
||
|
Raphaël Bosi
|
64001591f2 |
Fix numeric controlled input values in front components (#23421)
A front component rendering a numeric input never showed its value
because the caret-preserving path only accepted strings:
- controlled: `<input type="number" value={42}>` was rejected by the
value sync guard, so nothing was written to the host element
- uncontrolled: `defaultValue={42}` was dropped from the initial value
seeding
Numeric values are now stringified in both places. Also adds a test
asserting `createCaretPreservingElement` forwards its ref to the
rendered element.
The controlled case and the ref test were flagged by cubic on #23264
|
||
|
Thomas Trompette
|
4c904aa44c |
fix(workflow): keep Limit and Offset when changing the Search Records object (#23423)
Fixes the second bug reported in #23387. ## Problem In the Search Records action, changing the Object silently reset `Limit` to `1`. A user who had set `Limit = 100` and then switched object (or switched away and back) ended up with a step that returns exactly one arbitrary record, with no indication beyond a small `1` in the side panel. Reproduced on `main` against a local instance, checking the persisted draft version: ```json { "limit": 1, "offset": 0, "objectName": "person" } ``` `handleOptionClick` rebuilt the entire form as `{ objectNameSingular, limit: 1, offset: 0 }`, discarding whatever the user had entered. `1` is the server-side default for a newly created `FIND_RECORDS` step, so this was effectively a revert-to-creation-default on every object change. ## Change Carry `limit` and `offset` over instead of hardcoding them. `filter` and `orderBy` are still dropped by omission, which is correct: they reference fields of the previous object. ## Test Added `KeepsLimitAndOffsetWhenObjectChanges` to the existing story file. It switches the object and asserts `onActionUpdate` receives `{ objectName: 'company', limit: 100, offset: 20 }`. Confirmed the test is not vacuous: reverting the fix makes it fail with exactly the reported symptom (`limit: 100 -> 1`, `offset: 20 -> 0`). ## Not addressed here The headline bug in #23387 (filters made only of value-less operators never persisting) does not reproduce on `main`. I ran the reporter's steps with `Is in past` OR `Is today (UTC)` and both rules plus the `OR` group were written to the draft version correctly. Persistence hangs off `useUpsertRecordFilter`, which fires the advanced-filter `onUpdate` on every upsert, so operand changes save just as value changes do. The reporter is on ~v2.18.x and did not re-test on a recent release. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23423?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. --> |
||
|
Thomas Trompette
|
11447bd96f |
fix: make add-select-option work on record detail pages (#23420)
Fixes #23339 Follow-up to #23410, which fixed the neighbouring issue (#23341) for users *without* the `DATA_MODEL` permission. ## Problem In #23339 the reporter added a multiselect field to Person and then found the inline "create option" prompt unresponsive. They clearly have `DATA_MODEL` permission, since they just created the field, so the permission check isn't what's blocking them. The blocker is the *other* precondition. Both hooks read the object name from the router: ```ts const { objectNamePlural } = useParams(); ``` `objectNamePlural` only exists on record index routes (`/objects/:objectNamePlural`). Record **detail** pages are `/object/:objectNameSingular/:objectRecordId`, so on a record page the param is `undefined` and: - `useCanAddSelectOption` returns false via `isNonEmptyString(objectNamePlural)` - `useAddSelectOption` bails out at `if (!fieldName || !objectNamePlural) return;` So the action was dead on record pages for **every** user, admins included, and the navigation target it needed was never reachable from there. ## Fix Resolve the field and its object from `fieldMetadataId`, which `FieldDefinition` already carries, instead of reading the object name off the URL: ```ts const { fieldMetadataItem, objectMetadataItem } = useFieldMetadataItemById(fieldMetadataId); ``` This drops the route dependency entirely, so the action behaves the same wherever the field is rendered, and `canAddSelectOption` now reflects only the real permission check. It also lets both hooks take a single `fieldMetadataId` argument: `fieldMetadataItem.name` is the same value the callers were previously passing as `fieldName`, so that parameter is no longer needed. Resolving both values from one id means the guard and the action can't disagree about which field they're describing. `useFieldMetadataItemById` is used rather than `useFieldMetadataItemByIdOrThrow` because a lookup miss should disable the prompt, not crash the field input. ## Reproduction On the code the reporter was running (immediately before #23410), as an **admin** with full `DATA_MODEL`, on a company record page, typing a value matching no option: - `Add "…" to options` renders - clicking it does nothing — URL unchanged, no navigation - pressing <kbd>Enter</kbd> does nothing either which matches #23339 exactly, including the note about the Enter keypress. After #23410 the same root cause shows up differently: the prompt is no longer rendered at all on record pages, since the guard it's now gated on is false there. Still broken, just silent. ## Testing Verified manually on a local instance, swapping only these files between three states and re-running the identical steps on the same cell. | code state | user | route | result | |---|---|---|---| | before #23410 | Admin | `/object/company/:id` | prompt shown, click and Enter both do nothing | | current main | Admin | `/object/company/:id` | prompt not shown, action unreachable | | **this PR** | Admin | `/object/company/:id` | prompt shown, navigates to `/settings/objects/companies/workPolicy?newOption=…` | | **this PR** | Admin | `/objects/tasks` (`Status`, single select) | still works, navigates to `/settings/objects/tasks/status?newOption=…` | | **this PR** | Member (no `DATA_MODEL`) | `/object/company/:id` | prompt not shown | The settings form opens with the typed value prefilled alongside the existing options, so the end-to-end flow works from a record page for the first time. The Member row confirms #23341 stays fixed: dropping the route dependency doesn't weaken the permission gate. The single-select row covers `SelectFieldInput`, which takes the same change. `nx lint:diff-with-main twenty-front` and `nx typecheck twenty-front` both pass. |
||
|
Paul Rastoin
|
7b46c3ed31 |
use legacy validate build and run for standard metadatas (#23419)
<!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23419?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. --> |
||
|
Abdul Rahman
|
6c66d4c862 |
fix(ai-agent): use a non-workflow base system prompt for programmatic agent runs (#23394)
`AgentAsyncExecutorService` hardcoded `WORKFLOW_SYSTEM_PROMPTS.BASE`, so every caller was told "You are executing as part of a workflow automation" and "your output may be used by downstream workflow nodes". That is only true for the workflow AI-agent action. The `runAgent` API (used by apps such as the call recorder) and agent evaluations got the same framing, which does not describe how they run or where their output goes. The executor no longer asserts its own execution context: `executeAgent` now takes a required `baseSystemPrompt` and each caller supplies its own. - Workflow AI-agent action passes `WORKFLOW_SYSTEM_PROMPTS.BASE` (unchanged behavior) - `runAgent` and evaluations pass the new `AGENT_RUN_BASE_SYSTEM_PROMPT` The param is required rather than defaulted so every call site states its context and no future caller silently inherits the wrong one. Prompt constants are also split one export per file, with the shared tool-usage guidance extracted into `TOOL_USAGE_STRATEGY` so both bases compose it. No GraphQL schema, SDK, or database changes. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23394?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. --> |
||
|
Félix Malfait
|
3f0236b590 |
fix(page-layout): let the column surface win over the solo presentation (#23412)
## Why In the side panel and on mobile, a tab holding a single widget renders with no gutter at all: the field list sits flush against the panel border. Regression from #23109. `getWidgetCardVariant` checked the derived presentation before the surface: ```ts if (presentation === 'solo') return 'solo'; const isSideColumnContext = isInPinnedTab || isMobile || isInSidePanel; ``` So a single-widget tab resolved to `'solo'` even in the side panel or on mobile, and `'solo'` has no branch in `WidgetCard`'s padding switch, so it falls through to `0`. The same widget used to match `variant === 'side-column' && !isEditable` and get `spacing[3]` (12px). The pinned left panel escaped this only because `PageLayoutLeftPanel` hardcodes `presentation: 'stack'` — the rule was already there ("the pinned left panel is always a column, a surface rule not a widget rule"), just applied at one call site instead of being the rule. ## Why only the Home tab looks broken Every widget that used to live on a `CANVAS` tab carries its own gutter, so losing the card padding costs them nothing: | Widget | Own horizontal padding | |---|---| | Timeline | `spacing[6]` | | Notes | `spacing[6]` | | Files | `spacing[6]` | | Tasks | `spacing[6]` | | **Fields** | **none** | `Fields` was the only widget on a `VERTICAL_LIST` tab, so it was the only one relying on the card for its gutter, and the only one that ends up flush. ## What Resolve the surface first: a column surface (pinned panel, side panel, mobile) is always a column of cards, whatever the tab presentation is. Solo stays a main-tab-area concept. Header visibility is untouched: `showHeader` keys off `presentation`, not the variant, so a solo tab still shows no bare title row. The `Fields` widget does not regain the header it lost in #23109. ## Measured Side panel, custom object whose Home tab holds a single Fields widget (1600x1000, panel at x=1200): | | Card padding | First label x | |---|---|---| | main | `0px` | 1221 | | this PR | `12px` | 1233 | 12px restored, matching what the pinned left panel gives the same widget. ## Trade-off worth a second opinion In the side panel and on mobile, the activity widgets now resolve to `'side-column'` instead of `'solo'`, so they pick up the card's 12px on top of their own 24px, i.e. 36px instead of 24px. Nothing overlaps or clips, but it is a visible change on those tabs. If you would rather keep them at 24px, the follow-up is to drop the intrinsic `spacing[6]` from the activity cards and let the surface own the gutter everywhere. ## Test plan - `getWidgetCardVariant` tests extended: `'side-column'` now wins over `'solo'` for each of `isInPinnedTab` / `isMobile` / `isInSidePanel`. 13 tests pass. - 88 suites / 620 tests across `page-layout/widgets` pass. - `lint:diff-with-main twenty-front` clean. - Verified against a local stack: side panel on a single-widget Home tab, before and after. |
||
|
Thomas Trompette
|
38e9d231bc |
fix: hide add-select-option prompt for users without data model permission (#23410)
Fixes #23341 ## Problem A user whose role lacks the `DATA_MODEL` permission flag still saw the `Add "…" to options` prompt when typing a value that matched no option in a multiselect. Clicking it did nothing. `MultiSelectInput` renders `AddSelectOptionMenuItem` based purely on whether the callback exists: ```tsx {onAddSelectOption && searchFilter && filteredOptionsInDropDown.length === 0 && ( ``` `MultiSelectFieldInput` always passed a callback, and did the permission check *inside* it: ```tsx const handleAddSelectOption = (optionName: string) => { if (!canAddSelectOption) { return; } addSelectOption(optionName); }; ``` So the guard suppressed the click but not the render, which is exactly the reported symptom: the prompt is visible and inert. ## Fix Gate at the prop instead of inside the handler, so the menu item is never rendered when the action is unavailable: ```tsx onAddSelectOption={canAddSelectOption ? addSelectOption : undefined} ``` The wrapper is now redundant and removed; `addSelectOption` already has the matching `(optionName: string) => void` signature. `SelectFieldInput` had the byte-identical bug (`SelectInput` gates on `onAddSelectOption &&` the same way), so it gets the same change. ## Note on scope `useCanAddSelectOption` requires `objectNamePlural` from the route in addition to the permission flag: ```ts const canAddSelectOption = userHasPermissionToEditDataModel && isNonEmptyString(fieldName) && isNonEmptyString(objectNamePlural); ``` Record *detail* pages (`/object/:objectNameSingular/:recordId`) have no `objectNamePlural`, so the prompt was dead there for **every** user, admins included. This change hides it in that case too, which is the correct behavior since the click could never have worked. ## Testing Verified manually against a local instance, toggling the patch in and out on the same cell so before/after is directly comparable. Company `Work Policy` (multiselect) in the Companies table view, typing a string that matches no option: | user | route | before | after | |---|---|---|---| | Member (no `DATA_MODEL`) | `/objects/companies` | prompt shown, click does nothing | prompt hidden | | Admin | `/objects/companies` | prompt shown, click works | prompt shown, click works (navigates to `/settings/objects/companies/workPolicy?newOption=…`) | | Admin | `/object/company/:id` | prompt shown, click does nothing | prompt hidden | `nx lint:diff-with-main twenty-front` and `nx typecheck twenty-front` both pass. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23410?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. --> |
||
|
Félix Malfait
|
1064ae835b |
Remove ugly page card top-left rounded corner on mobile (#23414)
On mobile the main page card kept the desktop styling that makes it look attached to the navigation drawer: a rounded top-left corner (`border-radius: lg 0 0 0`) and a 1px ring box-shadow. Since the drawer isn't rendered inline on mobile, the card is full-bleed and the rounded corner plus hairline border look out of place. Changes in `PageCardLayout`: - Card: `border-radius: 0` and `box-shadow: none` below `MOBILE_VIEWPORT`, including the `.dark` override which would otherwise win on specificity - Wrapper: drop the `-3px` margin-left / `4px` padding-left that reserved the drawer seam Verified in the running app at 390px width on both the record show page and the record index, in light and dark mode: no full-width element carries a shadow or top-left radius anymore. --- _Generated by [Claude Code](https://claude.ai/code/session_01N6LfZg7JZ2FiYiJ9QcNucj)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23414?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. --> |
||
|
github-actions[bot]
|
897d29b603 |
i18n - translations (#23417)
Created by Github action --------- Co-authored-by: github-actions <github-actions@twenty.com> |
||
|
neo773
|
1e58c3073c |
Feat/email composer improvements (#23188)
- Move composer to dedicated page - Add test email option - Auto saved as draft can be revisited from `objects/messageCampaigns` later - Campaign stats component https://github.com/user-attachments/assets/9e523116-e79b-496d-9c9d-3887e0c9213f <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23188?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Félix Malfait <felix.malfait@gmail.com> |
||
|
github-actions[bot]
|
30bbf4149a |
i18n - translations (#23409)
Created by Github action <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23409?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: github-actions <github-actions@twenty.com> |
||
|
Raphaël Bosi
|
46cf4cebd1 |
Guard stale chunk auto-reload against loops (#23362)
AppErrorBoundary auto-reloads on stale chunk errors, but if the server keeps returning stale assets (cached index.html, bad deploy) the reload lands back on the same failure and loops forever with no user interaction. Follow-up to #23359, which broadens the errors that trigger this reload. - Reload at most once per 60s per tab (sessionStorage timestamp); within the cooldown the error fallback shows instead, with its manual Reload button still unguarded. - The auto-reload waits for the Sentry capture (`captureException` + `flush`), bounded by a 2s timeout so a broken network cannot stall the reload. |
||
|
Raphaël Bosi
|
2bd1ece952 |
Redesign the external link popup for front components (#23404)
<img width="3840" height="1866" alt="CleanShot 2026-07-28 at 11 52 15@2x" src="https://github.com/user-attachments/assets/de081951-6b1f-4194-8452-8395a90f3746" /> Applies the Figma design to the confirmation popup shown before a front component navigates to an external site. New copy: "Open external link?", the destination as a pill, "Always allow links to this domain", and "Open link" as the confirm button. The popup is now its own component built on `ModalStatefulWrapper` because `ConfirmationModal`'s fixed spacing cannot produce the design's layout. The "always allow" checkbox stays checked by default, as before. The pill is a non-interactive span rather than a `RoundedLink`, so the destination cannot be opened outside the confirm flow, and it ellipsizes the path so the domain stays readable. |
||
|
Etienne
|
74260a161d |
fix(ai): stop double-counting cache-creation tokens in reported token totals (#23405)
## Context Under AI SDK v6 usage normalization, `usage.inputTokens` is the **full prompt**: fresh (noCache) + cache-read + cache-creation tokens. Our `totalTokens` formulas still added `cacheCreationTokens` (extracted from provider metadata) on top of `inputTokens` — a leftover from the pre-v6 SDK generation, where flat `inputTokens` excluded cache tokens. The v6 upgrade changed the semantics under the formula's feet, so every Claude run using prompt caching reported a `totalTokens` inflated by exactly `cacheCreationTokens`. ## Evidence, traced through AI SDK source **1. The Anthropic provider folds cache tokens into `inputTokens`.** The raw Anthropic API reports `input_tokens` *excluding* cache tokens; the provider sums all three components — [`convertAnthropicMessagesUsage`, `@ai-sdk/anthropic@3.0.84`](https://github.com/vercel/ai/blob/%40ai-sdk/anthropic%403.0.84/packages/anthropic/src/convert-anthropic-messages-usage.ts): ```ts inputTokens: { total: inputTokens + cacheCreationTokens + cacheReadTokens, noCache: inputTokens, cacheRead: cacheReadTokens, cacheWrite: cacheCreationTokens, } ``` **2. ai core surfaces that total as the app-visible `usage.inputTokens`** — [`asLanguageModelUsage`, `ai@6.0.97`](https://github.com/vercel/ai/blob/ai%406.0.97/packages/ai/src/types/usage.ts): ```ts inputTokens: usage.inputTokens.total, ... totalTokens: addTokenCounts(usage.inputTokens.total, usage.outputTokens.total), ``` So the SDK's own `totalTokens` is already "full prompt (incl. cache read + creation) + output". **3. The value we were adding on top is the same one already inside `inputTokens`.** The provider also exposes the raw API field in metadata (`@ai-sdk/anthropic` dist): ```ts const anthropicMetadata = { usage: response.usage, cacheCreationInputTokens: response.usage.cache_creation_input_tokens ?? null, ... ``` `extract-cache-creation-tokens.util.ts` reads exactly `providerMetadata.anthropic.cacheCreationInputTokens` — the same `cache_creation_input_tokens` that step 1 already folded into `inputTokens.total`. Adding it again counts it twice. **Worked example** (matches the new pinning test): API returns `input_tokens: 400, cache_read_input_tokens: 600, cache_creation_input_tokens: 200, output_tokens: 500` → app sees `usage.inputTokens = 1200`, `providerMetadata.anthropic.cacheCreationInputTokens = 200` → old formula reported `1200 + 500 + 200 = 1900`; actual tokens processed: `1700`. All snippets are verbatim from the version tags in `vercel/ai` and match the installed `node_modules` dists. ## Provider independence `inputTokens + outputTokens` is correct for every provider Twenty routes through, not just Anthropic: - The v3 provider spec (`@ai-sdk/provider`) defines `inputTokens.total` as "the total number of input (prompt) tokens used", with `noCache`/`cacheRead`/`cacheWrite` as its components — and all 8 installed provider packages comply (verified in dists): `anthropic` and `amazon-bedrock` sum the components explicitly ([`convertBedrockUsage`, `@ai-sdk/amazon-bedrock@4.0.117`](https://github.com/vercel/ai/blob/%40ai-sdk/amazon-bedrock%404.0.117/packages/amazon-bedrock/src/convert-bedrock-usage.ts): `total: inputTokens + cacheReadTokens + cacheWriteTokens`); `openai`, `azure`, `google`, `mistral`, and `openai-compatible` pass through wire values that already include cached tokens; `xai` even detects which wire convention the API used and normalizes either way. - The removed `cacheCreationTokens` term was already 0 for every provider except Anthropic/Bedrock (`extract-cache-creation-tokens.util.ts` only reads those two metadata namespaces), so this PR is a strict no-op for OpenAI-style providers and only removes the double-count where it existed. Caveat: a custom `AI_PROVIDERS` entry pointing at a legacy V2-spec provider package bypasses this normalization (ai core's shim passes flat usage through verbatim); that path could misreport under any formula, and none of the built-in providers use it. ## What changed Four sites computed the inflated total: - `ai-billing.service.ts` — `quantity` on the emitted AI token usage event - `chat-execution.service.ts` — chat-turn usage event - `agent-async-executor.service.ts` — workflow-agent usage event - `build-ai-agent-step-log.util.ts` — workflow step log (display) The first three now compute `totalTokens = inputTokens + outputTokens`; the step-log util uses the SDK's `usage.totalTokens` directly (it receives the `generateText` usage object, where the field is guaranteed). The explicit sum is used where usage objects are hand-assembled or merged — e.g. the streaming path in `stream-agent-chat.job.ts` builds usage literals with no `totalTokens` field at all, so `usage.totalTokens ?? 0` would silently emit 0. Both forms are definitionally identical where the SDK object exists, since ai core computes `totalTokens` as `input + output` (see evidence above). **Impact: reported/analytics quantities only.** Billed credits (`creditsUsedMicro`) come from `computeCostBreakdown`, which already handles the cache-inclusive convention correctly and is unchanged. **Ops note:** `usageEvent.quantity` for cache-heavy workspaces steps down on deploy — dashboards trending this metric may want an annotation. Historical rows are not backfilled (per-row component fields aren't stored, so mixed-era rows can't be reliably corrected). ## How tested - Updated `build-ai-agent-step-log.util.spec.ts` expectation (155 → 150 with `cacheCreationTokens: 5` still present) - New pinning test in `ai-billing.service.spec.ts`: emitted `quantity` is 1700 (not 1900) for inclusive Anthropic usage with `cacheCreationTokens: 200` - New pinning test in `agent-async-executor.service.spec.ts`: emitted total is 150 (not 180) when steps carry `providerMetadata.anthropic.cacheCreationInputTokens` - 3 suites / 20 tests pass; oxlint, oxfmt, and `nx typecheck twenty-server` clean <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23405?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. --> |
||
|
Rashad Karanouh
|
7fe59bf42d |
feat(website): send the referring partner with a client brief (#23351)
**Pairs with #23344** (`twenty-partners` v1.4.1), which adds the `referredByPartner` relation and the Discord notification. This PR is the sender; that one is the receiver. **Merge #23344 first.** Its schema is a non-strict `z.object`, so an unknown `partnerSlug` is stripped rather than rejected — shipping this one first degrades silently (attribution dropped) rather than breaking, but there is no reason to. Until #23344 is deployed, this field goes nowhere. No dependency in the other direction and no shared files: #23344 is entirely inside `packages/twenty-apps`, this is entirely inside `packages/twenty-website`. ## What this does A visitor can reach the client brief form from two places: the marketplace listing page, or a specific partner's profile. Until now both produced an identical payload, so the partner whose page drove the lead was lost. This sends the partner's slug along with the brief when the form was opened from a profile page. #23344 resolves it to a Partner record and links it to the created Opportunity. ## How it flows `PartnerProfileCtas` links to `/partners/brief?partner=<slug>` → `page.tsx` reads and normalizes the param → prop threaded through `ClientBriefPageContent` → `ClientBriefWizard` → `buildClientBriefRequestBody`. The slug is inert context, never a form field, so the wizard reducer and `ClientBriefState` are untouched. The three CTAs on `/partners/list` (`MarketplaceHeader`, `MarketplaceMatchCard`, `MarketplaceBriefPrompt`) stay bare — a brief from the listing page has no referring partner, and the notification labels it "Marketplace listing". ## Why `normalizePartnerSlug` exists `clientBriefRequestSchema` is a `z.strictObject`. Forwarding a malformed `?partner=` value straight into the body would fail validation for the **entire request** and lose the brief — a bad trade for an attribution field the visitor never saw. So the param is normalized at the boundary: array-valued params take the first entry, and anything not matching `[a-z0-9-]{1,100}` is dropped to `undefined` rather than passed on. The charset mirrors the app's `slugify` helper, which is what produced the slugs in the first place. ## Testing 8 new cases — 6 for the normalizer (well-formed, absent, empty, bad charset, over-long, repeated param) and 2 for the schema. Suite: 456 passing, up exactly 8 from a 448 baseline. `oxlint` and `oxfmt --check` clean; `next build` compiles with no type errors. Verified in a browser rather than asserted: opening a partner profile, clicking "Submit a brief", and completing the wizard produces ```json {"firstName":"Jane","lastName":"","email":"…","companyName":"NetZero Test Co","need":"…","partnerSlug":"netzero-systems"} ``` on `POST /api/client-brief` → 200. `LocalizedLink` preserves the query string across locale prefixing (`localize-href.test.ts:20` already covers this; confirmed live on the FR route). ## Deliberately not included - **CTA-level attribution.** Which of the three listing-page CTAs was used is not tracked. That is click analytics, a different concern from partner attribution. - **Length bounds on the other brief fields.** `country`, `seatCount`, `timeline`, `budgetRange` and `companyName` remain unbounded, as they were before this PR. Worth tightening, but pre-existing and out of scope here. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23351?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. --> |
||
|
Rashad Karanouh
|
fea06bdd4b |
v1.5.1 — partners: Discord notification for client briefs + referring-partner attribution (#23344)
**Merge after #23295.** Targets `main`, but must land second: #23295 bumps `1.3.2 → 1.4.0`, and this bumps `1.4.0 → 1.5.1`. Merging this first would leave `main` at 1.5.1 and make #23295's bump conflict and regress the version. `package.json` is the only file the two branches share. App version: **v1.5.1**. ## What this does Posts a Discord notification when a client brief is submitted through the public marketplace form, and records which partner's profile page the brief came from. A visitor can reach the brief form from the marketplace listing page or from a specific partner's profile. Until now that context was lost. This adds a `referredByPartner` relation on Opportunity so the attribution is a queryable CRM fact rather than a line in a chat message. ## How it works `submitClientBrief` resolves the incoming `partnerSlug` to a Partner, sets the relation on create, then posts the embed inline. Inline rather than an `opportunity.created` database trigger, because that event cannot distinguish a brief from a TFT import — both are created by logic functions and both carry `createdBy.source === 'APPLICATION'`. A trigger would need a discriminator like "source is APPLICATION and `tftOpportunityId` is empty", which silently breaks the day a third logic function creates an Opportunity. The cost of going inline is that the Discord call sits in the visitor's request, so it uses a 3s timeout rather than the trigger path's 8s, and every failure is swallowed — a dead webhook can never turn a submitted brief into a failed one. ## Notable decisions - **Slug resolution ignores `validationStage` and `availability`**, unlike the marketplace profile query. If someone submitted a brief from a partner's page, that partner referred it, even if they go unavailable a minute later. Filtering would silently drop real attribution. - **An unresolved slug never fails the brief.** It logs a warning, leaves the relation unset, and still notifies. A brief is a sales lead; losing one over an attribution field the visitor never saw would be a bad trade. - **`referredByPartner` is separate from the existing `partner` field.** One is who sent the lead, the other is who works it. - **The Discord connector moved to `modules/shared/connector/`.** Two domains now need it, and `AGENTS.md` forbids importing logic sideways between domains. `postWebhook` gained `label` and `timeoutMs` parameters; the transport is otherwise unchanged. - Reuses the existing `DISCORD_WEBHOOK_URL` and `PARTNER_APP_FRONTEND_URL` variables — no new configuration to set on prod. ## Permissions `partner.role.ts` locks the new Opportunity field. `configure-partner-rls.ts` treats its skip-list as a closed allowlist of system columns, so an unlocked new field is reported as a discrepancy. Note that Opportunity RLS for partners is `(partnerUser IS me) OR (isListed = true)`, so on a **listed** brief any partner can read `referredByPartner` — i.e. see that a competitor referred it. Called out deliberately; happy to restrict it if that's not wanted. ## Testing 8 unit tests for the embed mapper (partner present/absent, truncation, absent optionals, no email in the payload, inline-row padding) and 4 for the schema. Full suite: 188 passing, lint clean. Verified end to end against a local workspace with a real Discord webhook. All three paths return `ok: true`; the persisted relation was confirmed via GraphQL rather than inferred from the status code: | Submission | `referredByPartner` | |---|---| | valid slug | linked to the partner | | no slug | `null`, embed reads "Marketplace listing" | | unknown slug | `null`, brief still succeeds | ## Follow-up, not in this PR `yarn rls:configure` fails before reaching its field-lock check — its retry path strips `predicateGroups` but the predicates still carry `rowLevelPermissionPredicateGroupId`, so the retry fails identically. Pre-existing and unrelated to this change (`configure-partner-rls.ts` is untouched here), but it means the script cannot currently verify the lock on a fresh workspace. The website side that sends `partnerSlug` is #23351. Until it ships, this is inert: no caller sends the field, and briefs behave exactly as before. Merge this one first — #23351 is the sender, this is the receiver. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23344?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. --> |
||
|
martmull
|
1f55234d0b |
fix(call-recorder): leave call when only recording bots remain (#23053)
## Problem Fixes [core-team-issues#2689](https://github.com/twentyhq/core-team-issues/issues/2689). `everyone_left_timeout` only fires when the bot is the sole remaining participant, and Recall counts other recording bots as participants. So when several bots share a meeting, none of them sees itself as alone. Recall does enable `bot_detection` by default, but it ships an empty `matches` list, so the name-based check can never classify anyone. The only detector that actually runs is the behavioural one, at its default 20 minute grace plus 10 minute timeout. A meeting left with only bots therefore stays open for around 30 minutes, and two Twenty bots in the same call never recognise each other at all. This happens when several workspace members are invited to the same meeting and each has the recorder preference on, or when third-party notetakers stay behind after the humans leave. ## What this does Sends a full `automatic_leave.bot_detection` block plus `silence_detection`: - **`using_participant_names`** — the configured recorder name, so co-scheduled Twenty bots recognise each other, plus a list of common notetakers. `timeout: 10`, which is Recall's enforced minimum; their example config shows `5` and the API rejects it. - **`using_participant_events`** — a participant that never speaks nor shares screen is treated as a bot. - **`silence_detection`** — Recall's documented example values (`activate_after: 1200`, `timeout: 300`). Previously unset, so it fell back to Recall's 20 + 60 minute default. Both bot detectors activate 5 minutes after the **meeting start time**, not 5 minutes after the bot joins. The bot joins early by a configurable amount, so anchoring to join time spent the grace period before the meeting existed — at a 10 minute early join, detection would have gone live 5 minutes before the meeting began. `everyone_left_timeout` is unchanged and still covers the ordinary case. Effect: | | before | after | |---|---|---| | Only bots remain | ~30 min | ~5 min after meeting start | | Someone leaves the call open after talking | ~80 min | ~25 min | ## Deferred De-duplicating bots per meeting URL, so several `callRecording`s in one meeting share a single bot instead of each spawning one. `bot_detection` is still needed for third-party bots, so this ships first. --------- Co-authored-by: ehconitin <nitinkoche03@gmail.com> |
