f663cd3c684ef0bb65a697ba7af67a366aeefa0a
6586 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Félix Malfait
|
f663cd3c68 |
Move open-record-in to object metadata and member preference (#23614)
Replaces the per-view "Open in" setting with a two-level model, following up on #23422 / #23424 and superseding the closed #23446 and #23457: - `objectMetadata.openRecordIn`: `SIDE_PANEL` | `RECORD_PAGE` | `USER_CHOICE` (default `USER_CHOICE`) - `workspaceMember.openRecordIn`: `SIDE_PANEL` | `RECORD_PAGE` (default `SIDE_PANEL`), editable in Settings > Experience The rule: records open where the member prefers, unless the object pins them, and never in a panel there is no room for (mobile always resolves to the record page). ## Why Having the setting on views, objects and members at once was heavy, and view-level resolution was fragile: a chip rendered outside a view (notes, front components, kanban cards pointing at another object) had no view to read from, which is the class of bug behind #23422. Resolution is now context-free: it needs only the object, the current member and the viewport, so chips behave identically everywhere by construction. ## Changes **Object level** - New `openRecordIn` enum column on `objectMetadata`, editable through `updateOneObject` and surfaced in Settings > Data model > Object > Layout ("Open records in": Member preference / Side Panel / Record Page) - Standard definitions pin `workflow`, `workflowVersion`, `dashboard` and `messageCampaign` to the record page (matching the previously hardcoded list) and `calendarEvent` to the side panel (it has no curated record page); everything else, including `workflowRun`, follows the member preference - Apps can set it in `defineObject()` via the object manifest **Member level** - New `openRecordIn` standard field on `workspaceMember`, persisted through the existing settings path (same as `colorScheme`) and exposed in Settings > Experience **View level (deprecated)** - `view.openRecordIn` is no longer read or written by the frontend; the "Open in" entry is gone from the view options dropdown - The column, DTO field and inputs are kept for one release for API compatibility: the output field carries a `deprecationReason`, the inputs keep accepting the value with a `Deprecated:` description (NestJS silently drops input fields that have a `deprecationReason`, which would have been a breaking change) **Upgrade (2.27)** - Fast instance command adds the `objectMetadata.openRecordIn` column defaulting to `USER_CHOICE` - Workspace command adds the `workspaceMember.openRecordIn` field - Workspace command seeds the object column from the standard definitions (any non-`USER_CHOICE` value), then lifts deliberate per-view record page choices onto objects the definitions don't pin **Debt removed** - `canOpenObjectInSidePanel` hardcoded object list and its test - `ObjectOptionsDropdownLayoutOpenInContent` and the `layoutOpenIn` dropdown wiring - `DefaultViewOpenRecordIn` - Context-store/view-based resolution in `useResolveOpenRecordIn` (now reads object metadata + member + viewport) - Front components no longer guess from the current view: an explicit side-panel call honours a pinned object and the viewport, nothing else ## Verification - Ran the three upgrade commands against a live database: column created, the pinned standard objects seeded per workspace (record page pins plus calendarEvent to side panel), member field backfilled to `SIDE_PANEL`; seed rerun is a no-op - Seed command verified on a simulated pre-upgrade workspace (index view set to record page on company): pins the standard objects plus company, idempotent on rerun - Both packages typecheck and lint clean; affected unit suites and the application sync, view creation and metadata cache integration specs pass --------- Co-authored-by: Thomas des Francs <tdesfrancs@gmail.com> |
||
|
Thomas Trompette
|
706d72e53e |
fix(front): reload record board groups when view groups change (#23637)
## Problem Fixes #23462 On a Kanban (record board) view grouped by a SELECT field, adding a new option to that field creates the column, but dragging a record into the new column silently fails (no move, no error) until a hard page reload. ## Root cause `RecordIndexLoadBaseOnContextStoreEffect` builds its load key from the view id and the calendar-week flag only: ``` `${contextStoreCurrentViewId}-${isCalendarWeekViewEnabled}` ``` The effect early-returns when `loadedViewKey === currentViewLoadKey`. When a new `ViewGroup` is created from the added SELECT option, the view id does not change, so the key is unchanged and `loadRecordIndexStates` never re-runs. The record group state (`recordGroupIdsComponentState` / `recordGroupDefinitionFamilyState`) stays stale, so the drop handler cannot resolve the new group's field value and the move no-ops. A hard reload fixes it because the view then loads with the new group present from the start. ## Fix Include a signature of `view.viewGroups` (ordered `id:position:isVisible`) in the load key so the effect re-runs `loadRecordIndexStates` whenever the view's groups change, not only when the view id changes. The calendar-week flag is kept in the key. ## Testing Verified end to end on a local instance against an Opportunities "By Stage" Kanban, with the record's stage change confirmed in the database: - **Before the fix:** add a new Stage option in-session, then drag a record into the new column. Dragging into an existing column persists the move; dragging into the newly created column does nothing (record's stage unchanged in DB). - **After the fix:** same flow, dragging a record into the newly created column moves it and persists the new stage in DB, with no reload. `nx typecheck twenty-front` and `oxlint` pass. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23637?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. --> |
||
|
avonian
|
d02332834b |
Fix record title cell reopening on every page refresh (#23551)
## What `location.state.isNewRecord` is set when navigating to a freshly created record so the title cell opens for naming. But router state lives in **browser history state, which survives page refreshes** — so every refresh of that record's page re-opens the title cell with an empty draft and a blinking cursor. Strip the flag after its one intended consumption in `PageChangeEffect` (react-router keeps user state under `history.state.usr`). ## Repro (on current main, any view set to open records in record page — or on mobile) 1. Create a record from a table; you land on its record page with the title focused (intended). 2. Name it, click away, then refresh the page. 3. The title cell re-opens, empty, focused — on every refresh, forever. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23551?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: bosiraphael <raphael.bosi@gmail.com> |
||
|
github-actions[bot]
|
17ddff8470 |
i18n - translations (#23620)
Created by Github action Co-authored-by: github-actions <github-actions@twenty.com> |
||
|
Thomas Trompette
|
3ed11054a0 |
Keep leading + when filtering phones by calling code (#23546)
Fixes #23528 Filtering a PHONES field with `CONTAINS` / `DOES_NOT_CONTAIN` stripped every non-digit character from the filter value, so `+33` became `33` and the generated `ilike`/`like` predicates could not distinguish an international calling code from any number containing those digits. `turnRecordFilterIntoGqlOperationFilter` now preserves a leading `+` while still removing other formatting characters (spaces, dashes, parentheses). `+33 6 12` becomes `+33612`; values without a `+` are unchanged. Added a regression test in `computeViewRecordGqlOperationFilter.test.ts` for a `+`-prefixed value. Lint and typecheck pass on `twenty-shared` and `twenty-front`; the filter test suites pass in both packages. --------- Co-authored-by: Thomas Trompette <tom@twenty.com> |
||
|
Etienne
|
8f9f2f390e |
fix(ai-chat): show streaming activity during and between steps (#23581)
https://github.com/user-attachments/assets/e72e313c-66f8-40af-bf48-9225422ffa78 ## Problem During a streaming turn with tool calls, the chat goes completely static in two places: - **Between two steps**: once a tool's output arrives, its row flips to past tense and nothing animates until the model's next chunk arrives (a full LLM round trip, often several seconds). This window is defined by the absence of parts, so no part-driven component can fill it — and the pre-turn "…" indicator can't either, since it's cleared on the turn's first chunk and never comes back. - **During tool execution**: the active tool row in `ThinkingStepsDisplay` is a static icon + label; the only animated element there is the orbit loader on an actively-streaming reasoning part. Users can't tell whether the AI chat is still thinking or blocked. ## Fix - **Pending thinking row between steps.** The renderer flags the trailing thinking-steps group of a streaming, error-free message (`showPendingThinkingRow`), and `ThinkingStepsDisplay` appends the thinking row (orbit loader + "Thinking") inside its rows container when none of its own steps is active (`isThinking`, which it already computes). The row occupies the exact slot where the next real step row materializes, so the handoff happens in place with no layout shift. - **One shared row component.** `AiChatThinkingRow` renders the orbit loader + "Thinking" and is used both for an actively-streaming reasoning step and for the pending row. - **Shimmer on executing tools.** Active tool rows wrap their label ("Searching the web for…") in the existing `ShimmeringText` while awaiting output, with the text as a direct child of the background-clip element so the effect applies reliably. - **Activity derived from the tool lifecycle state.** `isThinkingStepPartActive` now checks `input-streaming` / `input-available` instead of output presence, so a tool completing with a legitimate `null` output is no longer classified as still running. Why the trailing-group check is sufficient: anything in progress outside the group — streaming answer text, a running code execution card, a pending question — is itself a later render item, so the group isn't last and never gets flagged. No message-wide part scanning needed. ## Notes - The row renders only while `agentChatIsStreaming`, which the existing keepalive watchdog force-clears (with a visible connection-lost error) after ~5s of subscription silence — it cannot spin forever on a dead stream. - It never shows while waiting on the user: `ask_questions` renders as its own item after the group, and the server ends the stream on that tool anyway (`stopWhen`). - Consciously not covered, for simplicity: a pause right after a mid-turn text part or right after the routing row. ## Tests - Renderer: trailing group flagged as pending while streaming; not flagged when answer text follows or when not streaming - `ThinkingStepsDisplay`: pending row appended after completed steps, suppressed while a tool step runs, loading label shown on a running tool - `isThinkingStepPartActive`: lifecycle-state cases, including a completed tool with `null` output Lint, format, and `typecheck twenty-front` are clean. |
||
|
Raphaël Bosi
|
a9084604b4 |
Use the fast model for the onboarding setup chat (#23586)
The workspace setup chat ran on the smart model. The hidden kickoff turn enqueued its job without a `modelId`, and the frontend sends none unless the user picks one, so every turn fell through to `modelId ?? workspace.smartModel` in `chat-execution.service.ts`. Two halves, since the kickoff is server-initiated and the frontend never sends it: - `startHiddenKickoffStream` takes a `modelId` and the setup chat passes `workspace.fastModel`. - `useAgentChatModelId` requests `workspace.fastModel` on the setup page, so user turns follow. Everywhere else it still sends nothing and the server fallback is unchanged. `workspace.fastModel` defaults to the `default-fast-model` sentinel, so the model still resolves through the registry and stays admin-overridable. An explicit pick from the model picker still wins. |
||
|
Thomas Trompette
|
53a18d7528 |
feat(workflow): route all version content readers through the flag-aware sources (#23583)
## What Follow-up to #23499. Migrates every remaining reader of `record.trigger`/`record.steps` so all version content flows through the flag-aware sources, then removes `trigger`/`steps` from the record field sets. The record CRUD path no longer carries version content anywhere in the app. Reading is still entirely behind `IS_WORKFLOW_VERSION_IN_CORE_ENABLED`: this PR changes who asks, never where the answer comes from. Flag off remains record reads (via the content hook's record branch), flag on the core query. ## Per reader | reader | now reads | | --- | --- | | `WorkflowDiagramCanvasEditable` (connect, drag-stop) | flow atom | | `useDeleteStep` | flow atom | | `WorkflowEditActionIfElseBody` (branch cleanup) | flow atom | | `SidePanelWorkflowCreateStepContent` (parent-step lookup) | flow atom | | `SidePanelWorkflowStepInfo` | flow atom (explicit instance id), falling back to `useWorkflowVersionContent` when the visualizer is not mounted | | `TestWorkflowSingleRecordCommand` | `useWorkflowVersionContent`; `ready` gates on content being loaded | | headless enrichment hook (imperative) | core content query when the flag is on, record otherwise | | `WorkflowRunVisualizerEffect` (step output schemas) | the run snapshot (`state.flow`), which is what a run should show anyway | ## Field-set slimming `useWorkflowVersion` and `useWorkflowWithCurrentVersion` stop fetching `trigger`/`steps` (identity fields only). Three call sites lost their only reason to call `useWorkflowWithCurrentVersion` and were dropped entirely. Verified by grep that no `currentVersion.trigger/steps` reads remain; the only remaining `.trigger`/`.steps` accesses are argument-taking utils whose callers now pass flow/content-sourced objects. ## Verification - `nx typecheck twenty-front` green - Front tests: 1058 green (the enrichment test gained mocks for the apollo client and flag its hook now uses) - Full-tree `oxfmt` + `oxlint --type-aware` green (3 remaining warnings are pre-existing in unrelated record-field files) - Live click-through pending, flag off and on <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23583?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. --> |
||
|
Weiko
|
0d63906a58 |
Fix calendar field picker state handling (#23595)
## Context Changing a calendar date field already updated the record-index calendar state immediately, so the calendar moved to the new field before the `updateView` mutation completed. The options dropdown still derived its selected checkmark and field labels from `currentView`, which remains unchanged while persistence is pending. On slower environments this left the previous field name visible even though the calendar was already using the new field. Locally the same mismatch existed, but was only visible briefly because the mutation completed faster. ## What changed - Read the active start and end date field IDs from the record-index calendar component state in the calendar options dropdown. - Use that state for the main options label, the two-field submenu, and both field-picker selections. - Use the optimistic end-field state when filtering compatible start fields and deciding whether an incompatible end field must be cleared. - Keep the existing view mutation and calendar-state writes unchanged. ## Why The calendar and its configuration UI now share the same source of truth while persistence is pending. A field selection updates the calendar, checkmark, and contextual labels together instead of temporarily mixing optimistic calendar state with stale persisted view metadata. ## Safety and expected impact This is frontend state synchronization only. It does not change the metadata schema, API payloads, or persistence flow. Existing date and datetime compatibility rules remain in place. Users should see the selected field name update immediately, including when the metadata mutation is slow. ## Limitations This does not change mutation error handling or add rollback behavior. The calendar atoms were already updated optimistically before this change, this PR only makes the configuration UI reflect those same values. ## Validation - Reproduced the stale selection on qacoco and locally. - Verified locally that the checkmark moves immediately after selecting another date field, before the mutation closes the dropdown. - `npx nx typecheck twenty-front` - Focused type-aware oxlint on the four changed files, 0 warnings and 0 errors. - `npx oxfmt --check` on the four changed files. - `git diff --check` |
||
|
github-actions[bot]
|
b4102946f4 |
i18n - translations (#23598)
Created by Github action Co-authored-by: github-actions <github-actions@twenty.com> |
||
|
Thomas Trompette
|
a747e62970 |
fix(workflow): use as draft with an existing draft and cross-object record page filters (#23524)
Fixes two workflow issues.
### "Use as draft" fails when a draft already exists
`UseAsDraftWorkflowVersionSingleRecordCommand` rendered its own
`OverrideWorkflowDraftConfirmationModal`. Headless commands are
unmounted by `HeadlessEngineCommandWrapperEffect` as soon as `execute`
resolves, so the modal was removed from the tree right after `openModal`
was called and the user saw nothing happen. This regressed when the
command was converted from a rendered `<Command onClick>` to a
self-unmounting effect.
The command now uses `HeadlessConfirmationModalEngineCommandEffect`, the
existing mechanism for headless commands that need a confirmation: it
opens the app-wide `CommandMenuConfirmationModalManager` and keeps the
command mounted until the modal emits its result.
`OverrideWorkflowDraftConfirmationModal`, its modal id and its config
state are deleted.
To keep the "Go to Draft" shortcut, the shared confirmation modal config
gains an optional `linkButton` rendered as a secondary link button that
emits a `cancel` result on click.
The command also resolved the workflow id through `useWorkflowVersion`,
which is `undefined` while the query is in flight, so it threw and
surfaced an error snackbar through the command error boundary. It now
reads the workflow id off the selected record like the sibling workflow
version commands, and waits for the workflow to load before deciding
whether a confirmation is needed.
### `workflow object doesn't have any "workflowId" field` when opening a
workflow from a version
`useRecordShowPagePagination` builds prev/next queries from the parent
view stored in `contextStoreRecordShowParentViewComponentState`.
Navigating from a workflow version record page to its workflow through
the relation chip keeps the workflow version parent view, whose relation
filter compiles to `workflowId: { in: [...] }` and is then sent against
the `workflow` object, which the API rejects.
`useQueryVariablesFromParentView` now ignores the parent view when
`parentViewObjectNameSingular` does not match the current object, which
covers every navigation path between record pages of different objects.
### Test
Added `useQueryVariablesFromParentView.test.tsx` covering both the
matching and mismatching parent view object.
Manually checked on a local instance: override with an existing draft,
"Go to Draft", cancel then re-trigger, and the no-existing-draft path,
plus navigating from a filtered workflow versions view to a workflow.
---------
Co-authored-by: Tom <tom@twenty.com>
|
||
|
github-actions[bot]
|
f3de8ce631 |
i18n - translations (#23587)
Created by Github action Co-authored-by: github-actions <github-actions@twenty.com> |
||
|
Raphaël Bosi
|
5848c9bd30 |
Display object, field and view links as chips in the AI chat (#23573)
<img width="3840" height="1876" alt="CleanShot 2026-07-30 at 15 37 46@2x" src="https://github.com/user-attachments/assets/9fe178b9-c2fa-4b05-9c9d-0cdc80270b67" /> https://github.com/user-attachments/assets/34c4e486-c462-4300-ae98-da99f614f069 The AI chat already renders record chips from a `[[record:...]]` marker the model writes in its prose, but naming an object, field or view produced plain text. This adds three sibling markers so those render as chips too, as in the [Figma design](https://www.figma.com/design/xt8O9mFeLl46C5InWwoMrN/Twenty?node-id=104416-116261). - `[[object:<nameSingular>:<label>[[/object]]` links to the record index page. It is name-keyed rather than id-keyed so an object the assistant only *proposes* to create still renders as a chip, just without a link. - `[[field:<id>:<label>[[/field]]` links to the field's settings page, gated on the `DATA_MODEL` permission. - `[[view:<id>:<label>[[/view]]` links to the object index page for that view. Field and view ids must come from a tool, so an unresolvable one falls back to plain text rather than a chip that goes nowhere. The record-only parser becomes one scan over all four kinds. Alternative order is load-bearing: `[[view:<uuid>:` is shaped exactly like the legacy prefix-less record marker, so metadata kinds are tried first and only records keep the legacy `]]` terminator. Server side is prompt-only. The metadata and view tools return bare objects rather than `ToolOutput`, so there is nowhere to hang a structured reference array without wrapping every factory, and the names and ids the markers need are already in those results verbatim. Also fixes a pre-existing issue in `LazyMarkdownRenderer`: its `components` map was rebuilt on every render, and react-markdown uses each entry as the JSX element type, so every node remounted on every streamed chunk. Harmless before, expensive once the model is told to chip every metadata name it writes. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23573?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
|
65155fe50c |
feat(apps): add enqueueJob to run a logic function on the workers (#23527)
Closes twentyhq/core-team-issues#2742 A logic function run is capped by its own `timeoutSeconds` (900s max), so anything that can't finish in one run — a full re-sync, a per-record fan-out, a rate-limited third-party API — had no way to continue. This adds a way to hand that work to the workers. ## What it looks like for an app author ```ts import { enqueueJob } from 'twenty-sdk/logic-function'; await enqueueJob({ logicFunctionUniversalIdentifier: '9f1c3d7e-51b8-4a29-8f0d-7c4e2a6b1d33', payload: { cursor: nextCursor }, retryLimit: 3, priority: 2, delayMs: 60_000, }); ``` The target runs in its own process with its own timeout budget. The classic shape is a function that enqueues *itself* with the next cursor until there is nothing left. ## Changes **twenty-shared** — `EnqueueJobInput` / `EnqueueJobOptions` / `EnqueueJobResult` in `application`. **twenty-server** — new `application-job` module under `core-modules/application`, following the `application-key-value` pattern: - `enqueueJob` mutation on the metadata API, `@AuthApplication`-scoped - the lookup is scoped to `applicationId` + `workspaceId` — that's the authorization boundary, an app can only enqueue its own logic functions, anything else is `LOGIC_FUNCTION_NOT_FOUND` - pushes a `LogicFunctionTriggerJob` onto the existing `logicFunctionQueue`, so the enqueued run goes through the same executor (and the same execution throttling) as every other trigger - the queued run inherits the caller's `userId`/`userWorkspaceId`, so its app access token carries the same permissions as the function that queued it **Job options** are range-checked via `ResolverValidationPipe`, since the values come from application code and an unbounded delay or retry count would let an app pin work in the shared queue: | Option | Default | Range | |--------|---------|-------| | `retryLimit` | `0` | `0`–`10` | | `priority` | queue default | `1`–`10` (lower first) | | `delayMs` | `0` | `0`–7 days | `retryLimit` defaults to `0` rather than inheriting the server-route path's `3`: retries re-run the whole handler, so opting in should be the author's explicit choice. **twenty-sdk** — `enqueueJob` in `twenty-sdk/logic-function`, same shape as `runAgent`/`kv`. **Docs** — new "Background Jobs" page under Extend → Apps → Logic, plus nav and overview entries. **Generated** — regenerated `twenty-front/src/generated-metadata` and `twenty-client-sdk/src/metadata/generated` for the new mutation. ## Tests - `application-job.service.spec.ts` — 5 unit tests: job options mapping, defaults, acting-user propagation, application-scoped lookup, not-found - `enqueue-job.integration-spec.ts` — 5 integration tests: rejects a non-`APPLICATION_ACCESS` token, enqueues a function the app owns, rejects a function owned by another application, rejects an unknown identifier, rejects out-of-range options All green locally, along with `typecheck` for `twenty-server`/`twenty-sdk` and oxlint/oxfmt on the touched files. ## Notes for review - The target is addressed by `universalIdentifier`, matching `runAgent({ agentUniversalIdentifier })` and `ServerRouteDispatchResult.targetLogicFunctionUniversalIdentifier`. Addressing by `name` would be friendlier, but logic function names aren't validated for uniqueness within an app — happy to add it as a convenience if you'd rather. - `enqueueJob` returns as soon as the job is accepted; it can't return the target's result, since the queue driver's `add` returns void. Documented, with a pointer to the KV store for handing results back. --- _Generated by [Claude Code](https://claude.ai/code/session_01QrYvGonS3HMdeuMAVjs5hR)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23527?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> |
||
|
Thomas Trompette
|
6447b7f935 |
feat(workflow): make the flow atom authoritative for version content, read core behind a flag (#23499)
## What
The frontend half of the workflow-version read switch, plus the small
server query it consumes. Two ideas:
1. **One hook owns where content comes from.**
`useWorkflowVersionContent(workflowVersionId)` returns `{ trigger, steps
}` from the workspace record when `IS_WORKFLOW_VERSION_IN_CORE_ENABLED`
is off (default), and from the new `workflowVersionContent` core query
when on. Switching the source later (core-only, after the column drop)
is a change inside this one hook.
2. **`flowComponentState` becomes authoritative for the builder.** The
canvas, diagram and step output schemas derive from the jotai atom; the
atom is seeded once per version through the hook above; mutations keep
it up to date.
## Why the seeding change is required
Today `WorkflowDiagramEffect` re-seeds the atom from the Apollo record
on **every** `currentVersion` identity change. That has two
consequences:
- Three of the five step/edge hooks (`delete step`, `create edge`,
`delete edge`) never write the atom themselves; they only write the
record and the re-seed papers over it.
- The model breaks the moment content comes from a source mutations do
not write (i.e. core): the stale fetch would be re-applied over every
optimistic edit, and your just-added step would vanish from the canvas.
So the atom is now seeded **once per version**, and
`useUpdateWorkflowVersionCache` applies the mutation's
`stepsDiff`/`triggerDiff` to the atom directly. All five step/edge hooks
get that through their existing call, which closes the three-hook gap in
one move. The step-update, trigger and tidy-up hooks write the atom too.
The record-cache writes are all kept while `trigger`/`steps` still live
on the record (dropped later with the columns).
## The dead wire, now the refresh path
`shouldWorkflowRefetchRequestFamilyState` was set by
`WorkflowSSESubscribeEffect` (reconnect, other-tab create) and
**consumed by nothing**. It is now the external-refresh path: when set,
the builder refetches content and reseeds. Known trade-off: while
connected, another tab's edits no longer live-patch the canvas through
record cache updates (they arrive on reconnect, version switch or
reload). Given concurrent editing of one draft has no conflict handling
anyway, that seemed acceptable; easy to extend the SSE effect to set the
flag on update events if we want live propagation back.
## Untouched by design
- **Run visualizer**: feeds the same atom from the immutable
`workflowRun.state.flow` snapshot; that duality (version content or run
snapshot) is exactly why the atom stays separate from the record store.
- **Version visualizer** (read-only): reseeds on content change, safe
because nothing writes its instance optimistically.
- Peripheral readers of `currentVersion.trigger/steps` (test-workflow
command, headless command enrichment, if-else body, etc.) still read the
record. Correct while dual-writing continues; they move to the content
hook before workspace content writes stop (tracked in the migration
plan).
## Verification
- `nx typecheck` green on both packages; `oxfmt` + `oxlint --type-aware`
green on all 16 changed files
- Front unit tests: 134 suites / 993 tests green (the two hook tests
gained the visualizer instance context their hooks now require)
- New server integration test for `workflowVersionContent`
- **Live click-through pending**: step create/delete/duplicate, edge
create/delete, trigger edit, tidy-up, draft create/discard, activation,
version viewer, run viewer, with the flag off and on. The failure mode
this PR guards against (an edit vanishing from the canvas) does not show
up in typecheck or unit tests.
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/23499?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]
|
5977185c34 |
i18n - translations (#23572)
Created by Github action <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23572?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
|
a3beea893d |
Revert the external link confirmation popup for front components (#23567)
Reverts #23270 and #23404. Links in front components navigate natively again, with no confirmation popup and no per-app trusted-origins state in localStorage. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23567?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
|
38ad13655c |
Auto-start the workspace setup chat with a data model proposal (#23437)
https://github.com/user-attachments/assets/d447372b-c1b4-4c95-bac9-a8f8efa7d4a1 When the workspace creator lands on `/workspace-setup` after onboarding, the AI chat now starts on its own: an invisible first message, built server-side from the company enrichment collected in #23199, asks the assistant to propose a data model tailored to the business. The proposal streams in; the user never sees the prompt. - New `startWorkspaceSetupChat` mutation: creator only, gated on `IS_ONBOARDING_AI_CHAT_ENABLED`, available models and credits. Idempotent per user and workspace via a `keyValuePair` pointing at the thread, so a reload or a second tab joins the same conversation instead of starting a new one. - The thread holds exactly one hidden `USER` message combining the company context and the setup instructions, which keeps the one-hidden-message-per-thread index from #23199 satisfied. It goes through a dedicated streaming path that never queues, so the prompt cannot resurface as a visible message. - The assistant only proposes. It creates nothing until the user approves, then builds the model with the `metadata-building` skill. Objects and fields get English names with labels in the user's language, and the conversation continues in that language. - With no enrichment (consumer email domain, or the integration disabled) the kickoff still runs, and the assistant asks one short question about the business before proposing. - `findLatestSentUserMessage` no longer filters out hidden messages, so a failed kickoff turn stays retryable, and the no-message chat error surface now offers retry for stream errors. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23437?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
|
079e9b8e56 |
feat(dashboard): extend number format option to bar, line and pie charts (#23505)
https://discord.com/channels/1130383047699738754/1509604545381142649 Extends the Format option (Short/Full) added for the Number widget in #21521 to bar, line and pie charts. Format controls the numbers printed on the chart face: data labels and the pie center metric. Axis ticks stay abbreviated and tooltips always show the full value. Defaults to Short, so existing charts render unchanged. Server: nullable `numberFormat` on the bar/line/pie configuration DTOs, exposed in the dashboard AI tool schema. No migration, configuration is jsonb. Deferred: - The Format row has no visible effect while data labels are off, since tooltips are always full. - Number widget format defaults differ by field type (CURRENCY defaults to Short, NUMBER to Full). Pre-existing, untouched here. https://github.com/user-attachments/assets/0778f08a-6681-4e7a-8716-fb3026d1e01f <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23505?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
|
0b335d15b3 |
Refresh billing state after ending trial period (#23534)
Fixes #23530 After adding a credit card in the billing prompt, the credits section and subscription details stayed stale until a full page refresh. The `endSubscriptionTrialPeriod` mutation only returned `status` and `hasPaymentMethod`, and the frontend hook only patched the subscription status into the workspace state. The credits query was never refetched, so granted credits kept showing trial values, and `currentPeriodEnd` (renewal date) and `billingCustomer.hasPaymentMethod` stayed outdated. The backend already syncs everything to the database synchronously before the mutation returns, so fresh data was available, just never fetched. Changes: - `BillingEndTrialPeriodDTO` now includes nullable `currentBillingSubscription` and `billingSubscriptions`, returned by the resolver on success, mirroring the other billing update mutations (`switchSubscriptionInterval`, etc.) - `useEndSubscriptionTrialPeriod` applies the full billing update via `useApplyCurrentWorkspaceBillingUpdate` (falling back to the previous status-only patch), marks the billing customer as having a payment method, and refetches `GetResourceCreditUsage` so the credits section updates for any active observer This covers all entry points that end the trial: the billing page card modal, the trial banner, the AI chat banner, and the return from the Stripe portal. --- _Generated by [Claude Code](https://claude.ai/code/session_01W1J7cW2MhaqXGfdjvHeFoX)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23534?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]
|
33fb57d128 |
i18n - translations (#23525)
Created by Github action Co-authored-by: github-actions <github-actions@twenty.com> |
||
|
Thomas des Francs
|
030ee2c7cc |
Move settings tabs below page headers (#23519)
## Summary - Position the Admin Panel tabs directly below the settings header. - Position the Communication tabs directly below the settings header. - Reuse the shared settings tab bar while preserving permissions, disabled states, and hash navigation. - Keep the responsive tab overflow menu available on narrow settings cards. ## After <img width="3456" height="2008" alt="Admin Panel tabs positioned below the settings header" src="https://github.com/user-attachments/assets/c8ff965c-d4b2-4700-85e1-0763f9f0852d" /> |
||
|
Raphaël Bosi
|
ada7eb1d88 |
Restore the Figma halftone shapes and calm the welcome animation (#23495)
https://github.com/user-attachments/assets/0c06d190-977e-4ad6-8a02-251f341ee310 The welcome overlay settled into circles instead of the halftone from Figma: the densify step that took the dot set from 681 to 2897 emitted points, so every dash had zero length. All 681 dashes in the Figma export (`public/images/onboarding/welcome-halftone.svg`) share a constant length / stroke width ratio of 1.452, so the shape is restored by deriving the length from the stroke width, with no data regeneration. Dashes now stretch into shape while they are still flying in, rather than popping once they have landed. The rest of the pass makes the animation quieter. The shine sweep is gone, along with the highlight colour that only fed it. Particles approach from much closer on a gentler ease, the idle drift is roughly halved, and the exit is a soft outward drift instead of a burst that threw everything off screen. The white pill behind the title and the person chip's surface are removed too, so the title reads directly against the halftone. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23495?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
|
684259fd5e |
Make onboarding cards contrast with the page background (#23516)
Onboarding card surfaces used `background.secondary`, the same token as the onboarding page background, so they blended in (visible on the workspace selection step). Switched them to `background.primary`, matching the other onboarding cards (plan card, install apps, trust badges). <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23516?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
|
58b8e8afee |
Fix clipped New chat button label in localized navigation drawer (#23511)
Fixes #23503 <img width="161" height="76" alt="Capture d’écran 2026-07-29 à 17 20 25" src="https://github.com/user-attachments/assets/a6ea0a12-b91d-419f-8023-8e65d5dce65b" /> The expanded "New chat" button had a hardcoded `width: 103px`, sized for the English label. Localized labels ("Neuer Chat", "Nouveau chat") were clipped, since `OverflowingTextWithTooltip` can only truncate inside a parent it cannot resize. The expanded wrapper is now `width: max-content` with `max-width: 100%`, so it grows with the label and only truncates (with tooltip) when the sidebar has no space left. `min-width` keeps the pill from collapsing below icon size. Collapsed state is unchanged. ### Verified locally (German locale) | | wrapper width | label | |---|---|---| | before | 103px (fixed) | `Neuer C...` clipped | | after | 109px (max-content) | `Neuer Chat` in full | - English: 103px -> 98px, visually identical. - Collapsed drawer: still exactly 24x24, unchanged. - Very long label (Vietnamese-length): wrapper stops at the sidebar edge, no overflow, label truncates with tooltip. |
||
|
github-actions[bot]
|
cedb3768ec |
i18n - translations (#23513)
Created by Github action <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23513?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> |
||
|
Weiko
|
adfb96c7ce |
Keep email participant avatar colors consistent (#23444)
## Summary - Fixes issues where the same record didn't share the same avatar in multiple places of the inbox. - Add a shared avatar color seed resolver for email participants. - Apply consistent placeholder colors across participant chips and email thread previews. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23444?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
|
742f76e318 |
[BREAKING-CHANGE] Add NOT_RECORDED call recording status (#23478)
Adds NOT_RECORDED to the CallRecording status select, for meetings where nothing was captured (bot never admitted, meeting not started, nobody joined). First part of twentyhq/core-team-issues#2706, split out so existing workspaces are upgraded before the call-recorder app starts writing the new status. - NOT_RECORDED enum value + standard select option - 2-26 workspace upgrade command adding the option to existing workspaces (idempotent, same option id as the standard definition) App-side classification from Recall sub codes comes in a follow-up PR. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23478?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]
|
63d34e0133 |
i18n - translations (#23509)
Created by Github action <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23509?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> |
||
|
Weiko
|
e2e2142998 |
Add calendar date field submenu with grouped field options (#23445)
## Summary - Add a submenu for selecting calendar date fields as it was not clear enough that you could pick 2 date fields. - Group date and datetime fields with non-selectable headers ### Before <img width="240" height="252" alt="Screenshot 2026-07-29 at 11 32 54" src="https://github.com/user-attachments/assets/169bd965-676f-4ef9-8ba6-9ecac80547c6" /> ### After <img width="260" height="246" alt="Screenshot 2026-07-29 at 11 31 58" src="https://github.com/user-attachments/assets/a4471bb0-5c1f-4f5e-bddb-165a5c9da4c7" /> |
||
|
Thomas Trompette
|
a0281f635b |
Restore soft-deleted junction record when re-adding a junction relation (#23371)
Fixes #23305. Removing a junction relation soft-deletes the intermediate junction record. Re-adding the same relation created a brand new record, which the composite unique index on the junction object (e.g. `personId` + `companyId`) rejected with "This record already exists". `useUpdateJunctionRelationFromCell` now creates the junction record through `useCreateManyRecords` with `upsert: true`. The server matches on the unique index with `withDeleted()` and clears `deletedAt` on the matched row instead of inserting. ## This revives, it does not create Worth being explicit, because it is a deliberate trade and not obvious from the diff. When a soft-deleted row exists for the pair, the user gets that row back. Same id, same `createdAt`, same `createdBy`, and anything attached to it (notes, files, and any fields the app added to the junction object). Verified on a dev instance: after re-adding a link through the picker, the row still reported a creation date from days earlier. That is fine for a pure link. It is a lie for a junction that carries data, for instance a `PersonCompanyRelationship` with a role and dates. The alternative designs are hard-deleting on detach (needs `canDestroyObjectRecords` on the junction object, which most roles do not grant) and partial unique indexes (needs `indexWhereClause` exposed to app-declared indexes, which the SDK does not support today). Both are larger changes. This one unblocks affected apps without requiring anything from them. Note that upsert conflict detection ignores `indexWhereClause`, so shipping partial indexes later would not change this behaviour on its own. ## Why the id handling changed The hook no longer sends a client-generated id. Under upsert the server decides which row you get, so the id in the input would be discarded. The optimistic store entry still uses a local id so the chip appears immediately, then adopts the persisted id once the mutation resolves. Without that, a revive left an id in the store that exists nowhere on the server, and the next removal failed with "This record does not exist or has been deleted". Supersedes #23365, which took the same approach but added `$upsert` to the shared `createOne` mutation. That capability already exists per call on `createMany`, and widening the shared document broke the `useCreateOneRecordMutation` and `useCreateOneRecord` tests. ## Testing Verified end to end on a dev instance with a junction object carrying a non-partial composite unique index, since the dev seed does not create one and the bug cannot reproduce without it: - before: re-adding after a removal fails with "This record already exists" - after: the original row is restored, `deletedAt` cleared, one row throughout, and removing again in the same session works, with no GraphQL errors Added an integration test for the path this depends on: a soft-deleted record matched on its unique fields alone, with no id in the input. The existing coverage only exercised upsert by explicit id. ## Known gaps, deliberately not addressed here **Toggling a link off while its creation is still in flight.** The store id is provisional until the mutation returns, so a removal issued inside that window deletes an id the server never received. Reproduced by stalling the create and clicking remove during it: `CombinedGraphQLErrors: Record not found`, and the link stays active despite the user removing it. The window is one mutation round trip. Left for a follow-up; the likely fix is a per-record operation queue so adds and removes on a field run in click order. **Junction objects with no unique index.** Remove then re-add still creates a duplicate row there, on this branch as on main, because conflict detection is driven by unique indexes. --------- Co-authored-by: Shinu Cherian <129690295+Shinu-Cherian@users.noreply.github.com> |
||
|
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]
|
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`) |
||
|
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. |
||
|
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. --> |
||
|
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. --> |
||
|
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. --> |
||
|
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. --> |
