1292 Commits

Author	SHA1	Message	Date
Abdul Rahman	1b7dc0367e	fix(ai): gemini not working in ask ai (#21898) ... Upstream issue: https://github.com/vercel/ai/issues/14369 Gemini 400s whenever a tool result contains JSON Schema `$ref`/`$defs` (it reads `$ref` as a function declaration name and finds no match). We hit this because `learn_tools` returns tool input schemas, and our recursive filter schema emits `$ref`/`$defs`. Other providers accept it fine, so this only blocks Gemini. Adds a Google-only `wrapLanguageModel` middleware that serializes ref-bearing tool results to text before they reach Gemini, so the pointers travel as a string instead of structured keys. The model still reads the full schema (same as the MCP path). Guarded so normal tool results pass through untouched. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21898?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-22 07:16:59 +00:00
martmull	6423c4cd3c	Add recall io webhook endpoint (#21879) ... ## Context Bot-recording integrations (e.g. the Recall.ai meeting bot) receive webhooks from a third-party provider that delivers **every tenant's events to a single URL**. Our existing `route-trigger` (`/s/…`) resolves the workspace from the request host, which can't work for one shared multi-tenant webhook URL. We need an instance-scoped ingress that identifies the target workspace from the payload instead. ## Strategy Add a new **`ingress-trigger`** logic-function trigger, mirroring `route-trigger`: - A public endpoint keyed by the app's identifiers: `POST /webhooks/ingress/:applicationRegistrationUniversalIdentifier/:logicFunctionUniversalIdentifier`. - The logic function declares an `ingressTriggerSettings` block in its manifest describing how to find the workspace in the payload (`workspaceId: { source: 'body' | 'query' | 'header', path }`). - Core only **resolves the workspace** (declarative, fail-closed, prototype-safe path getter), verifies the app is installed in that workspace, then runs the function **synchronously** so the provider sees the response (status codes / retries). - **Signature verification stays in the logic function** (it gets `rawBody` + forwarded headers), keeping core provider-agnostic. - Shared execution logic (`build event → execute → map response`) extracted into `LogicFunctionTriggerService`, now reused by both `route-trigger` and `ingress-trigger`. ## Major changes - **twenty-shared**: new `ingressTriggerSettings` on `LogicFunctionManifest` (`IngressTriggerSettings` type). - **twenty-server**: new `ingress-trigger` module (controller, service, exception + filter, workspace-id resolver util). - **twenty-server**: extracted `LogicFunctionTriggerService` + `route-trigger-response.util` (response builder + sender); refactored `RouteTriggerService` and both controllers to reuse them. - **twenty-docs**: documented the ingress trigger (endpoint, workspace resolution, signature responsibility, provider HMAC examples). - Unit tests for the resolver and the ingress service.	2026-06-19 23:34:43 +02:00
Félix Malfait	23f5ba9ebf	feat: add resizable kanban column width (#21828) ... ## What & why Lets users resize the columns of a Kanban (record board) view. Requested by a user; the design avoids the "ragged board" problem by making the width a **single shared value**. ## Behaviour - A drag handle appears on the right edge of every column header. - Because all columns read **one** width value, dragging any handle resizes **every** column together — they can never end up mismatched. - Width is clamped between **150px** and **400px** (default **200px**). - The width is **persisted per view** and restored on reload. ## Approach **Backend** — a new nullable `View.kanbanColumnWidth` field, threaded through the existing view-level setting pattern (the same one `kanbanAggregateOperation` / `shouldHideEmptyGroups` use), so it gets create/update/manifest/override support for free: - entity column + `ViewOverrides` + `@WasIntroducedInUpgrade` - `CreateViewInput` / `UpdateViewInput` (`Int`, `@Min(150)`/`@Max(400)`) + `ViewDTO` - flat-view editable properties, entity-properties config, compare-type, standard-view + manifest converters - a fast instance command adding the `core.view` column **Frontend** — the value hydrates into a view-scoped atom and drives a single CSS variable set on the board container, which both column headers and bodies read. Live dragging only writes that CSS variable (no per-move React re-render); the final width is committed to the atom and persisted via `updateView` on pointer-up. ## Nullability / defaults `kanbanColumnWidth` is nullable — `null` means "never resized" and the UI falls back to the 200px default, so existing rows need no backfill. ## Validation - `nx typecheck twenty-server` ✅ and `nx typecheck twenty-front` ✅ - `nx lint:diff-with-main twenty-server` ✅; frontend lint fixes applied (split constants to one-per-file, removed `useRef`-for-state in favour of `useState`). - Draft pending a final green CI run (the dev container reclaimed `node_modules` mid-session; re-running locally). ## Test plan - [ ] Drag a kanban column edge → all columns resize together, clamped 150–400px - [ ] Reload → width persists for that view; other views unaffected - [ ] A view that was never resized still renders at 200px https://claude.ai/code/session_016Qe6oDBkhVbrq2QkXBJ5nE --- _Generated by [Claude Code](https://claude.ai/code/session_016Qe6oDBkhVbrq2QkXBJ5nE)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21828?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Claude <noreply@anthropic.com>	2026-06-19 15:58:13 +02:00
Paul Rastoin	26db3f5735	Deprecate legacy encryption (#21831) ... # Introduction Still preserving the cross-upgrade flow close https://github.com/twentyhq/core-team-issues/issues/2465 <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21831?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-19 11:32:39 +00:00
neo773	616d58bc7e	messaging: gmail folder backfill (#21753) ... demo https://github.com/user-attachments/assets/a157cee1-a8fa-4050-af1b-c31a83fb75da /closes #17095 <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21753?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-19 01:59:35 +02:00
Weiko	9f30915f6f	fix(metadata): remove deprecated isCustom from Objects and Fields (#21799) ... ## Context Follow-up to #21228, which deprecated `isCustom` on object/field metadata but kept it exposed because the frontend still relied on it. This removes it from the GraphQL API and the frontend entirely. ## Implementation ### Server - Remove `isCustom` `@Field` from the `Object`, `Field`, and `MinimalObjectMetadata` GraphQL types - Remove the `isCustom` `@ResolveField` resolvers and the `isCustomLoader` dataloader (+ payload/interface) - Remove `isCustom` as an internal `@HideField()` on the Object/Field DTOs used by the i18n standard-override gate > Use an explicit isStandard instead (which is the correct gating) ### Frontend - Add `getIsMetadataItemCustom` helper + `useGetIsMetadataItemCustom` hook: an item is custom when `applicationId === currentWorkspace.workspaceCustomApplication.id` - Migrate all consumers off `objectMetadataItem.isCustom` / `fieldMetadataItem.isCustom`; `isRecordFieldReadOnly` now takes a precomputed `isFieldCustom` - Drop `isCustom` from the metadata fragment/mutations/minimal query, FE types, zod schemas, and mock generators; regenerate GraphQL types ## Notes - Breaking change on the (already-deprecated) `Object.isCustom` / `Field.isCustom` GraphQL fields and the `isCustom` filter - FE semantic is "belongs to the workspace custom app" (third-party-app objects/fields are treated as non-custom) - `isCustom` on IndexMetadata / View / Skill / Agent is a separate column and is untouched - Breaking changes on REST metadata API	2026-06-19 01:19:49 +02:00
Weiko	cc4659ce11	fix(server): type WasRemovedInUpgrade columns with WasRemovedInUpgrade<> (#21785) ... ## Context WasRemovedInUpgrade type brand was introduced in https://github.com/twentyhq/twenty/pull/21228/changes#diff-1b6d688610669a46b3ee8e3a41b1c7eb0ee03e19146d0d249f95df6e56164a92R15 for the `isCustom` property deprecation. The @WasRemovedInUpgrade decorator and the WasRemovedInUpgrade<T> type are meant to go together: the type brand makes the property optional in every derived flat-entity type, so the column only needs to be declared on the entity itself. RolePermissionFlagEntity.flag had the decorator but was typed as a plain PermissionFlagType, forcing the property to be supplied everywhere. This PR: - Types flag as WasRemovedInUpgrade<PermissionFlagType> (matching the isCustom reference impl on object/field metadata). - Removes the now-redundant flag from the flat-entity construction sites, the create input, and the service call site — leaving it only on the entity. The GraphQL RolePermissionFlagDTO.flag is kept (it's an API field derived from permissionFlag.key, not the removed column). - Fixes a latent brand-leak in the flat-entity config type: toStringify is computed via object-detection, and a branded type reads as an object. This was harmless for boolean but wrongly forced toStringify: true for enum/string columns. Added UnwrapWasRemovedInUpgrade<T> and applied it so the brand is transparent making the pattern work for any type, not just booleans. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21785?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-18 15:23:24 +02:00
Abdul Rahman	ccc77932a0	Tool execution metrics (#21587) ... <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21587?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-18 10:58:47 +02:00
Félix Malfait	f96e36d3e6	fix(ai): prevent chat thread bricking from tool parts with null input (#21752) ... ## Problem Fixes #21695. An AI chat thread became **permanently unusable** — every subsequent message failed with `AI_APICallError: Internal server error` from Anthropic — when the thread history contained a tool part in `output-error` state with a **null input** (e.g. a tool call that failed input validation before execution, so neither `toolInput` nor `toolOutput` was ever captured). ## Validation of the reported findings I reproduced and confirmed the root cause empirically against the pinned `ai@6.0.97` SDK before writing the fix. **Root cause (confirmed from SDK source).** `convertToModelMessages` serializes every non-`input-streaming` tool part into a provider `tool_use` block, and for errored parts it uses: ```ts input: part.state === 'output-error' ? (part.input ?? ('rawInput' in part ? part.rawInput : undefined)) : part.input, ``` When both `input` and `rawInput` are nullish, the block is built with `input: undefined`, which `JSON.stringify` drops — so the HTTP payload carries a `tool_use` with **no `input` field**. This matches the reporter's minimal repro exactly (no `input` → `400 Field required`; `input: {}` → `200`). Inside a large streamed conversation the same malformed block surfaces as the generic `500`, and because the bad part is replayed on every turn the thread stays bricked. **Why #21276 didn't catch it.** `finalizeDanglingToolParts` only rewrote `input-available` parts; a part that arrives already in `output-error` with a null input was passed through untouched. **Note on current `main`.** A read-path default added recently (`mapDBPartToUIMessagePart`: `input: part.toolInput ?? {}`) already masks the live 500 on the standard reload path. However the gap is real and worth closing: the persist path still writes `toolInput = NULL` (the exact malformed rows the reporter found in `core."agentMessagePart"`), `finalizeDanglingToolParts` still doesn't normalize this case, and the protection rested on a single implicit default with no regression coverage. A small repro harness confirmed all of this: persisted `toolInput` was `undefined`, and a raw (non-defaulted) `output-error` part produced a `tool-call` whose `input` value was `undefined`. ## Fix Defense-in-depth so the invariant *"a tool part always carries a defined input"* holds at both the finalize and storage boundaries: - **`finalizeDanglingToolParts`** now backfills `input: {}` for `output-error` parts whose input is null, while preserving the original error message. This is the natural chokepoint (it already runs immediately before every persist). - **`mapUIMessagePartsToDBParts`** defaults a nullish tool input to `{}` so malformed rows are never persisted, independent of the caller. The existing read-path `?? {}` default is kept as a third safety net. ## Tests - Unit tests for `finalizeDanglingToolParts`: backfills `{}` for an `output-error` part missing its input, and preserves the existing validation error message. - Persistence test: `mapUIMessagePartsToDBParts` stores `{}` (never `null`) for a missing input. - End-to-end round-trip test: after finalize → persist → reload, `convertToModelMessages` produces a `tool-call` with a defined input and the errored call stays resolved. All three new core assertions were verified to **fail without the fix** and pass with it. Full AI module suite (97 tests) passes; `oxlint --type-aware`, `oxfmt`, and `tsgo` typecheck are clean. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01SpuX6Pp2yTevk1zKTRiB9G --- _Generated by [Claude Code](https://claude.ai/code/session_01SpuX6Pp2yTevk1zKTRiB9G)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21752?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Claude <noreply@anthropic.com>	2026-06-17 21:13:51 +02:00
Etienne	d99e479be8	feat(billing) - facilitate top up in ai chat (#21645) ... Today, when a trialing user hits their AI usage cap inside the Ask AI chat, ending the trial bounces them to the Stripe billing portal (and, for card-less users, loses their place in the conversation). This PR makes activating a paid plan / topping up credits feel seamless from within the chat: Trial users with a card on file activate their subscription in place, without leaving the app. Trial users without a card are sent to the Stripe payment-method portal and, on return, the trial is ended automatically and they're dropped back into the exact Ask AI thread they came from. Credit-exhaustion and trial banners now reflect whether a payment method exists (Add Credit Card vs Subscribe Now / End Trial Period) and upgrade inline via a confirmation modal instead of redirecting to Settings. Uploading Screen Recording 2026-06-16 at 07.51.12.mov… https://github.com/user-attachments/assets/4ea77273-da63-4b32-b6f1-5ac9e9560651 <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21645?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-17 16:20:11 +00:00
Félix Malfait	02a3a3c47c	fix(ai): handle dynamic-tool message parts in chat persistence (#21740) ... ## Summary Fixes #20558. AI chat streams crashed with `Unsupported part type: dynamic-tool` whenever the model emitted a *dynamic* tool call (a tool that isn't part of the bound schema). The assistant message never persisted, so the user saw a hard failure mid-stream. ## Root cause The AI SDK v6 emits two flavors of tool parts: - **Static** — `type: "tool-<toolName>"` (e.g. `tool-execute_tool`) - **Dynamic** — `type: "dynamic-tool"`, with the name on `part.toolName` `mapUIMessagePartsToDBParts` recognised tool parts with a homegrown check: ```ts part.type.includes('tool-') && 'toolCallId' in part ``` That returns `false` for `'dynamic-tool'` (it contains `-tool`, not `tool-`), so dynamic parts fell through to `throw new Error(\`Unsupported part type: ${part.type}\`)` during the `handleStreamFinish` persistence step. Stack trace from the issue matches exactly. The same broken heuristic was duplicated in: - `packages/twenty-server/.../mapDBPartToUIMessagePart.ts` (reverse mapper) - `packages/twenty-front/.../utils/mapDBPartToUIMessagePart.ts` (frontend mirror — would also throw on a `dynamic-tool` row reloaded from history) Meanwhile, two other call sites in the codebase (`finalize-dangling-tool-parts.util.ts`, `isThinkingStepPart.ts`) already correctly use the SDK's `isToolUIPart`, which natively recognises both flavors. ## What this PR does 1. **Switches all three mappers to the SDK's canonical check** (`isToolUIPart` on the forward path; explicit `dynamic-tool` + `tool-` startsWith on the reverse paths, where the input is an entity/DTO, not a UI part). 2. **Persists `toolName`** — the column already existed on the entity, DTO and GraphQL fragment but nothing wrote it. For static parts the name is recoverable from `type`; for dynamic parts it's the only place the name lives, so without it the round-trip is impossible. The shared denormalisation also helps existing per-tool analytics (`count-native-web-search-calls-from-steps.util.ts`). 3. **Reconstructs `dynamic-tool` parts on read** (with `toolName`) so they survive a DB round-trip both on the server and on the frontend history view. 4. **Adds a round-trip unit test** covering both `dynamic-tool` and a static tool part to lock the behavior in. ## Architecture notes (called out for review) - `mapDBPartToUIMessagePart` is duplicated frontend + backend because the input shape differs (TypeORM entity vs. GraphQL DTO). Out of scope to consolidate here, but they're drifting — this PR is what that drift looked like in production. Worth a follow-up to express the shared logic once over a unified row type. - I left the existing renderer guard `part.type !== 'dynamic-tool'` in `AiChatAssistantMessageRenderer.tsx` alone — it's a reasonable UI-side decision to not attempt to render an unknown dynamic tool generically. Persistence and history reload now work; rendering of dynamic tool calls is a separate UX decision. - No DB migration needed — the `toolName` column already exists. Old static rows have `toolName: null`; the reverse mapper recovers their name from the `type` column as before. Old dynamic-tool rows don't exist (they all threw on write). ## Test plan - [x] `yarn workspace twenty-server jest map-message-parts.dynamic-tool` — 5 passed - [x] `yarn workspace twenty-server jest finalize-dangling-tool-parts.roundtrip` — still 4 passed (no regression) - [x] `yarn nx typecheck twenty-server` — clean - [x] `yarn nx typecheck twenty-front` — clean - [x] `yarn nx lint:diff-with-main twenty-server` — clean - [x] `yarn nx lint:diff-with-main twenty-front` — clean - [ ] Manual: trigger an AI chat that exercises a dynamic tool (e.g. via an MCP server returning a tool not in the bound schema) and confirm the stream finishes and the message persists. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_013EE11eVWtyxmdcbEHVJKoc --- _Generated by [Claude Code](https://claude.ai/code/session_013EE11eVWtyxmdcbEHVJKoc)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21740?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Claude <noreply@anthropic.com>	2026-06-17 18:12:21 +02:00
Weiko	607d9ee6e5	fix(server): allow app-defined permission flags to be referenced by a role in the same sync (#21742) ... ## Context When an application defined custom permission flags and a role referencing them in the same sync, installation failed, first at validation (Permission flag not found) and then at execution (Migration action 'create' for 'rolePermissionFlag' failed). Root cause: both the migration builder order and the runner execution order processed rolePermissionFlag before permissionFlag, so the role's flag assignments were validated/inserted before the flags they reference existed. ## Changes - Builder order: run the permissionFlag builder before rolePermissionFlag so newly created flags are visible in the optimistic maps when assignments are validated. - Execution order: order the permission-flag actions so definitions are created before assignments, and assignments deleted before definitions, keeping the FK satisfied in both directions. - In-use check: move the "flag still assigned to a role" guard out of the per-entity deletion validator (order-dependent, false-positived when a flag and its assignments were deleted together) into a new order-independent validatePermissionFlagNotInUseCrossEntity (aligned with existing validateObjectMetadataCrossEntity, validateViewFieldLabelIdentifierCrossEntity, ...), run after all builders against the migration's final state. This fixes both the create path (define flag + reference it in one sync) and the teardown path (delete flag + its assignments in one sync). <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21742?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-17 15:44:01 +00:00
martmull	102c530d0f	Add limit on view widget (#21718) ... <img width="1345" height="463" alt="image" src="https://github.com/user-attachments/assets/a5d9ac2f-6375-4956-895d-3675aa9bebc1" /> <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21718?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: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>	2026-06-17 14:43:31 +00:00
Weiko	3ee93b5ec9	feat(server): add isSystemSideEffect & merge createOneObject/createOneField side-effect migrations (#21673) ... ## Context When an object is created via the metadata API, `createOneObject` creates its side-effect entities (INDEX view + viewFields, indexes, navigation menu item, "go to" command menu item, record-page fields view, page layout/tabs/widgets) across **three separate `validateBuildAndRunWorkspaceMigration` calls**, purely because the protection behavior (mutations → overrides, delete → deactivate, reset → reactivate) was keyed on *"owned by the standard app"*, forcing the side effects into batches with different application owners. This misrepresents ownership and breaks atomicity. This PR separates two orthogonal concepts: - **Ownership** (`applicationId`), the true owner: the caller's application (the workspace custom app today, 3rd-party apps later). - **Protection** (`isSystemSideEffect`), the row was generated by the system, so user mutations route to overrides, deletion becomes deactivation, and reset restores defaults. Once side effects are re-owned to the caller, the old `applicationId === standardApp` check can no longer tell an original side-effect row from a user-added one so a dedicated `isSystemSideEffect` flag carries the protection instead. This is **PR 1 of 2** (forward-only). It makes newly created objects and fields correct; existing workspaces are handled by a follow-up backfill (see *Out of scope*). ## What this PR does - **`isSystemSideEffect` column** on the 8 affected entities (`view`, `viewField`, `indexMetadata`, `commandMenuItem`, `pageLayout`, `pageLayoutTab`, `pageLayoutWidget`, `fieldMetadata`), with `@WasIntroducedInUpgrade` + an entry in the flat-entity property configuration (`toCompare: true`, read-only). - **Single atomic migration in `createOneObject`**: the three `validateBuildAndRunWorkspaceMigration` calls are merged into one, owned by the caller (`resolvedOwnerFlatApplication`) and the record-page view/fields, page layout, and navigation command item are re-owned to the caller and flagged `isSystemSideEffect: true`. `buildNavigationFlatCommandMenuItem` is parameterized with `applicationUniversalIdentifier` (no longer hardcoded to the standard app). - **Field-creation side effects** (`createManyFields`/`createOneField` already run as a single caller-owned migration, so no re-ownership/merge was needed): the auto-created viewField is flagged `isSystemSideEffect: true`, and a new field now also propagates to the object's **INDEX/table view** (added there as a **hidden** column, `isVisible: false`) in addition to the record-page FIELDS widget. The INDEX view is targeted directly by `key = INDEX` (it is not a page-layout widget), de-duplicated per `(viewId, fieldMetadataUniversalIdentifier)` to respect the per-view unique index. The unique-field index is likewise flagged the inverse relation field stays unflagged (`isSystem: false`). - **Protection predicate** extended: `isCallerOverridingEntity` and the removal/reset split strategies now treat `isSystemSideEffect` rows as protected even when caller-owned (route to overrides / deactivate / reset) and the page-layout-reset guards allow resetting flagged entities. - **Standard compute maps** set the flag consistently so a re-sync produces no diff (standard-object side effects stay `false`; per-object nav command items and custom-object base fields are `true`). - **Read-only GraphQL exposure** of `isSystemSideEffect` on the view / view-field / page-layout / tab / widget / command-menu-item DTOs (not exposed on create/update inputs). => Todo: needs to take this new flag into account. This is fine for now because isSystem remains on object/field. - **Fast instance command** (`2-14`) adding the 8 columns (`NOT NULL DEFAULT false`). ## Scope decisions - **`pageLayout` is not an `OverridableEntity`**, its own row has nothing user-overridable (all customization lives on tabs/widgets). It's dual-purpose (`RECORD_PAGE` side-effect vs. user `DASHBOARD`), so it gets `isSystemSideEffect` for protection only, no `overrides` jsonb. - **`navigationMenuItem` is out of scope.**: Those are side effects only for the metadata API and not marked as "system" (they can be deleted/updated etc...) - **`viewFieldGroup` is not a side effect**, it's only created via the explicit view-field-group API, never by object/field creation, so it gets no flag. ## Out of scope (follow-ups) **PR 2** — slow per-workspace backfill (re-own + flag existing side effects, recreate missing ones) and deterministic v5 identifiers for base fields / pageLayout / tab. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21673?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-17 15:56:27 +02:00
Charles Bochet	34362de7b7	fix(route-trigger): distinguish user vs platform logic function execution errors (#21715) ... ## What Splits route trigger logic-function failures into two cases instead of one catch-all: - **User error** — the function's own code threw an uncaught error. Returns `500` and is **not** sent to Sentry. - **Platform error** — an infrastructure/execution failure on our side. Returns `500` and **is** sent to Sentry. A disabled logic function now returns `403`. ## Why User-code failures were flooding Sentry: a single workspace's function hitting a transient upstream error generated tens of thousands of events. #21656 stopped the flood by muting the entire route-trigger execution error bucket — but muting everything also silenced genuine platform failures we *do* want to be alerted on. Splitting the bucket keeps the user-code noise out of Sentry (the original goal) while making sure real platform errors still surface. Users who want to return a specific status/body when their function fails can still catch the error and return a `Response` — that path is unchanged. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21715?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-17 12:45:04 +02:00
Félix Malfait	bb6da7b7d1	feat(code-interpreter): reuse a warm sandbox per conversation (E2B) (#21664) ... ## What The E2B code-interpreter driver created a **fresh sandbox on every execution** and killed it in `finally`, so every call in a conversation paid full cold-start and started blank. This PR keeps **one warm sandbox per conversation** and, on idle, **pauses** it rather than killing it. ## How - **Discovery without a registry:** the sandbox is tagged with the chat `threadId` (scoped `workspaceId:threadId`) via E2B **metadata**, found with `Sandbox.list({ query: { state: ['running','paused'], metadata } })` and resumed with `Sandbox.connect()` (which auto-resumes a paused sandbox). E2B is the source of truth — no Redis/DB mapping. - **Pause/resume (E2B 2.x):** session sandboxes are created with `lifecycle: { onTimeout: 'pause', autoResume: true }`. When idle they **pause** — compute billing stops, filesystem **and** kernel/memory state are preserved — and resume in ~1s on the next call. This replaces the earlier keepalive approach. - **No premature pause mid-run:** the sandbox is kept alive for `max(execution timeout, idle window)`, so a long execution is never paused underneath itself. - **Tenant isolation:** discovery filters by the `twentySessionId` tag and **re-checks it client-side**, so a loose server-side match can never hand one conversation's warm sandbox (with its files, kernel state, token) to another. - **Concurrency:** executions sharing a session are serialized in-process (one active stream per thread, run as a single job — the chat resolver queues concurrent messages), so parallel tool calls can't race the shared kernel. - **Output isolation:** `/home/user/output` is reset at the start of each reused run, so a call only returns the artifacts it actually produced; durable state lives elsewhere and persists. ## SDK upgrade `@e2b/code-interpreter` **`^1.0.4` → `^2.6.0`** (pulls `e2b@2.x`). The typed pause/resume API, `lifecycle`, and the `state`/`metadata` list filter only exist in the 2.x line; 1.x exposed them only as untyped OpenAPI internals. `Sandbox.list()` is now a paginator (handled). ## Config | Var | Default | Purpose | |---|---|---| | `CODE_INTERPRETER_TIMEOUT_MS` | `300000` | Max single-execution duration. | | `CODE_INTERPRETER_IDLE_TIMEOUT_MS` | `300000` | Idle window before the warm sandbox auto-pauses. | Reuse is always-on when a session id is present (chat path). The workflow-agent path and the dev-only `LocalDriver` are unaffected. ## ⚠️ Open item before merge: paused-sandbox GC E2B retains paused sandboxes **indefinitely** (no TTL). Unlike the old keepalive path (which auto-killed on idle), pause means a conversation's sandbox persists after the chat ends — so without garbage collection, paused sandboxes accumulate (≈ one per historical conversation) and consume storage. A GC policy is required; the approach + retention window are being decided (see PR discussion). Also: the E2B runtime path can't run in CI, so this still needs a **live smoke test** (reuse hit, idle→pause, resume) and confirmation of paused-storage pricing before rollout. ## Tests / checks - Resolver unit tests (`getOrCreateSessionSandbox`): reuse+extend, create-when-absent, duplicate reaping, connect-failure fallback, keep-first-connectable-when-earlier-dead, **ignore cross-tenant metadata**, and **kill-on-timeout-refresh-failure**. - `nx typecheck twenty-server` (against e2b 2.x), `oxlint --type-aware`, `oxfmt --check` all clean. --------- Co-authored-by: Claude <noreply@anthropic.com>	2026-06-17 08:12:24 +00:00
neo773	d8d5991977	fix(messaging): honor IMAP/SMTP encryption setting instead of inferring it from the port (#21562) ... This pull request makes the IMAP and SMTP encryption setting actually honor what the user selects. As per spec there's 3 modes: SSL/TLS (implicit TLS from the start), STARTTLS (it will attempt TLS but if the server doesn't support it, it gracefully falls back to plaintext), NONE (plaintext) Current implementation had a boolean flag for this, this replaces it with the 3 modes Upgrade command to migrate all existing accounts, to not risk breaking anyone's existing account in production we map each account to the mode that matches its current behavior, so nothing changes on the wire /closes #21300 <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21562?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-16 18:09:04 +02:00
Weiko	f0c3883fd1	fix(command-menu-item): persist overrides after save and add reset-to-default (#21623) ... ## Context Command menu items are an overridable entity (like page-layout / FIELDS widgets), but the override flow in layout-customization mode was broken: - **Move / pin-unpin / hide-label didn't persist.** `useSaveCommandMenuItemsDraft` fired the `updateCommandMenuItem` mutations (backend persisted correctly) but never wrote the result back into `metadataStoreState`, the source the live menu and edit panel read from. So the UI reverted on exit and changes only showed after a hard reload. - **No true "reset to default".** Existing reset controls only reverted the draft to the last-saved values (which still contained overrides). there was no way to clear overrides back to the original values after a save. Notes - removed the footer "Reset to default" button. This is not clear to me how we want to build, let's re-implement better in the next version - reset are done on click and not delayed on the save. This is similar to other reset to default on page layouts where we actually usually reload the component and this is because the FE has no idea what's original VS override from the response itself <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21623?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-15 18:10:42 +02:00
Charles Bochet	0a99f784eb	fix(front): dedupe morph relation fields in view field pickers (#21580) ... ## Issue Reported in quality-feedbacks: **"Issues with morph relation view field"** — a morph relation column added to a view **disappears after refresh** (and can be added several times). ## Root cause — the SSE metadata sync A morph relation is stored as **one `fieldMetadata` row per target object**, all sharing a `morphId`. Collapsing those rows into the single field that represents the relation is a **read-time projection** in the server's `objects.fieldsList` resolver — it is *not* a storage invariant, and the rows are never merged. The frontend metadata store is kept in sync with the raw rows **one row at a time over SSE** (`MetadataStoreSSEEffect`): every metadata change broadcasts a single created/updated record that's pushed straight into the store. Creating a morph relation creates N rows (one per target), so **N `create` events arrive and N raw sub-fields land in the store — bypassing the `fieldsList` projection entirely.** The view-field pickers read straight from that store, so they saw the morph relation **once per target**. Each could be added as a column referencing a different sub-field id; after a refresh the view reloads from the projected (deduped) data, the non-survivor columns no longer resolve, and they disappear. ## Fix & architecture note Because the store deliberately mirrors raw rows (that's what the SSE sync maintains), the fix applies the **same read-time projection on the client** — deduping morph rows by `morphId` in `useActiveFieldMetadataItems` — rather than filtering rows at each insert path (SSE, optimistic create, …). This matches how the backend already models morph fields and is robust regardless of which path delivered the rows. The survivor-selection rule (which sub-field id represents the relation) now lives in `twenty-shared` (`pickMorphGroupSurvivor`) so client and server can't drift.	2026-06-15 11:56:35 +00:00
Manish Kumar	25b0e4d81c	fix: #19173 correct labels and icons for custom object default relations (#19224) ... **### Problem** When creating a custom Data Model object, the auto-generated Note and Task relations had incorrect labels ("Note Targets", "Task Targets") and a wrong hardcoded icon (IconBuildingSkyscraper). Expected behavior is to use user-friendly labels ("Notes", "Tasks") and proper icons, consistent with standard objects like Company and Person. **Root causes:** * `icon` in `createFieldInput` was hardcoded to `'IconBuildingSkyscraper'` * `label` was derived from `targetFlatObjectMetadata.labelPlural`, which returns system labels (e.g., "Note Targets") instead of display labels --- **Fix** * Added `sourceFieldOverridesByRelationObjectNameSingular` map to define correct labels and icons for all default relation types * Ensures consistency with standard objects Mappings: * noteTarget: "Note Targets" → "Notes", IconBuildingSkyscraper → IconNotes * taskTarget: "Task Targets" → "Tasks", IconBuildingSkyscraper → IconCheckbox * attachment: "Attachments" → "Attachments", IconBuildingSkyscraper → IconFileImport * timelineActivity: "Timeline Activities" → "Timeline Activities", IconBuildingSkyscraper → IconTimelineEvent * favorite: "Favorites" → "Favorites", IconBuildingSkyscraper → IconHeart * Added type safety using: `satisfies Record<(typeof DEFAULT_RELATIONS_OBJECTS_STANDARD_IDS)[number], ...>` This ensures new default relations must be explicitly defined * Renamed variable: `icon` → `targetFieldIcon` for better clarity (it is only used for the target field) --- **Limitations** * Applies only to newly created custom objects * Existing objects will keep incorrect labels/icons * Requires a separate data migration to fix existing data --- **Testing** 1. Go to Settings → Data Model 2. Create a new custom object 3. Verify: * Labels show "Notes" and "Tasks" (not "Note Targets"/"Task Targets") * Icons match those used in standard objects (e.g., Company, Person) --- ## Update (reworked while merging main) The original approach was reworked: - The label/icon mapping now lives in a shared `STANDARD_RELATION_FIELD_PROPERTIES_BY_RELATION_OBJECT` constant (`msg`-based, so labels stay translatable), used as the single source of truth. Dropped the unused `favorite` entry. - Standard objects now reference that same constant explicitly at each call site (uniformization) instead of duplicating the values. Objects that intentionally differ keep their explicit overrides: note/task → `Relations`, person/workspaceMember → `Events`, workflow attachments → `IconFileUpload`. - Fixed an unrelated typo found along the way: Company's `timelineActivities` icon was `IconIconTimelineEvent`. - For the history (supersedes the "Limitations" above): added a `2.9.0` workspace upgrade command `upgrade:2-9:fix-standard-relation-field-labels-icons` that re-syncs **standard** objects' default relation labels/icons against the source of truth. It deliberately leaves **custom** objects untouched — their relation fields are user-editable and must not be overwritten by an upgrade. ## Testing / Verification Verified locally end-to-end: **New custom objects** - Created a custom object via the Data Model UI and via the metadata API — its note/task/attachment/timeline relations now show `Notes` / `Tasks` / `Attachments` / `Timeline Activities` with the correct icons instead of `Note Targets` + `IconBuildingSkyscraper`. **Standard uniformization (value-preserving)** - Re-seeded a workspace on this branch and inspected all 25 default-relation field definitions across the 10 standard objects: every canonical value is unchanged, every intentional variant (Relations / Events / IconFileUpload) is preserved, and the only diff vs `main` is the Company `IconIconTimelineEvent` → `IconTimelineEvent` fix. **Upgrade command (existing workspaces)** - Simulated a real upgrade: seeded a workspace on `main` (Company icon typo present), created a custom object via the metadata API (it came out with the old buggy labels, as expected on `main`), then switched to this branch and ran the command. - Confirmed via both the metadata API and direct DB inspection: Company's standard `timelineActivities` icon healed to `IconTimelineEvent`, while the custom object's relations were left untouched. - Idempotent: re-running reports "already up to date". **CI**: typecheck, lint, server unit tests, and all server integration-test shards green. --------- Co-authored-by: Manish Kumar <manishkumar@Mac.lan> Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-14 21:06:58 +02:00
Félix Malfait	c05f01f2a3	fix(server): repair 2.13 isUIReadOnly→isUIEditable rename fallout (#21504) (#21537) ... ## Context Follow-up to #21504 ("Rename isUIReadOnly to isUIEditable, add isUICreatable…"), which surfaced two issues: 1. **`column FieldMetadataEntity.isUIReadOnly does not exist`** on twenty-main.com. 2. **`cross-version-upgrade` CI failure** — `SyncStandardUiCapabilityFlags` aborts the v1.22 → 2.13 upgrade. ## Fix 1 — don't drop `isUIReadOnly` in the 2.13 rename command The 2.13 fast instance command physically dropped `isUIReadOnly` from `core."fieldMetadata"` and `core."objectMetadata"`. But migrations run in an ArgoCD **PreSync** hook **before** the new pods roll out (`charts/prod-eu/apps/twenty-server` migration Job is `hook: PreSync`, sync-wave `2`; the api/worker Deployments are sync-wave `10`). So the **previous** release's pods keep serving and still `SELECT isUIReadOnly`, throwing `column ... does not exist` from the moment the column is dropped until the rollout finishes. This keeps the column (already hidden from the app via `@WasRemovedInUpgrade` on both entities) and **defers the physical drop** to a later release. Since 2.13 hasn't shipped to self-hosters yet, the committed command is amended in place. Both tables handled; `isUICreatable` (new, additive column) is unaffected. The eventual physical drop + GraphQL-compat removals are tracked in twentyhq/core-team-issues#2542. ## Fix 2 — allow `isUIEditable` updates on relation field metadata `SyncStandardUiCapabilityFlags` re-syncs `isUIEditable` on standard fields, including morph/relation fields (the activityTargets `target*` relations). The flat-field-metadata validator only permits a fixed property allow-list on relation fields, which omitted `isUIEditable`, so the command failed with `FIELD_MUTATION_NOT_ALLOWED` and aborted the upgrade (leaving workspaces in a FAILED state). `isUIEditable` is a per-field UI-affordance flag that applies to relation fields too, so it's added to the relation-field updatable properties (a constant used **only** by that validator — no diff-engine side effects). ## Coherence notes - Object-level is covered: the drop is deferred on **both** tables, and `ObjectMetadataEntity` has the identical decorators. - `isUICreatable` needs no change: object-only and additive (no drop → no rolling-deploy hazard), and never reaches the field relation allow-list. - The object-metadata validator has no relation allow-list, so there's no object-level analog to change. ## Verification - `nx typecheck twenty-server` ✅ (the `satisfies` guard holds — `isUIEditable` is a `toCompare` property of `fieldMetadata`) - `oxlint --type-aware` + `oxfmt --check` ✅ on changed files - Fix 2's path is exercised end-to-end by the `cross-version-upgrade` CI that originally caught it. --------- Co-authored-by: Claude <noreply@anthropic.com>	2026-06-14 05:51:23 +02:00
Alexandre Ribeiro	fefb6cdb94	feat(page-layout): add number format option to aggregate chart widget (#21521) ... ## Context Closes #21522 Large values in the dashboard **Number** widget are always abbreviated (e.g. `1300090` → `1.3m`) with no way to display the full number. Following a discussion with the core team who were interested in this feature (https://discordapp.com/channels/1130383047699738754/1509604545381142649) , this adds a **Format** option in the **Style** section of the Number (aggregate chart) widget, letting users choose between **Short** (abbreviated, current behavior) and **Full** (complete number with thousand separators). Only the displayed value of the Number widget is affected — axes, labels and tooltips of other chart types are intentionally left untouched. ## What's inside **Server** - New `ChartNumberFormat` GraphQL enum (`SHORT` / `FULL`), following the `AxisNameDisplay` pattern - The existing — and previously unused — `format` field on `AggregateChartConfigurationDTO` is now typed with this enum and validated with `@IsEnum` - The dashboard AI tool schema (`widget.schema.ts`) accepts the new `format` option - Regenerated GraphQL types and the `twenty-client-sdk` metadata client to reflect the enum **Front** - New **Format** setting in the Style section of the Number widget settings, with a Short/Full selection dropdown (same pattern as the Axis name setting) - `transformAggregateRawValueIntoAggregateDisplayValue` takes an optional `numberFormat`: - `FULL` → full number via `formatNumber` (currency values keep up to 2 decimals) - `SHORT` → abbreviated via `formatToShortNumber` - not set → behavior unchanged (currency short, number full), so existing widgets and the record table/board footers render exactly as before ## Screenshots | Full UI Look | <img width="1917" height="955" alt="Twenty_Showcas_FullShort" src="https://github.com/user-attachments/assets/05d05779-395d-4e1a-8ff0-964f6fbef182" /> | Menu UI Look | <img width="291" height="308" alt="Screenshot_2" src="https://github.com/user-attachments/assets/82b5a1de-32fe-46ec-a9b8-add11ab4c6cd" /> ## Tests - Extended `transformAggregateRawValueIntoAggregateDisplayValue` unit tests with SHORT/FULL cases for currency and number fields - Updated the page-layout-widget creation/update integration tests and snapshots to use `ChartNumberFormat.SHORT` <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21521?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-13 23:32:41 +02:00
neo773	5d892bdfd0	[WIP] Feat/marketing emails (#21173) ... Marketing/campaign emails on top of the emailing-domain (SES) feature: send a broadcast to a hand-picked list, with per-customer-domain unsubscribe links and opt-out-only **unsubscribe topics**. ## Model Standard objects (workspace schema, flat-metadata): - `messageCampaign` — a campaign send (subject, body template, from address, status, list, optional unsubscribe topic). - `messageList` + `messageListMember` — the hand-picked audience (person ↔ list join). A campaign's recipients are its list's members; everyone is sendable unless suppressed. Core entities (`core` schema, workspace-scoped — readable by the public unsubscribe flow without a workspace context): - `unsubscribeTopic` — an opt-out-only category (name, description, visibility). There is no opt-in subscription state. - `messageSuppression` — the single consent store: a row with `unsubscribeTopicId` NULL is a global block; a row with an `unsubscribeTopicId` and reason `UNSUBSCRIBE` is a per-topic opt-out. Two partial unique indexes dedupe global vs per-topic rows (Postgres treats NULLs as distinct). - `emailingDomain` — the workspace's SES sending domain, auto-provisioned when an email channel is added (and cleaned up when its last channel is removed), with verification status + DNS records. Campaign messages reuse the existing `message` / `messageThread` / `messageParticipant` model — one outbound `message` per recipient with a `deliveryStatus` state machine. ## Sending - `sendMessageCampaign` resolves the audience **under the caller's permissions**, creates the campaign, and enqueues a single fan-out job (the request never materializes per-recipient rows or jobs). - The fan-out job materializes one QUEUED message per recipient (deterministic ids → idempotent re-runs, reconciles crash-orphaned rows) and fans out per-recipient send jobs carrying **only ids**. - Each send job renders per-recipient `{{variable}}` merge fields and sends via `EmailingDomainSenderService`, which applies suppression (global + per-topic) and the unsubscribe footer/headers. Suppressed recipients are recorded `SKIPPED`. - The campaign finalizes `SENT`, or `SENT_WITH_ERRORS` if any recipient terminally failed. - `previewMessageCampaignAudience` returns a pre-send breakdown (total / without-email / duplicate / globally-unsubscribed / topic-unsubscribed / sendable), shown as a hint under the composer pickers. ## Unsubscribe - Encrypted (AES-256-GCM) token carrying workspaceId, address, optional `unsubscribeTopicId`, `issuedAt`, and a `preview` flag. - One-click POST (RFC 8058) + `mailto:` — topic-scoped when the token carries a topic, global otherwise. - Preferences page: a checkbox per visible topic (checked = still receiving); submitting creates per-topic opt-outs for unchecked topics and lifts re-checked ones (UNSUBSCRIBE only — never `BOUNCE`/`COMPLAINT`, never a global block). - A **Preview** action in settings opens the live page via a preview-claim token; opt-out POSTs are no-ops for preview tokens, so previewing never mutates state. - SES webhooks: inbound unsubscribe + outbound bounce/complaint → suppression (race-safe against at-least-once delivery, with reason escalation that never downgrades). - Per-customer unsubscribe hostname (Cloudflare DNS); sends are gated on it being active, except in LOG/demo mode. ## Architecture Campaign orchestration, suppression, the sender, the unsubscribe controller, and the SES webhook handlers live in `src/modules/emailing` + `src/modules/messaging-webhooks` (the workspace-feature layer). `core-modules/emailing-domain` keeps the SES driver, domain provisioning, the `unsubscribeTopic` / `messageSuppression` core entities, and the unsubscribe token/hostname plumbing. Domain creation is validated (`CreateEmailingDomainInput` — domain-format regex, lowercased) before any value reaches SES or the unsubscribe hostname. ## Frontend - Campaign composer side panel (from / list / unsubscribe topic / subject / body) with a live audience-preview hint. - Email settings: email channels each showing their auto-provisioned sending domain in a single section (status + DNS records + a "Check verification" action), plus an **Unsubscribe Topics** section to create/manage topics and preview the recipient page. A demo-mode banner is shown when the LOG driver is active. --------- Co-authored-by: Félix Malfait <felix@twenty.com> Co-authored-by: Félix Malfait <felix.malfait@gmail.com>	2026-06-13 18:37:39 +02:00
Félix Malfait	76f69efb43	Keep synced messages and events when removing a workspace member (#21443) ... ## Context Removing a workspace member deletes their connected accounts, which cascades into deleting every message and calendar event those accounts synced. For a CRM, losing the email history of departed teammates is a big deal. ## What this does Connected accounts are now kept and reassigned instead of deleted when a member is removed: - Ownership moves to the acting user (whoever removed the member). When members remove themselves (leave workspace, account deletion), it falls back to the oldest admin. - OAuth tokens are revoked, credentials wiped, message/calendar channels get `isSyncEnabled = false`, and the account is stamped with a new `archivedAt` column (fast instance command included). - Synced messages, threads and calendar events stay in the workspace. Channel visibility settings keep applying as before, since channels and associations survive. - The reassigned account appears in the new owner's Settings → Accounts, where it can still be deleted (with its data) like any other account. The transfer happens synchronously during removal, while the member's userWorkspace row still exists. This also removes `DeleteWorkspaceMemberConnectedAccountsCleanupJob` and its listener: the async job had to reconstruct the account-owner link from rows the removal flow had just deleted, which was race-prone (see 2181fb541e). Archived accounts are excluded from the workflow send-email default account resolution, and both removal confirmation modals now mention what happens to synced data. --------- Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>	2026-06-13 15:52:13 +02:00
Weiko	f63f053444	CommandMenuItem overridable entity (#21486) ... ## Context Second PR of the overridable-entities track (after #21436 for views): command menu items become overridable so that edits on non-owned items are stored as overrides instead of mutating the row, and deletion/deactivation becomes reversible. ## What this does - `CommandMenuItemEntity` now extends `OverridableEntity<CommandMenuItemOverrides>` (adds `isActive` + `overrides`). All editable properties are overridable for now (to discuss). - **Update**: mutations on a command item not owned by the caller (standard items) are written into `overrides`; reads merge them in the DTO. The command palette edit mode (pin, reorder, shortLabel) now preserves standard values, "Reset label to default" gains true post-save semantics. - **Delete**: protected items are deactivated (`isActive = false`) instead of deleted; custom items still hard-delete. - **Object deactivate/enable toggle**: now flips `isActive` on the command item (merged into the main migration call) instead of delete/recreate; a create-if-missing fallback covers legacy deactivated objects. - **Front**: inactive command items are filtered out of the palette selector. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21486?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-13 14:21:27 +02:00
neo773	d2fbc165b6	fix(messaging): emit channel and account deletion events from core metadata services (#21491) ... /closes #21425 <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21491?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-13 13:33:37 +02:00
Félix Malfait	1efa3567ef	Rename isUIReadOnly to isUIEditable, add isUICreatable, expose both to app developers (#21504) ... <!-- CURSOR_AGENT_PR_BODY_BEGIN --> # UI capability flags: `isUIEditable` + `isUICreatable` ## Per-verb capability model This PR replaces the negative `isUIReadOnly` metadata flag with positive, per-verb capability flags (à la Salesforce `createable`/`updateable`): - **`isUIEditable: boolean`, default `true`** — rename of `isUIReadOnly` with inverted polarity, on **both** `objectMetadata` and `fieldMetadata`. It is one concept ("can the user edit this through the generic UI?") at two altitudes, so it carries one name at both levels. - **`isUICreatable: boolean`, default `true`** — new, **object-level only** (fields have no create verb). When `false`, no generic UI affordance to create a record of this object appears anywhere (table "+" buttons, board column add, calendar add, relation-section "Add new", record picker "Add new", command-menu create action and its keyboard shortcut). Both flags are **UI-affordance flags only**: the server does not block create/edit mutations based on them, so the system, API, and workflows continue to mutate these records freely. They are orthogonal statements about the object's nature with no implication rule in the data model. Because today's inline creation UX creates a blank record the user must then edit, the frontend create predicate currently requires both `isUICreatable` and effective editability. There is no CREATE permission in `ObjectPermissions`; the frontend keeps gating creation on `canUpdateObjectRecords` as a proxy, ANDed with the new flags. ## Unified create predicate All generic creation entry points now flow through one predicate, `canCreateRecordsForObjectMetadataItem` (`isUICreatable` && not `isSystem` && not effectively read-only, where effective read-only covers `isUIEditable`, `isRemote`, and the `canUpdateObjectRecords` proxy via `isObjectMetadataReadOnly`). This deletes the previously hardcoded suppression lists: - `isRecordTableCreateDisabled.ts` and its hardcoded `WorkflowRun`/`WorkflowVersion` list — deleted; those objects (plus `workspaceMember`) now declare `isUICreatable: false` in the standard application instead. - The hardcoded `workspaceMember` guard inside `useAddNewRecordAndOpenSidePanel.ts` — deleted. - The `CREATE_NEW_RECORD` command menu item's availability expression now checks `objectMetadataItem.isUICreatable`, `isUIEditable`, `isSystem`, and `isRemote`; a workspace upgrade command re-syncs the expression in existing workspaces. Component-local conditions (soft-delete filter active, layout customization mode) stay in their components. ## GraphQL compatibility and removal plan The schema delta versus main is **purely additive plus deprecations — zero breaking changes**: - `isUIReadOnly` remains on both the ObjectMetadata and FieldMetadata GraphQL output types for **one release** as a deprecated field computed as `!isUIEditable` (`deprecationReason: 'Use isUIEditable'`). The Twenty frontend no longer queries it. - `isUIReadOnly` also remains on the **input side** for one release (`CreateFieldInput`, `UpdateFieldInput`, `FieldFilter`, `ObjectFilter`), keeping the schema shape identical to main for those members. On create it acts as a legacy alias mapped to `!isUIReadOnly` (`isUIEditable` wins when both are provided); on update it is ignored, exactly as on main (it was never an editable property). Filtering on the deprecated member keeps working until the column is dropped at upgrade time; after that it is a deprecated no-op surface kept only for schema compatibility. **Removal plan for next release: drop `isUIReadOnly` from the output DTOs (and resolvers' `@ResolveField`s), from the input/filter types, from the create-input mapping, and the `@WasRemovedInUpgrade`-retained entity columns and decorators.** ## ⚠️ Webhook / database-event payload shape change The `database-event-payload` type in `twenty-shared` got a clean rename (no alias): metadata snapshots in webhook and database-event payloads now carry `isUIEditable` (and `isUICreatable` at object level) **instead of** `isUIReadOnly`, with inverted polarity. Consumers of these payloads that read `isUIReadOnly` must switch to `isUIEditable`. ## New manifest properties (app-developer DX) Application developers can now set these flags in their app manifests (purely additive — existing manifests and older `twenty-sdk` versions are unaffected, defaults apply when omitted): - `objects[].isUICreatable?: boolean` (default `true`) - `objects[].isUIEditable?: boolean` (default `true`) - `fields[].isUIEditable?: boolean` (default `true`) The manifest converters previously hardcoded `isUIReadOnly: false`; they now read the manifest values with `?? true` defaults. The types are re-exported through `twenty-sdk` from `twenty-shared`. ## Migration & backfill - One fast instance command: adds `isUIEditable` (NOT NULL default `true`) on `core."objectMetadata"` and `core."fieldMetadata"`, backfills `isUIEditable = false` exactly where `isUIReadOnly = true`, drops `isUIReadOnly`, and adds `isUICreatable` (default `true`) on `objectMetadata`. The `down` is the exact inverse. Uses `ADD/DROP COLUMN IF (NOT) EXISTS`, matching the 2-12 drop-`isCustom` precedent. Verified up and down in separate transactions against a dev database with exact backfill counts. - **Cross-version upgrade safety (multi-version self-hosted jumps):** the upgrade sequence interleaves per version (instance → workspace commands), so pre-2.13 workspace commands run **before** the 2.13 rename when an old instance jumps several versions. Following the `isCustom` precedent: `isUIEditable`/`isUICreatable` are marked `@WasIntroducedInUpgrade` and `isUIReadOnly` stays on both entities as `@WasRemovedInUpgrade`, so the upgrade-aware entity metadata adapter hides the not-yet-existing columns (and keeps the legacy column live) at pre-2.13 cursors. **No committed upgrade command outside the 2-13 directory is modified**: the old 1-21/2-8/2-9 commands keep their original `isUIReadOnly: true` inputs, which still compile (entity property retained, deprecated create-input alias mapped) and still produce the correct legacy column writes pre-rename. - A 2-13 workspace command (`sync-standard-ui-capability-flags`) re-syncs `isUICreatable` **and** `isUIEditable` on standard objects and `isUIEditable` on standard fields from the standard-application definitions. This backfills `isUICreatable: false` on `workflowRun`/`workflowVersion`/`workspaceMember` and heals fields created mid-cross-upgrade by pre-2.13 commands (whose hidden `isUIEditable` value cannot reach the insert). Both 2-13 sync commands pass `isSystemBuild: true` — the flat metadata validator otherwise rejects direct updates to system objects (verified against a deliberately drifted dev database; the run is idempotent). - A second 2-13 workspace command re-syncs the create-record command availability expression. ## Testing - Unit tests for `canCreateRecordsForObjectMetadataItem` (flag/permission/system combinations) and for the manifest converters (flags set / omitted → defaults). - Full `upgrade --dry-run` boots the sequence (107 steps) and validates the upgrade-aware decorator references; both 2-13 sync commands verified end to end against real drift and re-run idempotently. - Schema verified by live introspection after the input-alias restore: all four input/filter members match main, output deprecations intact; frontend metadata types and `twenty-client-sdk` schema regenerated from the running server. - Read-only-related and touched jest suites pass on both packages; typecheck and lint pass on `twenty-server` and `twenty-front`. <!-- CURSOR_AGENT_PR_BODY_END --> <div><a href="https://cursor.com/agents/bc-0f3e04cb-b04a-40be-8330-5609c4538e8a"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-web-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-web-light.png"><img alt="Open in Web" width="114" height="28" src="https://cursor.com/assets/images/open-in-web-dark.png"></picture></a>&nbsp;<a href="https://cursor.com/background-agent?bcId=bc-0f3e04cb-b04a-40be-8330-5609c4538e8a"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-cursor-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-cursor-light.png"><img alt="Open in Cursor" width="131" height="28" src="https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a>&nbsp;</div> <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21504?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com>	2026-06-13 07:10:22 +02:00
Charles Bochet	9bb98fa5b5	fix(billing): don't crash when workspace has no active subscription (#21510) ... ## Problem Sentry (high severity, SLA-breaching): `Billing Subscription Not Found: No active subscription found for workspace …` The `billingSubscription` workspace-cache provider (`WorkspaceBillingSubscriptionCacheService.computeForCache`) called `getCurrentBillingSubscriptionOrThrow`. For a workspace whose subscription is fully canceled, `getCurrentBillingSubscription` filters out `Canceled` and returns `undefined`, so the provider **threw** `BILLING_SUBSCRIPTION_NOT_FOUND`. That cache key is read on every usage-recording path: - workflow execution (`WorkflowExecutorWorkspaceService.sendWorkflowNodeRunEvent`) - AI usage (`AiBillingService`) - logic-function execution (`LogicFunctionExecutorService`) - app charges (`AppBillingService`) - the gate `BillingUsageService.canFeatureBeUsed` / `hasAvailableCredits` / `decrementAvailableCreditsInCache` - the cancellation webhook (`invalidateAndRecompute('billingSubscription')`) So any of these throws an unhandled exception for a no-active-subscription workspace. The intent was clearly to tolerate this state — `canFeatureBeUsed` already guards with `isDefined(billingSubscription)` and the workflow runner logs *"there is no subscription for this workspace"* — but the throwing provider made those guards unreachable. ## Fix - `computeForCache` now returns `FlatBillingSubscription | null` via the non-throwing `getCurrentBillingSubscription`, and the cache type allows `null`. - Every consumer guards the absent case (`isDefined` / optional chaining) and no-ops: usage events still emit with an undefined `periodStart`, credits aren't decremented, `hasAvailableCredits` returns `false`. - `getCurrentBillingSubscriptionOrThrow` is **left untouched** for the many callers (resolver, subscription-update, etc.) that genuinely require a subscription. ## Test Adds `workspace-billing-subscription-cache.service.spec.ts`: the provider returns `null` when there's no active subscription (regression) and the flattened subscription when one exists. All 142 tests across the billing / ai-billing / workflow-executor suites pass; `oxlint --type-aware` and `oxfmt` are clean. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21510?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-12 22:47:44 +02:00
Thomas Trompette	ba94c3b857	feat(workflow): idempotent stop + retry failed runs from failing step (#21458) ... https://github.com/user-attachments/assets/5a25396f-8959-4bd8-93cb-1187559ffe5f ## Summary Two workflow-run improvements, with all non-trivial logic isolated in pure, unit-tested utils. ### 1. Idempotent stop `stopWorkflowRun` no longer throws when a run is already in a terminal status (`COMPLETED` / `FAILED` / `STOPPED`) or already `STOPPING`; it returns the run unchanged. This fixes: - bulk stop aborting on the first non-stoppable run in a mixed/select-all selection, - the click-vs-processing race on a single run (run finishes between click and mutation). It also releases the cached not-started throttle slot when stopping a `NOT_STARTED` run (prevents counter drift), and ends runs with no `state` directly. ### 2. Retry a failed run from the failing step New `retryWorkflowRun` mutation (same guards/passthrough as `stopWorkflowRun`). It resets the failed step(s) to `NOT_STARTED`, flips the run to `RUNNING`, and enqueues a `RunWorkflowJob` with the steps to re-execute; downstream execution and status computation are unchanged. Logic lives in pure utils: - `build-retry-step-infos.util.ts` - decides per failed step what to reset; delegates iterator-specific logic to `build-retry-iterator-step-infos.util.ts` (an iterator that failed mid-loop is restored to `RUNNING` with cursor preserved, an iterator that failed itself restarts its whole loop). - `get-runnable-step-ids.util.ts` - reuses the executor's `shouldExecuteStep` to also resume branches that never started (avoids hangs), excluding loop-interior steps. The service method only orchestrates; the job's status check is a race guard (retriability is enforced in the service before enqueue). A "Retry" command menu item surfaces only for `FAILED` runs (`someEquals(selectedRecords, "status", "FAILED")`). ### 3. Keep the run diagram visible across regenerations The run diagram is regenerated on every run state change, producing fresh nodes without the dimensions Reactflow had measured. Reactflow hides unmeasured nodes until it re-measures them, so the diagram could flicker and disappear when the last regeneration before going idle left nodes unmeasured (reproducible after retrying a failed run). The regenerated nodes now carry over the previously measured dimensions (by id) so they stay rendered. ## Test plan - [x] Unit tests for both retry utils (9 cases: plain failed step, non-failed untouched, iterator mid-loop restore, iterator self-failure, frontier parent gating, entry steps, loop-interior exclusion, parallel branches) - [x] `twenty-server` + `twenty-front` typecheck - [x] `lint:diff-with-main` clean for both packages - [x] Manual: retry a failed run repeatedly and confirm the diagram stays visible - [ ] Manual: stop a COMPLETED/mixed selection (no error), retry a failed run and confirm it resumes from the failing step	2026-06-12 15:25:53 +00:00
Weiko	214dc70b67	Fix missing WasIntroducedInUpgrade for overridable view entity (#21483) ... <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21483?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-12 11:33:31 +00:00
github-actions[bot]	e6d730cd75	chore: sync AI model catalog from models.dev (#21476) ... Automated daily sync of `ai-providers.json` from [models.dev](https://models.dev). This PR updates pricing, context windows, and model availability based on the latest data. New models meeting inclusion criteria (tool calling, pricing data, context limits) are added automatically. Deprecated models are detected based on cost-efficiency within the same model family. **Please review before merging** — verify no critical models were incorrectly deprecated. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21476?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: FelixMalfait <6399865+FelixMalfait@users.noreply.github.com>	2026-06-12 09:31:00 +02:00
Félix Malfait	69a7e614ff	fix: restore isCustom gate in metadata label resolvers (#21432) ... ## Context #21228 removed the stored `isCustom` column and, with it, the `isCustom` early-return in `resolveObjectMetadataStandardOverride` / `resolveFieldMetadataStandardOverride`, on the assumption that falling through the `standardOverrides` checks was equivalent. It isn't: custom object/field labels now reach the Lingui lookup. A custom label that collides with a standard catalog string (e.g. a custom field labeled "Status") gets translated for non-English locales against the user's intent, and every other custom label pays a hash + catalog miss — and, in production, an "Uncompiled message detected" warning (#21415) — on each metadata resolution. ## Fix Restore the gate. `isCustom` is no longer stored, so call sites that build the resolver input from flat entities (dataloader, minimal-metadata, view controller, command-menu-item navigation context) derive it via `belongsToTwentyStandardApp`; GraphQL resolvers keep passing DTOs, which already carry the derived value. ## Testing - Unit tests for both resolvers, including a new regression test: a custom label matching a standard catalog entry is returned verbatim, Lingui never called. --------- Co-authored-by: Weiko <corentin@twenty.com>	2026-06-11 16:10:53 +00:00
Weiko	cfb9772179	feat(server): convert view to overridable entity (#21436) ... ## Context Every entity created as a side effect of object creation must support the overridable pattern (`isActive` + `overrides` + override routing) before we can re-own side effects to their true application. Starting with View. viewField, viewFieldGroup, pageLayoutTab and pageLayoutWidget already extend `OverridableEntity`. This PR brings `view` to the same pattern. ## What this does - `ViewEntity` now extends `OverridableEntity<ViewOverrides>` (adds `isActive` boolean + `overrides` jsonb). All editable view properties are overridable; the 3 fieldMetadata foreign keys are converted to/from universal identifiers like viewField's `viewFieldGroupId`. - **Update**: mutations on a view not owned by the caller (e.g. standard views like "All Companies") are written into `overrides` instead of mutating the row. Reads merge overrides in the DTO. - **Delete/destroy**: views not owned by the caller are deactivated (`isActive = false`) instead of deleted. ~~- **INDEX invariant**: `key = INDEX` views can only be created via object-creation side effect. The API now rejects creating, deleting or destroying INDEX views (object-deletion cascade is unaffected). This was not really needed for this migration but was flagged during implementation.~~ - **Front**: views with `isActive = false` are filtered out of the views selector. - Fast instance command adds the two columns (`2-12-instance-command-fast-...-view-overridable-entity.ts`). ## Notes - Custom (caller-owned) views behave exactly as before: direct updates, soft delete. - View-group side effects (kanban groups) are computed on the override-merged view so overridden `mainGroupByFieldMetadataId` works.	2026-06-11 16:00:52 +00:00
Etienne	303c415dd1	fix(ai) - add logs + remove dashboard building (#21440) ... - add logs for thread finishing without agent message - add logs to monitor toolCall token usage - remove dashboard building via AI (before fixing it) - fix Anthropic compute	2026-06-11 12:45:25 +00:00
nitin	20c83e1f86	fix(kanban): preserve scroll on board re-init + propagate same-column reorders via SSE (#20637) ... closes https://discord.com/channels/1130383047699738754/1504130730840821860 https://github.com/user-attachments/assets/d5833031-01c6-4e46-b699-c29c42435a53 ## Summary Fixes two related issues with the kanban (board view) collaboration experience: 1. **Scroll-to-top on every data change** — `triggerRecordBoardInitialQuery` always scrolled the board to the top, even when re-initializing for a single-record data change (SSE echo of your own mutation, a collaborator's update). Scroll reset only makes sense when the dataset itself changes (filter / sort / group). 2. **Same-column reorders by other users did not propagate** — the server's diff function stripped `FieldMetadataType.POSITION`, so position-only updates produced empty `updatedFields` and short-circuited event emission entirely. SSE clients never received them. ## What's in here - **Frontend** — `useTriggerRecordBoardInitialQuery` now exposes a `triggerRecordBoardInitialQueryWithoutScrollReset` variant; data-driven re-inits in `RecordBoardDataChangedEffect` use it, while genuine filter / sort / group changes keep the scroll-resetting `triggerRecordBoardInitialQuery`. `getRecordBoardEffectsForUpdateInputs` classifies each update as `trigger-initial-query` / `reposition-records` / `none`. For position- or group-only changes we skip the re-query and reposition records in place in the store (`useRepositionRecordsOnBoard`), which avoids the flicker and preserves scroll. - **Server** — removes `POSITION` from `objectRecordChangedValues`' strip list, so position-only updates emit a non-empty diff and flow through SSE. Position is now treated as a field like any other across all event consumers (SSE, webhooks, workflows, logic functions); a trigger with an explicit field filter still excludes it.	2026-06-11 07:26:51 +00:00
Charles Bochet	7258722754	security: upgrade @nestjs/graphql 12→13 + @ptc-org/nestjs-query 4→9 (+ @nestjs/config 4) (#21402) ... ## What Upgrades the NestJS GraphQL stack to clear the High **`ws`** alert (GHSA-3h5v-q93c-6h6q) and modernize off two heavily-patched majors. `@nestjs/graphql@13` pulls `ws@8.20.1` (was 8.16.0). This had to be a **coordinated** upgrade: `@ptc-org/nestjs-query@4.2.0` doesn't support `@nestjs/graphql@13`, so all three move together. | Package | From → To | |---|---| | `@nestjs/config` | 3.3.0 → ^4.0.4 | | `@nestjs/graphql` | 12.1.1 → ^13.4.2 | | `@ptc-org/nestjs-query-{core,graphql,typeorm}` | 4.x → ^9.4.0 | ## The tricky bits - **Re-ported the custom `@nestjs/graphql` patch onto v13.** v13 rewrote the schema builder and added its *own* native multi-schema support (`includeModules`, native `clear()`). Twenty's patch (`resolverSchemaScope` + `computeReachableTypes` — the core/metadata/admin split) is re-merged into v13's new `generate(options, includeModules, reachableTypes)` flow, with a link-preserving `storage.clear()` so cross-schema `resolveType` closures keep working. - **Re-ported the `@ptc-org` patch onto 9.4.0**: removes the `@shareable` federation directive from built-in connection/response types, **and** adds a `.js` extension to its extensionless deep import of `@nestjs/graphql` internals — which v13's new `"exports"` map otherwise rejects at runtime (this was the boot blocker). - **`AppTokenService`**: nestjs-query 9 requires custom services to inject their repo and `super(repo)` it (added an `@InjectRepository` constructor). - **`gridPosition` input fields**: dropped the `deprecationReason` (a *required* input field can't be `@deprecated` under the upgraded graphql) — fields keep their original nullability, so the **schema is unchanged**. - **Service specs**: nestjs-query 9's `TypeOrmQueryService` reads the repo's driver/metadata at construction, so the mocked repos now include `manager`/`metadata`. ## Verification - `nx typecheck twenty-server`: **0 errors**; lint clean - Server boots; **all 3 GraphQL schemas** (`/graphql`, `/metadata`, `/admin-panel`) generate and respond `200` - `graphql:generate` for all 3 schemas is **byte-identical** to before the upgrade (the reachable-types re-port is faithful) - **108 service unit tests pass** (incl. all 6 `TypeOrmQueryService` services) - `ws@8.16.0` gone (now 8.17.1 + 8.18.0); `yarn install --immutable` clean ## Note on lodash `lodash@4.17.21` still remains via `zapier-platform-core` (runtime) and `@stoplight/spectral`, so the lodash alert is **reduced but not fully cleared** by this PR — it needs those separate sources addressed (or a resolution).	2026-06-10 15:55:15 +02:00
github-actions[bot]	3c81566d65	chore: sync AI model catalog from models.dev (#21392) ... Automated daily sync of `ai-providers.json` from [models.dev](https://models.dev). This PR updates pricing, context windows, and model availability based on the latest data. New models meeting inclusion criteria (tool calling, pricing data, context limits) are added automatically. Deprecated models are detected based on cost-efficiency within the same model family. **Please review before merging** — verify no critical models were incorrectly deprecated. Co-authored-by: FelixMalfait <6399865+FelixMalfait@users.noreply.github.com>	2026-06-10 09:22:19 +02:00
Weiko	9c66975520	isCustom deprecation for Objects and Fields (#21228) ... ## Context `isCustom` was a legacy denormalized boolean on `ObjectMetadataEntity` and `FieldMetadataEntity`. Now that every metadata row carries `applicationId` (via `SyncableEntity`), "is this custom" is fully derivable, and the stored boolean was a redundant second source of truth that could drift. The real meaning of `isCustom` is **"the owning application is not the twenty-standard application"** — i.e. `!belongsToTwentyStandardApp`. Note this is *not* "belongs to the workspace custom app" as I initially thought: third-party-application objects/fields are custom too. The standard application has a globally stable `universalIdentifier`, so the value derives with no per-workspace lookup. ## Changed ## `isCustom` checks — before → after `isCustom` is no longer a stored column. The table below lists every site that branched on it and how it resolves now. The unifying rule: `isCustom ≡ !isTwentyStandardApplicationUniversalIdentifier(applicationUniversalIdentifier)`. ### Server — behavioural checks | Location | Purpose | Before | Now | |---|---|---|---| | `utils/compute-object-target-table.util.ts` | Physical table name `_` prefix | `computeTableName(nameSingular, objectMetadata.isCustom)` | derives from `applicationUniversalIdentifier` (single source for all table-name callers) | | `twenty-orm/factories/entity-schema.factory.ts` + `…/entity-schema-metadata.type.ts` | ORM table name (hot path) | `object.isCustom` | `object.applicationId !== standardApplicationId` (computed in `buildEntitySchemaMetadataMaps`) | | `twenty-orm/repository/workspace-{delete,soft-delete,update}-query-builder.ts` | Table name for mutations | `computeTableName(nameSingular, objectMetadata.isCustom)` | `computeObjectTargetTable(objectMetadata)` | | `index-metadata/utils/generate-deterministic-index-name-v2.ts` | Index name hash (must stay bit-identical) | `flatObjectMetadata.isCustom` | derives from `applicationUniversalIdentifier` | | `object-metadata/object-record-count.service.ts` | Table name for record count | `computeTableName(nameSingular, isCustom)` | `computeObjectTargetTable(flatObjectMetadata)` | | `workspace-manager/dev-seeder/data/services/dev-seeder-data.service.ts` | Match seed config by table name | `computeTableName(item.nameSingular, item.isCustom)` | `computeObjectTargetTable(item)` | | `commands/workspace-export/workspace-export.service.ts` + `…/utils/generate-workspace-schema-ddl.util.ts` | Export table name (raw entity) | `objectMetadata.isCustom` | `!isTwentyStandard…(objectMetadata.application?.universalIdentifier)` | | `flat-field-metadata/services/flat-field-metadata-type-validator.service.ts` | Block users creating reserved field types | `args.flatEntityToValidate.isCustom` | `!args.flatEntityToValidate.isSystem` | | `api/common/.../common-create-many-query-runner.service.ts` | Don't let client overwrite system `createdBy` | `createdByFieldMetadata.isCustom === false` | `createdByFieldMetadata.isSystem === true` | | `field-metadata/utils/resolve-field-metadata-standard-override.util.ts` | Skip i18n/overrides for custom fields | `if (fieldMetadata.isCustom) return raw` | **removed** — falls through on `isDefined(standardOverrides)` | | `object-metadata/utils/resolve-object-metadata-standard-override.util.ts` | Skip i18n/overrides for custom objects | `if (objectMetadata.isCustom) return raw` | **removed** — same fall-through | | `command-menu-item/utils/build-navigation-interpolation-context.util.ts` | Override context for nav labels | passed `isCustom` into resolver | dropped (resolver no longer needs it) | | `api/common/.../data-arg-processor.service.ts` | `isCustom` for record-position table name | `flatObjectMetadata.isCustom` | derives from `applicationUniversalIdentifier` | | `metadata-modules/minimal-metadata/minimal-metadata.service.ts` | Minimal DTO + override context | `flatObjectMetadata.isCustom` | derives from `applicationUniversalIdentifier` | | `commands/upgrade-version-command/1-23/…backfill-record-page-layouts.command.ts` | Filter to custom objects | `objectMetadata.isCustom` | `!isTwentyStandard…(applicationUniversalIdentifier)` | ### Server — DTO / API population | Location | Before | Now | |---|---|---| | `flat-object-metadata/utils/from-flat-object-metadata-to-object-metadata-dto.util.ts` | passthrough `isCustom` | derives from `applicationUniversalIdentifier` | | `flat-field-metadata/utils/from-flat-field-metadata-to-field-metadata-dto.util.ts` | passthrough `isCustom` | derives from `applicationUniversalIdentifier` | | `object-metadata/utils/from-object-metadata-entity-to-object-metadata-dto.util.ts` (REST) | `entity.isCustom` | `entity.applicationId !== standardApplicationId` | | `field-metadata/utils/from-field-metadata-entity-to-field-metadata-dto.util.ts` (REST) | `entity.isCustom` | `entity.applicationId !== standardApplicationId` | | `dataloaders/dataloader.service.ts` | passed `flatFieldMetadata.isCustom` into override resolver | dropped (resolver no longer needs it) | > REST controllers (`object-metadata.controller.ts`, `field-metadata.controller.ts`) resolve `standardApplicationId` once per request from the cached `flatApplicationMaps`. ### Frontend | Location | Purpose | Before | Now | |---|---|---|---| | `settings/.../SettingsObjectFieldDisabledActionDropdown.tsx` | Whether an inactive field is deletable | `isDeletable = isCustomField` | `isDeletable = isCustomField && !isSystemField` | ### Unchanged (out of scope) `isCustom` on `IndexMetadata` / `View` / `Skill` / `Agent` and their guards still read the persisted column. Breaking change is on the isCustom filter on field and object APIs, this is never used in the FE and unlikely used by external consumers	2026-06-09 13:57:19 +00:00
Marie	c27c8c88b0	Fix various graphs bugs (#21311) ... Some bugs fixed in this PR 1. From UI any field could be chosen to group the query by it, while for instance, RAW_JSON type (eg workflowRun.state) is not supported by PostgreSQL to group a query by. Fix: removed it from the "group by" fields options in FE + in BE --> 2. The BE check existed (isFlatFieldMetadataSupportedInGroupBy) but the signature was malformed: it expected`{ fieldMetadataType, fieldMetadataName, fieldMetadataIsSystem }` while every caller passes a flat field metadata object with type/name/isSystem. So the check is mis-wired — at runtime the destructured props are undefined, making it always return true (validation bypassed). Fixed this. 3. Group by does not work with Morph relations if their direction is ONE_TO_MANY. Added that constraint. 4. Group by with morph relations were broken even for MANY_TO_ONE, because a morph is stored as one field per target (polymorphicOwnerRocket, polymorphicOwnerSurveyResult…), each with its own join column, but the frontend collapsed them into a single polymorphicOwner field — so the backend tried to resolve a non-existent polymorphicOwnerId. Fix: Frontend: added a target picker so you choose the specific morph target (then its sub-field), storing the real per-target field id. Backend: fixed validate-relation-subfield to use the per-target field's own relationTargetObjectMetadataId instead of the multi-target resolver that returned null. 5. (improvement) When an error occured in the query, the graph showed "No data". Updated it to "error". (screenshot 1) 6. When a field used as a filter on a graph is deleted, it is not deleted as a graph filter (which is ok because it would involve parsing all the graph's configuration json to find whether a field is referenced; there is no foreign key), which prevented from further modifying the graph's filters. Fixed this + add an indicator that the filter is can/should be removed (see screenshot 2) 7. "Ambiguous column name" PG error occurs when ordering by "creation date" of a related field, because both objects have createdAt field. Fixed it by adding table alias as prefix. 8. (improvement) While working on #5 I did not understand why we could directly do `"objectMetadataNameSingular"."columnName" `while I expected that for custom objects it would have to be `_objectMetadataNameSingular`. that's simply because we use an alias from the beginning. To add clarity, within groupBy code I replaced `objectMetadataNameSingular` with `objectAlias` everywhere it is indeed inherited from us using objectAlias. <img width="685" height="391" alt="Screenshot 2026-06-08 at 12 01 45" src="https://github.com/user-attachments/assets/f2b15ca5-da39-4114-8188-69f58f3c4cbf" /> <img width="598" height="341" alt="Screenshot 2026-06-08 at 11 53 55" src="https://github.com/user-attachments/assets/66372811-4a37-40d9-b43a-4af51f89b6e6" />	2026-06-09 16:08:22 +02:00
github-actions[bot]	441fe73be5	chore: sync AI model catalog from models.dev (#21353) ... Automated daily sync of `ai-providers.json` from [models.dev](https://models.dev). This PR updates pricing, context windows, and model availability based on the latest data. New models meeting inclusion criteria (tool calling, pricing data, context limits) are added automatically. Deprecated models are detected based on cost-efficiency within the same model family. **Please review before merging** — verify no critical models were incorrectly deprecated. Co-authored-by: FelixMalfait <6399865+FelixMalfait@users.noreply.github.com>	2026-06-09 09:07:26 +02:00
Thomas Trompette	772b807490	fix: prevent deletion of standard fields via API (#21319) ... ## Summary - Adds a server-side guard that rejects deletion of standard fields (`isCustom: false`) in the `deleteOneField` path - The UI already prevents this, but the API had no enforcement, allowing standard fields to be deleted via direct GraphQL calls Without this guard, deleting a standard field like `jobTitle` cascades to drop dependent generated columns (e.g. `searchVector`), leaving the object in a broken state where all subsequent queries fail with "Data validation error." ## Test plan - [x] Call `deleteOneField` with a standard field ID → should return `FIELD_MUTATION_NOT_ALLOWED` error - [x] Call `deleteOneField` with a custom field ID → should succeed as before - [x] UI deactivation of standard fields still works (deactivate != delete)	2026-06-08 16:30:34 +00:00
Etienne	b56fea69aa	fix(ai) - optimize metadata CRUD tools (#21235) ... Reduces output tokens for all 13 metadata tools by (~49%) based on production sampling data. GET tools (field + object metadata) System fields are now returned as compact {id, name, type} instead of the full ~20-key payload (opt-in includeFullSystemFields to get full payload). System objects are similarly compacted to {id, nameSingular, namePlural}. Internal fields the agent never uses (searchVector, deletedAt, position, updatedBy) are excluded entirely. workspaceId and applicationId are hoisted into a response envelope instead of being repeated on every record. Null/default-false properties are stripped from custom field and object payloads (e.g. options: null, settings: null, isUIReadOnly: false). CUD tools (create/update/delete) Create and update field tools now return {id, name, type, label} instead of the full DTO. Create and update object tools now return {id, nameSingular, labelSingular} instead of the full DTO. Delete tools return {id, success: true} instead of the full DTO of the deleted entity. Validation errors are grouped by message — e.g. 10 fields failing the same check produce one line with all names instead of 10 identical lines. Learn schemas (all tools) UUID pattern regex stripped from JSON schemas (keeps format: "uuid"). $schema and additionalProperties: false stripped from all generated schemas. All Zod .describe() annotations and tool descriptions shortened. Skill & tool description updates: All references to the removed list_object_metadata_items tool replaced with get_object_metadata / get_field_metadata across skill instructions, dashboard tools, view filter/sort tools, and MCP server instructions.	2026-06-08 11:55:29 +00:00
neo773	186d5b8faa	revert #21177 (#21284)	2026-06-06 14:49:55 +02:00
Félix Malfait	898713bd49	fix(server): finalize dangling tool calls when persisting agent chat messages (#21276) ... ## Problem Interrupting an AI chat turn mid tool-call batch permanently bricks the thread. Every subsequent message fails with: > Tool results are missing for tool calls toolu_…, toolu_… ## Root cause When the model fires a parallel batch of tool calls, it streams all the calls first, then results come back one by one. If the stream is aborted (user hits stop, credit cutoff, etc.) after only some have resolved, the AI SDK's `onFinish` still fires with the partial assistant message — including tool parts left in `input-available` state (a tool call with no result). `addMessage` persists that message verbatim. On the next turn the history is rebuilt and `streamText` validates it: every `tool-call` must be cleared by a `tool-result` before the next user message, or it throws `MissingToolResultsError` (`ai/dist`, the `MissingToolResultsError` check). The orphaned calls are now in the DB, so the thread fails on every turn from then on. ## Fix Enforce the invariant at the single write chokepoint. Every chat message is persisted through `AgentChatService.addMessage`, so `finalizeDanglingToolParts` runs there once: any tool part still in `input-available` is rewritten to `output-error` ("Tool execution was interrupted.") before mapping to DB rows. `output-error` converts to a real `tool-result`, so the persisted turn is always self-consistent and the next request is valid. Interrupted calls are kept (not dropped) and surfaced as errored rather than perpetually "running" — honest, since a partially-executed call may have committed side effects the model should be able to reconcile. One guard at one point covers every abort source — no read-side patching, no migration, no schema change. ## Caching impact None on the happy path. A completed turn has no `input-available` parts, so the helper is a no-op and the persisted bytes (and therefore the cached prefix) are identical to before. For an interrupted turn, the finalized content is deterministic and written once, so it caches cleanly on the following request and stays stable across later turns — there is no scenario where this invalidates an existing cache entry. Net effect: turns a hard failure into a normally-cached continuation. ## Testing - New unit test covering finalize / no-op cases (7 cases, passing) - `oxlint --type-aware` + `oxfmt` clean on changed files	2026-06-06 11:22:45 +02:00
Félix Malfait	91f2f08995	feat(server): unify workspace-event ingestion behind one EventSink pipeline (#21197) ... ## Why The five event-log streams (`workspaceEvent`, `pageview`, `objectEvent`, `usageEvent`, `applicationLog`) each wrote to ClickHouse through their own fire-and-forget writer (`AuditService`, `UsageEventWriterService`, and the `application-logs` driver), with the per-type knowledge (table names, normalization, access rules) spread across several modules. Three of them reimplemented the same ClickHouse insert, and the read side, the live stream, and the producers lived in different modules under two different names. This consolidates them into one `core-modules/event-logs/` subsystem (emit, write, live, read), with the per-type config in a single registry so adding an event type is roughly one file. The base Logs settings tab and free application logs shipped separately in #21180 (merged). This PR adds the unified backend, the registry, and the viewer's live mode and entitlement gating. ## Pipeline ```mermaid flowchart TB subgraph PROD["Producers"] A["auth, billing, impersonation,<br/>webhook, custom-domain"] U["usage listener"] F["logic-function executor (app logs)"] R["record CRUD (entity events)"] end EM["EventLogEmitterService<br/>createContext().insert* / dispatch()"] EQ(["entityEventsToDbQueue<br/>(existing, shared with timeline)"]) CIE["CreateEventLogFromInternalEvent"] SINK["WorkspaceEventSinkService.ingest()"] C1["ClickHouseEventSink"] C2["ConsoleEventSink"] LIVE["EventLogLiveService.publishWatched()<br/>(presence-gated)"] CH[("ClickHouse, 5 tables, async_insert")] CHAN(["WORKSPACE_EVENTS_CHANNEL"]) RS["EventLogsService (registry-driven read)"] LR["EventLogsLiveResolver"] UI["Settings > Logs"] A --> EM U --> EM F --> EM EM -->|direct| SINK R --> EQ --> CIE -->|ingest| SINK SINK --> C1 --> CH SINK --> C2 SINK --> LIVE -.->|if a viewer is watching| CHAN --> LR --> UI CH --> RS --> UI ``` ## What it does - Producers call `EventLogEmitterService.createContext().insert*()`, which builds a typed `WorkspaceEventEnvelope` and writes it through `WorkspaceEventSinkService` to the configured sinks (ClickHouse, Console) plus a presence-gated live fan-out. Record/CRUD events reach the same sink through the existing `entityEventsToDbQueue`. There is no dedicated queue; ClickHouse `async_insert` batches server-side. Writes are best-effort, as on main today. - `EVENT_LOG_TYPES[table]` is the per-type source of truth: the ClickHouse table, the required entitlement, the free-text filter column, and the row-to-GraphQL mapping. Read row shapes derive from the write rows. - Four modules along their dependency boundaries: `EventLogEmitterModule` (producer API), `EventLogIngestionModule` (sink layer), `EventLogLiveModule` (fan-out), and `EventLogsViewerModule` (the entitlement-gated GraphQL read, which is where billing/enterprise/permissions stay so producers stay light). - Logs viewer: per-table columns, filters (text, date, record), live mode, and an upgrade card that points to Billing on Cloud or the Admin Panel on self-hosted. Application logs are free on every plan; the other four require the `AUDIT_LOGS` entitlement (with a `NO_ENTITLEMENT` fallback to the upgrade card). - Renames `AuditService` to `EventLogEmitterService`, and the generic `Monitoring` event to a typed `Impersonation` event (`level` + `action`). - Removes `UsageEventWriterService`, the `application-logs` driver/module, and `AuditService`'s direct inserts. ## Durability Writes are best-effort, the same as main today (the old writers were fire-and-forget). A dedicated queue was tried mid-PR and removed: `async_insert` already batches server-side, so the queue only added durability, which isn't a requirement right now. The `EventSink` seam keeps a durable transport (e.g. a Redis-Streams buffer) easy to add later without touching producers. ## Out of scope S3 peer sink (seam only), Postgres or any second read path, `ReplicatedMergeTree`, ClickHouse table-schema changes, and the record-data `EVENT_STREAM_CHANNEL` (unchanged, separate concern). ## Testing Unit tests cover the registry definitions and row normalization, the entitlement gating, the envelope builders, and the producers. Integration tests cover the write paths (record create produces an `objectEvent`; the track mutation produces a `workspaceEvent`) and the read/query path across all five tables. Verified with typecheck, lint, a server boot, and GraphQL/SDK codegen.	2026-06-06 10:32:56 +02:00
neo773	bfb83e93b2	fix(metadata): resolve junction targets order-independently during mgration (#21193) ... A junction relation points at a target field on the join object that another action may create later (two junctions into the same join reference each other). The builder validator now also looks up the target in the to be created set, and the runner mints every field id up front so the target resolves regardless of action order, the same way relation pairs are already handled. --------- Co-authored-by: Félix Malfait <felix@twenty.com>	2026-06-05 17:32:25 +00:00
Charles Bochet	20d9244639	fix(server): gate viewFilter.relationTargetFieldMetadataId behind its 2.6 upgrade command (#21267) ... ## Problem Self-hosted upgrades crossing 2.6 (e.g. `2.4 → 2.6/2.9`) can abort with: ``` column ViewFilterEntity.relationTargetFieldMetadataId does not exist at WorkspaceFlatViewFilterMapCacheService.computeForCache at WorkspaceCacheService.recomputeDataFromProvider [UpgradeSequenceRunnerService] Workspace steps ended with 1 failure(s). Aborting ``` This is **Failure #1** from #20841 — the counterpart to the role-permission cache crash fixed in #21257 (Failure #2). Same shape: a workspace **cache recompute runs mid-upgrade and reads schema that the target version's migration hasn't applied yet**. ## Root cause `ViewFilterEntity.relationTargetFieldMetadataId` is added to `core.viewFilter` only at the **2.6.0** cursor (`AddRelationTargetFieldMetadataIdToViewFilterFastInstanceCommand`, ts `1798000005000`). But the workspace cache recompute SELECTs every column of the entity, and it runs during *earlier* (2.5) workspace steps. Unlike `RolePermissionFlagEntity.permissionFlag`, this column has **no `@WasIntroducedInUpgrade` gate**, so the proxy can't hide it — and the SELECT fails when the column isn't there yet. There are three `IF NOT EXISTS` backport commands (2.3/2.4/2.5) meant to add the column sooner, but they use **low timestamps** that sort to the front of their version bundles. An instance whose cursor has already advanced past those positions (e.g. it reached 2.4, or a prior failed attempt advanced it through 2.5 instance commands) treats them as already-applied and **skips them** — so the column is never created, yet the entity keeps selecting it. ## Fix Gate the column with `@WasIntroducedInUpgrade` pointing at the **2.6.0** command that adds it: ```ts @WasIntroducedInUpgrade({ upgradeCommandName: '2.6.0_AddRelationTargetFieldMetadataIdToViewFilterFastInstanceCommand_1798000005000', }) @Column({ nullable: true, type: 'uuid', default: null }) relationTargetFieldMetadataId: string | null; ``` `UpgradeAwareRepositoryProxy` then hides the column from reads while the cursor is < 2.6, so the cache recompute simply omits it — no crash — and it becomes visible once the 2.6.0 command has run (where it's guaranteed to exist). Gating to **2.6.0** specifically (not the earlier backports) is what fixes the cursor-skip case: 2.6.0 is the first point where the column is reliably present regardless of whether the backports ran. Validator-safe: the referenced command resolves to a real step (`computeCommandName` = `${version}_${className}_${timestamp}`), so `validate-upgrade-aware-entity-decorators` accepts it. The existing backport commands are left untouched (committed instance commands). ## Recovery for already-stuck instances This prevents *new* failures. An instance already aborted mid-upgrade needs the column added manually before retrying: ```sql ALTER TABLE core."viewFilter" ADD COLUMN IF NOT EXISTS "relationTargetFieldMetadataId" uuid; DELETE FROM core."upgradeMigration" WHERE status='failed'; ``` then re-run the upgrade on a build that includes this fix. Refs #20841 Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-05 18:56:02 +02:00
Charles Bochet	a3d73740a1	fix(server): guard role-permission cache against stripped permissionFlag relation during upgrade (#21257) ... ## Problem Self-hosted upgrades that jump versions (e.g. `2.4 → 2.7/2.9`) abort with: ``` TypeError: Cannot read properties of undefined (reading 'universalIdentifier') at WorkspaceRolesPermissionsCacheService.hasSettingsGatedObjectPermissions at WorkspaceRolesPermissionsCacheService.computeForCache at WorkspaceCacheService.recomputeDataFromProvider ``` Reported in #20841 (Failure #2). The sequence aborts mid-upgrade and leaves the DB in a half-migrated state. ## Root cause The per-workspace **cache recompute runs at a `2.5.0` workspace step — before the `2.6` schema migrations apply**. At that cursor: - `RolePermissionFlagEntity.permissionFlag` is `@WasIntroducedInUpgrade('2.6.0_LinkRolePermissionFlagToPermissionFlag…')`, so `UpgradeAwareRepositoryProxy` **strips the relation** (`[upgrade-proxy] strip relation RolePermissionFlagEntity.permissionFlag` in the logs) → `permissionFlag` is `undefined`. - `hasSettingsGatedObjectPermissions()` then does an **unguarded** `rolePermissionFlag.permissionFlag.universalIdentifier` → throws. The crash only manifests when a workspace has **≥1 `rolePermissionFlag` row** (custom roles with gated settings perms / SDK `defineRole`). A vanilla seed has an empty table, so `.find()` over `[]` never dereferences anything — which is why it didn't reproduce on a clean instance. A null-safe fallback to the legacy `flag` column used to exist here; it was dropped in #20730. ## Fix Resolve the flag's universal identifier through a small helper that falls back to the legacy `flag` column (only removed in `2.7.0`) when the relation is unavailable: ```ts private getRolePermissionFlagUniversalIdentifier( rolePermissionFlag: RolePermissionFlagEntity, ): string { // The `permissionFlag` relation is stripped during upgrades until the 2.6.0 // cursor (@WasIntroducedInUpgrade), so fall back to the legacy `flag` column. return ( rolePermissionFlag.permissionFlag?.universalIdentifier ?? SystemPermissionFlag[rolePermissionFlag.flag] ); } ``` `SystemPermissionFlag[flag]` yields the same UUID the relation would, so the comparison stays in a single space and the computed permission is exact (not an over-grant). Correct at every transitional cursor: pre-`2.6` (relation stripped → use `flag`), `2.6` (both present → relation wins), post-`2.7` (`flag` removed → relation wins). ## Reproduction & validation Locally jumped a real `2.4.0` DB → `v2.9.0` build via `yarn command:prod upgrade`: | Scenario | Result | | --- | --- | | Empty `permissionFlag` (vanilla seed) | passes (no crash) | | **+1 flag row**, current code | `TypeError … universalIdentifier` → **3 succeeded, 1 failed** | | Same fixture, **this fix** | **16 succeeded, 0 failed**, DB fully migrated to 2.9.0 | `nx typecheck twenty-server` clean; existing cache-service unit tests pass; app boots on the upgraded DB. ## Scope / follow-up This fixes **Failure #2**. **Failure #1** in the same issue (`viewFilter.relationTargetFieldMetadataId` selected before its column exists) is a separate instance of the same theme — cache recompute reading "future" schema before migrations run — and is worth a follow-up. A more durable systemic fix would defer the workspace cache recompute until after all schema-adding migrations; this PR is the low-risk, backport-friendly fix for the immediate breakage. > Note: an earlier bot branch (`sonarly-39738-fixupgrade-guard-role-permission-flag-relation`) proposed the same fallback inline. This PR supersedes it with a named helper + a focused comment. Fixes #20841 Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-05 14:45:17 +00:00
nitin	e485b679ea	[Call Recording] Add standard object (#21158) ... Adds **Call Recording** as a first-class standard object (Twenty's flat-metadata standard-object system), with a hidden junction to calendar events and a backfill command for existing workspaces. Everything is gated behind the `IS_CALL_RECORDING_ENABLED` feature flag. ### What's included - **`CallRecording`**: audio/video files, transcript, status, recording policy, timing, external bot/recording ids. Label identifier is `meetingOccurrenceKey`. - **`CallRecordingCalendarEventAssociation`**: hidden junction linking a recording to a calendar event (dedupes one bot to many subscribers of the same meeting). - Full metadata graph via the flat-metadata builders: fields, indexes, views, view fields/groups, record page layout, and navigation items. - **Metadata-only reverse relation** on `CalendarEvent`: present in standard metadata, omitted from the TS entity class to avoid expanding recursive nested-insert types. - **Upgrade command (2.9.0)** backfilling active/suspended workspaces: - Creates the full graph; idempotent (skips when it already exists). - Moves a colliding custom `callRecording` object aside to `callRecordingOld` (numeric suffix if that name is also taken). - Navigation items (commands) are flag-gated by `universalIdentifier`, so a custom object reusing the name is never gated. ### QA Run locally against existing workspaces (with and without a name collision) and a freshly created workspace: - [x] Backfill, collision: custom `callRecording` renamed to `callRecordingOld`; standard graph created. - [x] Backfill, no collision: standard graph created; unrelated custom object untouched. - [x] Idempotent: re-run is a no-op, with no duplicate metadata and counts unchanged. - [x] New workspace via `init()` produces an identical graph to the backfill (`universalIdentifier` set-diff = 0). - [x] Label identifier (`meetingOccurrenceKey`) holds position 0 in non-widget views. - [x] Nav items gated behind the feature flag; collision-renamed object's nav expression re-pointed to its new name. - [x] Unit tests cover collision name resolution and nav-gating logic.	2026-06-05 13:02:50 +00:00
Félix Malfait	c3dd6b25a6	fix: use canonical oxlint rule id in lint-disable directives (#21253) ... ## What Many `oxlint-disable` / `eslint-disable` directives across the repo carry a corrupted rule id — `@typescripttypescript/<rule>` — most likely a find-and-replace accident that mangled the eslint-era `@typescript-eslint/` prefix. oxlint matches disable directives **loosely by rule name**, so these still suppress in practice (not a silent no-op), but the id is malformed and misleading. ## Change Replace them with the **canonical oxlint id** `typescript/<rule>` — matching the plugin name and rule keys declared in `.oxlintrc.json` — **127 files, 262 directives**: | rule | count | | --- | ----- | | `typescript/no-explicit-any` | 250 | | `typescript/ban-ts-comment` | 6 | | `typescript/no-misused-promises` | 4 | | `typescript/no-empty-object-type` | 2 | - `twenty-server`: 122 files - `twenty-front`: 5 files Comment-only — no code or runtime changes. ## Verification `oxlint --type-aware -c .oxlintrc.json` reports **0 warnings / 0 errors** for both `twenty-server` and `twenty-front`. Every changed line is exactly the id correction inside a disable directive (262 insertions / 262 deletions, no collateral edits). > Addresses the cubic review, which flagged that the canonical oxlint id is `typescript/...` (no `@`). Worth noting the original `@typescripttypescript/` was not actually a silent no-op — oxlint matches these directives loosely by rule name — but `typescript/` is the correct, config-aligned id.	2026-06-05 13:52:32 +02:00