611 Commits

Author	SHA1	Message	Date
Félix Malfait	614bc7b7e6	feat: serve HTTP logic functions on isolated *.withtwenty.com domain (#22045) ... ## Summary Implements [core-team-issues#2473](https://github.com/twentyhq/core-team-issues/issues/2473): serve HTTP-triggered logic functions from a dedicated, **cookieless** public domain (`{workspaceSubdomain}.withtwenty.com`) instead of the same-site `/s/` route, so functions can safely return **arbitrary headers** — custom headers, `Permissions-Policy` (camera/mic/geolocation), `Cross-Origin-Opener-Policy: same-origin`, `Cross-Origin-Embedder-Policy: require-corp`, `Set-Cookie`, etc. The `/s/` route stays the strict, same-site path it is today. **Self-hosting is unchanged** — everything new is gated on `PUBLIC_DOMAIN_URL` being set. ### Why Today user-authored function responses are served same-site with the Twenty app, so the response-header allow-list is restricted to 5 safe headers and request headers are limited to a per-function allow-list. Serving from an origin that shares nothing with `*.twenty.com` removes that constraint safely — the same "user content domain" pattern as GitHub (`*.githubusercontent.com`) and CodeSandbox (`*.csb.app`). ## What's in here **Routing** - The **root-path → `/s` rewrite happens at the nginx ingress**, not in app code. The existing `api-ingress.yaml` already rewrites root paths onto `/s` (host-agnostically) when the edge sets `X-Twenty-Public-Domain: true`, so `*.withtwenty.com` and registered custom public domains are handled by the same mechanism. (An earlier in-app middleware was removed as a redundant, wrong-layer duplicate.) - `WorkspaceDomainsService.resolveWorkspaceAndPublicDomain` recognizes `*.` subdomains, resolves the workspace by subdomain, and returns `isIsolatedOrigin`. Explicitly registered public-domain rows still take precedence and keep their application scoping. The ingress preserves the `Host` header, so this resolution still fires. **Headers (server)** - Isolated origin → all response headers pass through and all request headers are forwarded. Same-site `/s/` keeps the strict allow-lists. (Global CORS already handles preflight/ACAO.) **`/s/` deprecation for new routes (cloud only)** - New `LOGIC_FUNCTION_LEGACY_ROUTE_CUTOFF` config var (ISO date, optional). When `PUBLIC_DOMAIN_URL` is set, functions created on/after the cutoff return **410 Gone** on `/s/` with the new URL. Existing routes and self-hosted instances are untouched. **Frontend education** - `publicFunctionDomain` added to `ClientConfig` (from `PUBLIC_DOMAIN_URL`). - The logic-function **Live URL** now resolves to `https://{workspaceSubdomain}.{publicFunctionDomain}{path}` on cloud, falling back to `/s/` for self-hosting. - Front components call their functions through the SDK (`RestApiClient`), which now targets the isolated domain via the injected `TWENTY_FUNCTIONS_URL`. - New **"Public URL"** section on the application **Settings** tab explaining the isolated domain (shown when the app exposes HTTP-triggered functions). **Docs**: note the `withtwenty.com` domain for external callers in the apps guide. ## Infra prerequisites (not code — needs dashboard work) - Wildcard DNS `*.withtwenty.com` (proxied) + wildcard TLS in the public-domain Cloudflare zone. - Edge (Cloudflare) sets `X-Twenty-Public-Domain: true` for `*.withtwenty.com` requests, so the existing nginx ingress rewrites them onto `/s` (same header the custom-domain flow already relies on). - Set `PUBLIC_DOMAIN_URL=https://withtwenty.com` on cloud. - Submit `withtwenty.com` to the **Public Suffix List** (required for cross-tenant cookie isolation before relying on `Set-Cookie`). ## Test plan - [x] `nx typecheck twenty-server`, `nx typecheck twenty-front` - [x] `lint:diff-with-main` + oxfmt clean (server + front) - [x] `npx jest route-trigger public-function-domain domain-server-config workspace-domains build-logic-function-event client-config` → server unit tests passing (resolution tiers, header passthrough vs allow-list, `/s/` cutoff 410) - [x] `npx jest getLogicFunctionHttpUrl` (front) and `nx test twenty-client-sdk` (RestApiClient routing) passing - [x] CI green (server, front, sdk, renderer, ui, zapier, example apps) - [ ] Manual: hit `{subdomain}.withtwenty.com/` end-to-end once infra is provisioned <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22045?utm_source=github" rel="nofollow noreferrer noopener" target="_blank">``&lt;img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"&gt;``</a>	2026-06-24 15:57:01 +02:00
Weiko	56e20a81ea	Revert 21949 (#22081) ... #21949 introduced deterministic uuid utils with usage in the same PR. Usage was not uniform and expected a backfill command as well. Since we want to release I'm reverting all the changes from that PR that concerns twenty-server and only keeping the unused utils in twenty-shared and I'll introduce usages within the same PR as backfill command	2026-06-24 15:37:16 +02:00
martmull	b5a1aed24b	feat(server): run server-exposed logic functions in the owner workspace (#22002) ... ## Summary Implements the server-level logic-function tier in the simplest shape: a logic function is "server-exposed" iff its manifest entry carries `serverWebhookTriggerSettings`. Execution delegates to the owner-workspace copy of that function — billing, throttling, env vars, and the existing executor all apply uniformly against that workspace. Supersedes #21971 with the simplified design from that discussion (no `applicationRegistrationLogicFunction` registry, no dedicated manifest type, no separate SDK helper, no special throttling). ## Design - **Manifest**: `LogicFunctionManifest` gains `serverWebhookTriggerSettings?`. The declarative `workspaceIdResolver` shape is dropped. - **Materialization**: those settings become two new jsonb columns on `LogicFunctionEntity`. The manifest → flat converter and the create-from-source DTO/util forward them; the property-config map and editable-properties list are extended. - **Lookup**: a single QB query joins `logicFunction → application → applicationRegistration` and filters on `lf.workspaceId = reg.workspaceId` to get only the owner workspace's copy. - **Webhook**: `POST /webhooks/server/:logicFunctionUniversalIdentifier` → `ServerWebhookTriggerService.handle` → join lookup → `LogicFunctionTriggerService.run`. No registry table, no `:applicationRegistrationUniversalIdentifier` segment, no resolver. - **Gate**: `IS_SERVER_LOGIC_FUNCTION_ENABLED` config var (disabled by default). ## Test plan - [x] `npx jest server-webhook-trigger` — 9 unit tests across the webhook service. - [x] `npx jest logic-function` — 88 existing tests stay green. - [x] `npx nx typecheck twenty-server`. - [x] `npx nx lint:diff-with-main twenty-server`. - [x] Reset DB → init → run `database:migrate:prod` → run `database:migrate:generate --name pending-migration-check` → no drift. - [ ] Manual: hit `/webhooks/server/<uid>` end-to-end against a manifest carrying `serverWebhookTriggerSettings`. https://claude.ai/code/session_01GgsnCGmYJ26xRirx8va1Yh --- _Generated by [Claude Code](https://claude.ai/code/session_01GgsnCGmYJ26xRirx8va1Yh)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22002?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-24 13:34:12 +00:00
Charles Bochet	dd7435b807	fix: normalize date-time field input on backend to prevent timeline crash (#22035) ... ## Context Reported via support ([private-issues#477](https://github.com/twentyhq/private-issues/issues/477)): a customer saw **"Invalid Configuration"** in red on a record's **Timeline** tab. The dev console was flooded with: ``` RangeError: Cannot parse: 2026-05-07 at Temporal.Instant.from (...) at RecordFieldComponent ... ``` ## Root cause A `DATE_TIME` field in their workspace holds **date-only** values like `2026-05-07`. `validateDateTimeFieldOrThrow` (the write-path validator) **accepts** date-only formats — `'yyyy-MM-dd'` is in `ACCEPTED_DATE_TIME_FORMATS` — and **returns the raw input string unchanged**, with no normalization. So a date-only string passes validation and propagates verbatim into the mutation response and the timeline event payload. On render, `DateTimeDisplay` builds the timezone hint with `Temporal.Instant.from(value)`. That's strict — it requires a full instant (time + offset/`Z`) and throws `RangeError` on a bare date. The throw escapes into the page-layout widget error boundary, which renders the **"Invalid Configuration"** fallback and breaks the whole timeline. ## Fix **Backend (root cause) — normalize on write.** `validateDateTimeFieldOrThrow` now canonicalizes every accepted value to a full ISO 8601 instant, so a date-only value can never reach storage, the mutation response, or timeline events for a `DATE_TIME` field: - strict ISO-8601 carrying an offset/`Z` -> kept as its exact instant (server-timezone-independent) - zoneless / date-only / lenient formats -> interpreted as **UTC** (date-only -> midnight UTC), deterministically Lenient input is preserved — parsing still uses date-fns for the ~20 accepted formats (which `Temporal.Instant.from` cannot parse); only the *output* is canonicalized, via Temporal. | input | before (stored raw) | after (normalized) | |---|---|---| | `2026-05-07` | `2026-05-07` | `2026-05-07T00:00:00Z` | | `2026-05-07T12:00:00+02:00` | `2026-05-07T12:00:00+02:00` | `2026-05-07T10:00:00Z` | | `2026-05-07T12:00:00.000Z` | `2026-05-07T12:00:00.000Z` | `2026-05-07T12:00:00Z` | | `January 15, 2024` | `January 15, 2024` | `2024-01-15T00:00:00Z` | **Frontend (existing data) — Temporal-native guard.** Existing workspaces already have date-only values stored in events, so the backend fix alone won't un-break the reporting customer's timeline. `DateTimeDisplay` now parses the value via a new `parseStringToInstantOrNull` helper (Temporal `Instant.from` with a `PlainDate` start-of-day-UTC fallback) and only renders the timezone hint when valid — so stored bad data renders gracefully instead of crashing. This replaces the initial `new Date()` guard with a Temporal-native one, in line with the codebase's Temporal migration. ## Tests - `validate-date-time-field-or-throw.util.spec.ts` updated to assert the normalized instant output, incl. explicit date-only -> midnight-UTC cases. - `parseStringToInstantOrNull.test.ts` — unit coverage for the frontend helper (instant, offset, date-only, unparseable). - `DateTimeDisplay.stories.tsx` — story rendering a date-only value under a non-system timezone (the previously-crashing path).	2026-06-24 12:42:05 +00:00
Raphaël Bosi	558e2e4107	Add new onboarding login screen at /welcome-v2 (#22027) ... Stands up the new onboarding login screen at a new route `/welcome-v2`, as the foundation for the new onboarding flow (future PRs build the post-login steps on top of it). There is no feature flag: feature flags are per-workspace and read from `currentWorkspaceState`, which is null on the pre-auth welcome screen, so they can't cleanly gate it. A dedicated route is used instead. `/welcome` is untouched and stays the default for logged-out users; `/welcome-v2` is reachable only by navigating to it directly (nothing links or redirects to it yet), so this is fully non-breaking. The new page reuses all existing auth logic and behavior components (`useSignInUp`, `useSignInUpForm`, step state, the Google/Microsoft/credentials forms, `Logo`, `Title`, `ModalContent`) and mirrors `SignInUp.tsx` almost exactly. The only intentional design delta from today's screen is the footer wording, per Figma: "Data Processing Agreement" (linking to `/legal/dpa`) instead of "Privacy Policy". Notable: - Added an optional `to` prop to the shared `Logo` (defaults to `AppPath.SignInUp`, backward-compatible) so the logo on `/welcome-v2` doesn't bounce users back to `/welcome`. - The remaining changes are single-line additions to the pre-auth allowlists next to the existing `AppPath.SignInUp` entries (router, redirect guard, auth modal, metadata gater, captcha, page title, focus). https://github.com/user-attachments/assets/abfc96ec-a87d-4608-b92a-87e2322e4874 <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22027?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-24 12:13:55 +00:00
Etienne	5ca41d55fb	feat(ai): humanize tool-call (#21976) ... # Humanize tool-call labels cc: https://github.com/twentyhq/twenty/pull/21462 ## Preview <img width="459" height="156" alt="Screenshot 2026-06-22 at 19 13 11" src="https://github.com/user-attachments/assets/e7a2f5f5-cd09-4ec6-920b-5eb16b98285c" /> <img width="461" height="156" alt="Screenshot 2026-06-22 at 19 14 54" src="https://github.com/user-attachments/assets/c2114d2e-2aa8-499a-9801-68e3bb7c45f8" /> <img width="461" height="505" alt="Screenshot 2026-06-22 at 19 15 01" src="https://github.com/user-attachments/assets/ee9ca5d0-8e79-4c63-a2ff-ed5e359a9a9c" /> ## Why In the AI chat, tool steps were displayed using raw tool identifiers (`find_many_companies`, `create_one_task`, `send_email`...) and labels were partially reconstructed/humanized on the frontend. This was hard to localize and inconsistent across tool categories. This PR makes the **backend the single source of truth for human-readable, localized tool labels**, exposes them through `getToolIndex`, and reduces the frontend to a thin resolver that picks the right label for the current status (in-progress / completed). ## What changed ### Backend - `ToolIndexEntry` (and the `getToolIndex` GraphQL DTO) now carry `label`, `inProgressLabel?`, `completedLabel?`. - New `getCrudToolLabels(operation, objectLabel, i18nService, locale)` builds CRUD labels from a verb table (Search / Find / Group / Create / Update / Upsert / Delete × imperative / in-progress / completed) + the (translated, lowercased) object label. - New `translate-tool-label.util.ts` translates a source label via `I18nService` (`generateMessageId` → fallback to source when no translation exists). - Action tools: labels extracted to the `ACTION_TOOL_LABELS` constant (`msg` + `i18nLabel`) and translated in `ActionToolProvider.buildDescriptor`. - Logic-function tools use the function name as label; `toolSetToDescriptors` (workflow / view / metadata / dashboard) accepts an optional `labels` map and falls back to a humanized tool name. - Labels are localized server-side using the request locale (`@RequestLocale` → `buildToolIndex` → `context.locale`, threaded through `ToolContext` / `ToolProviderContext`). - `code_interpreter` schema now asks the model for `loadingMessage` (present tense) and `completedMessage` (past tense), so its status text is model-generated. - Removed the old generic `loadingMessage` injection mechanism (`wrap-tool-for-execution.util.ts` deleted; `wrapJsonSchemaForExecution` / `stripLoadingMessage` no longer wrap every tool). ### Frontend - New `useToolLabelMap()` hook builds a `Map<name, { label, inProgressLabel, completedLabel }>` from `getToolIndex`. - `getToolDisplayMessage` → `resolveToolDisplayMessage({ input, toolName, isFinished, labelMap, output })`: a small resolver registry keyed by tool name (`execute_tool`, `web_search`, `learn_tools`, `load_skills`, `code_interpreter`, default). - Default resolver prefers backend `completedLabel` / `inProgressLabel`, falling back to `Ran X` / `Running X`. - `learn_tools` / `load_skills` resolve their inner tool/skill names to labels (label map → tool output labels via `getToolOutputLabelEntries` → raw name). - `code_interpreter` step is now expandable to show the code even while running. ## How tool labelling flows (BE → FE) ```text BACKEND ┌───────────────────────────────────────────────────────────────────────────┐ │ Tool providers (per category) → ToolIndexEntry │ │ │ │ DatabaseToolProvider │ │ getCrudToolLabels(operation, object.labelPlural/Singular, i18n, locale) │ │ verb table (Search/Create/Update/Delete…) + translateToolLabel(object) │ │ → { label, inProgressLabel, completedLabel } │ │ │ │ ActionToolProvider │ │ ACTION_TOOL_LABELS[toolId] (msg) → translateToolLabel(…, locale) │ │ → { label, inProgressLabel?, completedLabel? } │ │ │ │ LogicFunctionToolProvider → label = logicFunction.name │ │ toolSetToDescriptors → label = labels[name] ?? humanize(name) │ │ (workflow / view / metadata / dashboard) │ └───────────────────────────────────────────────────────────────────────────┘ │ ▼ ┌───────────────────────────────────────────────────────────────────────────┐ │ GraphQL Query getToolIndex : [ToolIndexEntry] │ │ { name, label, inProgressLabel, completedLabel, description, │ │ category, objectName, icon } │ └───────────────────────────────────────────────────────────────────────────┘ │ ▼ FRONTEND ─ resolve the right label for the current status ┌───────────────────────────────────────────────────────────────────────────┐ │ useGetToolIndex() → useToolLabelMap() │ │ Map<name, { label, inProgressLabel?, completedLabel? }> │ └───────────────────────────────────────────────────────────────────────────┘ │ ▼ ┌───────────────────────────────────────────────────────────────────────────┐ │ resolveToolDisplayMessage({ input, toolName, isFinished, labelMap, output })│ │ │ │ TOOL_LABEL_RESOLVERS[toolName] ?? defaultResolver │ │ ├─ execute_tool → unwrap { toolName, arguments } then re-resolve │ │ ├─ web_search → "Searching/Searched the web for <query>" │ │ ├─ learn_tools → "Learning/Learned <labels>" │ │ ├─ load_skills → "Loading/Loaded <labels>" │ │ │ inner names resolved via: labelMap → output labels → raw name │ │ ├─ code_interpreter → model's loadingMessage / completedMessage │ │ └─ default → isFinished │ │ ? completedLabel ?? "Ran <label>" │ │ : inProgressLabel ?? "Running <label>" │ └───────────────────────────────────────────────────────────────────────────┘ │ ▼ Rendered by ThinkingStepsDisplay / ToolStepRenderer ``` ## Localization notes - Standard object labels and action/CRUD verbs are translated server-side via `I18nService` using the requester's locale. - Custom object labels are not translated unless a workspace custom translation exists (matched by `generateMessageId`); otherwise the source label is used as-is. ## Tests - **FE:** `resolveToolDisplayMessage` / `getToolOutputLabelEntries` (status selection, inner-name resolution, `code_interpreter` model labels, fallbacks). - **BE:** `toolSetToDescriptors` (label map + humanized fallback) and `database-tool.provider` label generation. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21976?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-24 13:41:09 +02:00
Weiko	b7850a6c64	feat(metadata): deterministic universalIdentifiers for server-generated side-effects (#21949) ... ## Context Server-generated "side-effect" entities created for every object (system fields, INDEX view, record-page fields view + view fields, search-vector index, navigation command, record page layout/tabs/widgets) were minted with random v4() ids. Because they were non-deterministic, nothing could reference them by id (e.g. point a view field at an object's createdAt field). This PR introduces a single shared rule for deriving these ids deterministically via uuid v5, so the same (owner app, parent, kind) always yields the same id, making side-effects referable and reproducible. This is the **forward-only foundation** (PR1). Follow-ups: - PR2: SDK with optional universalIdentifier + expose helpers to app authors. - PR3: regenerate the standard-app constants to the same scheme + workspace backfill. ## The rule ```ts universalIdentifier = computeOwnerScopedUniversalIdentifier({ ownerAppUID, namespace, value }) = v5(value, v5(ownerAppUID, ENTITY_TYPE_NAMESPACE)) value = `${parentUID}:${discriminator}` // entity scoped under a parent = `${discriminator}` // top-level, app-parented entity ``` - ownerAppUID: The application that owns the entity (already threaded through every generator as applicationUniversalIdentifier); folded into the namespace so it both owns and scopes the id — two apps adding the same-named entity to a shared parent never collide. - namespace: Per entity type (ENTITY_TYPE_NAMESPACE_BY_TYPE), so different types with the same parent+discriminator never collide. - parentUID: The immediate parent's actual universalIdentifier (omitted for top-level entities, since the owner app already scopes them). - discriminator: A stable semantic key (field name, tab/widget title, generated index name, select-option value, …). Scope boundary: deterministic v5 applies to system side-effects (unique by construction) and, later, app-authored manifest entities (uniqueness enforced at SDK build time). Entities created through the UI by the workspace "Custom" app (custom objects/views/fields) keep v4, their natural keys aren't unique and aren't enforced. A UI-created custom object keeps its v4 id; its side-effects are deterministic relative to that v4 parent. Changes twenty-shared: new application/deterministic-identifier/ module: - computeDeterministicUuid(value, namespace) primitive + a thin computeOwnerScopedUniversalIdentifier wrapper (boilerplate only), and frozen ENTITY_TYPE_NAMESPACE_BY_TYPE. - One self-contained util per usecase (no central registry, no generic engine): each util bakes in its own discriminator + namespace, so a key lives next to the code that uses it and is individually testable. ~28 utils covering side-effect and (future) app-authored entities, e.g. getFieldUniversalIdentifier, getIndexViewUniversalIdentifier, getFieldsWidgetViewUniversalIdentifier, getViewFieldUniversalIdentifier, getIndexUniversalIdentifier, getRecordPageLayoutUniversalIdentifier, getPageLayoutTab/WidgetUniversalIdentifier, getNavigationCommandUniversalIdentifier, plus the general getViewUniversalIdentifier / getPageLayoutUniversalIdentifier and app-authored getObject/Role/PermissionFlag/Agent/Skill/…UniversalIdentifier. - Golden snapshot test locking every util's output for fixed inputs, plus a cross-type no-collision test. twenty-server: side-effect generators now derive universalIdentifier via the helpers (local id PKs stay v4()): system fields + name, INDEX view, record-page fields (fields-widget) view, default view fields, search-vector index, nav command, page layout/tabs/widgets. Index ids key off the generated Postgres index name; extracted computeFlatIndexNameOrThrow so the name (and therefore the id) is computed once with no placeholder. ## Timeline ### What actually changes - New objects (custom objects created via Settings/metadata API) and fresh standard installs now get deterministic v5 universalIdentifiers for all side-effect entities (system fields, views, view fields, search index, nav command, page layout/tabs/widgets) instead of random v4(). - The nav-command id formula changed (new owner-scoped) for new objects, fresh standard installs, and the runtime lookup. ### What does NOT change - Existing objects' side-effect ids — untouched (no migration; forward-only). - Standard object UIDs — untouched - UI-created custom entities' own ids stay v4 (see scope boundary above). - Fresh installs are behaviorally a no-op — ids are internal; re-sync produces no diff (verified). Nothing user-visible. ### The one real-world impact / risk (existing workspaces) The nav-command runtime lookup (findNavigationCommandMenuItemForObject) now computes the new formula, but existing workspaces' nav commands were stored with the old formula. So on an upgraded existing workspace, until the PR3 backfill: - Object activate/deactivate toggle for existing objects won't find the nav command → re-activating can create a duplicate nav command; deactivating may no-op. - Object deletion won't find/clean up the old nav command → orphaned nav-command row. ### What app developers get right now Nothing usable yet. The helpers exist in twenty-shared but aren't re-exported from twenty-sdk (PR2), and app-authored objects still get SDK-derived ids in the old format until PR2 re-mints them. So "reference a server entity by deterministic id" doesn't work end-to-end until PR2	2026-06-24 11:47:44 +02:00
martmull	21c3574f05	docs(apps): add key-value store guide for logic functions (#22061) ... ## What Adds a new docs page under **Developers → Extend → Apps → Logic** explaining how to give logic functions key-value storage (to persist intermediate results, cache data, and share state across runs). Rather than introducing a dedicated storage primitive, the guide shows how to achieve this with a small **technical object** ("KV Store") that has a unique `key` field and a `RAW_JSON` `value` field — queried through the existing typed `CoreApiClient`. Closes the documentation part of [core-team-issues#2427](https://github.com/twentyhq/core-team-issues/issues/2427). ## Contents of the new page - `defineObject` for the `kvStore` object (`key` + `value`) - A unique index on `key` (the recommended uniqueness primitive) - `get` / `set` (upsert) / `del` helpers built on `CoreApiClient` - A worked example: caching an expensive third-party call with a TTL - Patterns & tips: namespacing, expiry, what to store, visibility/permissions, per-record scoping ## Files - `developers/extend/apps/logic/key-value-store.mdx` — the new page - `navigation/base-structure.json` — navigation source-of-truth - `docs.json` + `twenty-shared/.../DocumentationPaths.ts` — regenerated from base-structure ## Notes - Documentation only — no code/behavior changes. - This is a convention (a regular custom object), not a new feature, so it inherits the same sync, permissions, and tooling as the rest of an app's data. https://claude.ai/code/session_01XAgXy1mUUMff5BFkFPjtfZ --- _Generated by [Claude Code](https://claude.ai/code/session_01XAgXy1mUUMff5BFkFPjtfZ)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22061?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-24 11:45:35 +02:00
Charles Bochet	5ec98d3d84	fix(filter): guard isMatchingDateFilter against empty date values (#22029) ... ## Symptom On the Opportunities **board (kanban)** view, creating or updating *any* opportunity randomly crashed with: ``` Uncaught (in promise) Cannot read properties of null (reading 'split') ... at isMatchingDateFilter at isRecordMatchingFilter at opportunitiesGroupBy (group-by optimistic effect) at createOneRecord ``` Reported in quality-feedbacks as *"Can't update the Opportunity"* — "happens randomly, no specific path." The randomness is the tell: it depends on the **view's filter configuration**, not on which record you edit. ## What runs on create/update Create/update trigger an **optimistic cache update**. On a board view that means recomputing which group each record belongs to (the `opportunitiesGroupBy` field in the trace). To do that, the group-by optimistic effect re-evaluates **every record in the affected groups against the view's filters** via `isRecordMatchingFilter`, which walks the AND/OR filter tree and dispatches each leaf to a per-field-type matcher (`isMatchingStringFilter`, `isMatchingSelectFilter`, `isMatchingDateFilter`, …). ## Root cause `isMatchingDateFilter` passed the record value straight to date-fns `parseISO` for the `eq`/`neq`/`gt`/`gte`/`lt`/`lte` operators: ```ts case dateFilter.gte !== undefined: { const valueDate = parseISO(value); // value = record[fieldName], declared `string` but actually nullable ... } ``` `parseISO` parses an ISO string by first calling `argument.split(...)` internally, so `parseISO(null)` runs `null.split(...)` → **`Cannot read properties of null (reading 'split')`**. That's the three-deep `utils`-chunk frame in the minified trace: `isMatchingDateFilter` → `parseISO` → date-fns `splitDateString`. `value` is `null` whenever a record has an **empty date field** (e.g. an opportunity with no Close date). So the crash fires only when **both** hold: 1. the current view has a **date filter** (`gt`/`gte`/`lt`/`lte`/`eq`/`neq`) on some date field, **and** 2. at least one opportunity in view has that date field **empty**. That's the "randomness" — purely a function of the view config and which records have blank dates. The `is: NULL` operator never crashed (it checks `value === null` before `parseISO`); only the value-parsing operators were exposed. Sibling matchers (`isMatchingTSVectorFilter`, `isMatchingRatingFilter`, `isMatchingSelectFilter`) already tolerate `null` — the date matcher was the odd one out, and its `value: string` type masked the real nullability. ## Fix Widen the param type to the truth (`string | null | undefined`) and guard the empty case up front: ```ts if (!isDefined(value)) { return dateFilter.is === 'NULL'; } ``` Semantics: - empty value + `is: NULL` → `true` (it *is* null) - empty value + every other operator (incl. `is: NOT_NULL`) → `false` The `false` is the *correct* answer, not just crash avoidance: it mirrors SQL three-valued logic where `NULL > '2024-01-01'` is `UNKNOWN` and the row is excluded. So the optimistic match now agrees with what the backend query returns, and a blank-date record groups the same way before and after the server round-trip. ## Tests Added regression cases to `isMatchingDateFilter.test.ts` running `null` and `undefined` through every operator (assert no throw + correct boolean). These throw without the guard.	2026-06-24 08:53:08 +02:00
Félix Malfait	855664daa2	feat(timeline): activity kind registry (Layer A) (#21950) ... ## What & why The timeline-activity system's contract is a magic `name` string (`"company.updated"`, `"linked-note.created"`, `"message.linked"`) decoded by `String.split('.')` in **four** different frontend spots and produced by a hardcoded `if`-ladder + two listeners. It is not extensible and it already harbored a latent bug. This PR replaces that stringly-typed protocol with an explicit, persisted **`kind`** contract consumed through registries on both ends. Adding a new timeline activity type becomes: add a producer + register a presenter — no edits to a central switch. This is **Layer A** of a larger plan (see `packages/twenty-server/docs/TIMELINE_ACTIVITIES_REFACTOR.md` and `TIMELINE_ACTIVITIES_PR_A.md`). Layer B (timeline projection / "inheritance") and Layer C (user-defined aggregation rules) are intentionally **out of scope** here. ## 🐛 Bug fixed along the way `calendar-event-participant.listener.ts` was writing calendar-event timeline rows with `name: 'message.linked'` (copy-paste from the message listener). It rendered "correctly" only by luck — the frontend routed on `linkedObjectMetadataId → nameSingular`, never on `name`. This PR fixes it at the source (`calendarEvent.linked` / `kind: 'linkedCalendarEvent'`), and the shared resolver also corrects historical rows that carry the wrong `name`. ## Changes **`twenty-shared`** — new `timeline` module - `TimelineActivityKind` (`recordChange | linkedNote | linkedTask | linkedMessage | linkedCalendarEvent | linkedRecord`) + `resolveTimelineActivityDescriptor`, the **single** place that decodes an activity into `{ kind, action }`. Reads the persisted `kind` when present and falls back to legacy `name`/`linkedObjectMetadataId` parsing (back-compat shim). Unit-tested (20 cases). **`twenty-server`** - Persist a nullable `kind` field on the `timelineActivity` standard object (entity shape + field-metadata builder + universalIdentifier). - Producers (`timeline-activity.service.ts`, the two participant listeners) set `kind` explicitly; dev seeder populates it. - Fix the `calendarEvent.linked` mislabel. **`twenty-front`** - Static `TIMELINE_ACTIVITY_PRESENTERS` registry replaces the render `switch`, the icon `if`-chain, the diff-validation name-parsing, and the `name.match(/note|task/i)` title-prefetch hack. - New `EventRowGenericLinked` so an unknown linked object type renders a real "linked a {object}" row instead of falling through to the wrong (main-object) renderer. ## Migration / compatibility - The `kind` column on this **workspace** standard object is created by the normal workspace metadata sync — no hand-written migration. It is **nullable**, so pre-upgrade rows degrade gracefully through the resolver shim (they resolve correctly from `linkedObjectMetadataId` + `name`). An optional backfill workspace command could populate `kind` on old rows later; not required for correctness. - No GraphQL breaking change — `kind` is additive, `name` is retained for display/search. ## Test plan - `twenty-shared` unit tests (resolver) ✅ - `typecheck` + `lint:diff-with-main` green on `twenty-front`, `twenty-server`, `twenty-shared` ✅ - Reset + reseed a workspace: `kind` is populated for all seeded rows (recordChange / linkedMessage / linkedNote / linkedTask / linkedCalendarEvent) with no nulls ✅ - Manual end-to-end verification via Playwright on person / company record timelines — screenshots in a follow-up comment. Screenshots attesting the rendering (incl. the calendar fix) are posted as a comment below. --- _Generated by [Claude Code](https://claude.ai/code/session_01YRueWMo4UyaX2em8R2cdio)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21950?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-23 16:59:09 +02:00
Paul Rastoin	e9d5d71cd3	Wire up search field metadata (#21964) ... ## Part 1 - Exact scope of the current PR (#21964) close https://github.com/twentyhq/core-team-issues/issues/2586 This PR introduces `searchFieldMetadata` as a first-class flat metadata entity and migrates the existing search surface onto it, with **no change to which records are searchable** (ISO with `main`). In scope (what the PR does): - New flat entity `searchFieldMetadata` (universalIdentifier, applicationId, **`position`**, maps, conversions), registered in the central flat-entity constants and the migration build orchestrator. - `searchVector.asExpression` is **derived server-side** from `searchFieldMetadata` rows (validated by `isSafeTsVectorExpression`); never trusted from client input. - **Derivation order is deterministic, driven by each row's `position`** ([compute-search-vector-as-expression-from-search-field-metadatas.util.ts](packages/twenty-server/src/engine/metadata-modules/flat-search-field-metadata/utils/compute-search-vector-as-expression-from-search-field-metadatas.util.ts)), replacing the previous non-deterministic `(createdAt, id)` sort. That sort collapsed to random UUIDs for standard fields (same `createdAt`), so any rename/relabel rewrote the `STORED` generated column to a logically-identical-but-textually-different expression and produced a permanent per-workspace diff vs the standard definition. Ordering now equals provisioning order; ties break on `universalIdentifier`. - Provisioning at object creation mirrors the existing surface exactly **and seeds `position`**: - custom objects -> the `name` field only, at `position: 0` ([build-default-search-field-metadatas-for-custom-object.util.ts](packages/twenty-server/src/engine/metadata-modules/object-metadata/utils/build-default-search-field-metadatas-for-custom-object.util.ts)) - standard objects -> their curated `SEARCH_FIELDS_FOR_*` sets, `position` = the curated index - Backfill (instance + workspace commands in `2-16`) provisions rows for existing workspaces with the same surface **and the same positions** (standard from the curated standard maps, custom `name` = `0`), scoped to the workspace's own custom application ([build-search-field-metadata-backfill-operations.util.ts](packages/twenty-server/src/database/commands/upgrade-version-command/2-16/utils/build-search-field-metadata-backfill-operations.util.ts)). The `position` column is added in the same `2-16` fast instance command as `universalIdentifier`/`applicationId`. - Field rename of an already-indexed field recomputes `asExpression` (positions preserved, so order is stable) ([recompute-search-vector-on-field-rename.util.ts](packages/twenty-server/src/engine/metadata-modules/flat-field-metadata/utils/recompute-search-vector-on-field-rename.util.ts)). - Field delete drops the matching row(s) and recomputes; remaining rows keep their relative order (no renumber) ([from-delete-field-input-to-flat-field-metadatas-to-delete.util.ts](packages/twenty-server/src/engine/metadata-modules/flat-field-metadata/utils/from-delete-field-input-to-flat-field-metadatas-to-delete.util.ts)). - Object relabel is **additive** and ISO/regression-fix only: it indexes the new label identifier **appended last (`position = max(existing) + 1`)** without dropping `name` ([recompute-search-vector-on-label-identifier-update.util.ts](packages/twenty-server/src/engine/metadata-modules/flat-object-metadata/utils/recompute-search-vector-on-label-identifier-update.util.ts)). This is a deliberate, temporary bridge. Explicitly OUT of scope (deferred): - No API to edit `searchFieldMetadata` (no user-facing search-field configuration, including `position` — it is internal and only written by provisioning/backfill/recompute). - No auto-indexing of arbitrary searchable fields. Creating a custom TEXT/EMAILS/etc. field does NOT add it to search (the `computeSearchFieldMetadataCreationForFields` behavior was removed in `e6820ad`). - No field-type-transition handling (field type is immutable - not in `FLAT_FIELD_METADATA_EDITABLE_PROPERTIES`, so that path was dead code). - No `position` validation (uniqueness/range) and no multi-vector / per-field `weight` config — deferred to the configurable-search follow-up (#1428). Net: `searchFieldMetadata` becomes the source of truth for the *same* surface as `main`. The only intentional divergences from `main` are "relabel preserves `name`" (additive) and the deterministic `position`-ordered `asExpression` (a correctness/perf fix that is byte-identical to provisioning order, so it does not change the searchable surface). --------- Co-authored-by: Félix Malfait <felix@twenty.com>	2026-06-23 16:27:13 +02:00
neo773	9e31ffdf68	feat(messaging): webhook push sync for Gmail, Calendar and Microsoft (#21970) ... <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21970?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-23 14:04:16 +05:30
Raphaël Bosi	5f22908588	Decouple twenty-ui Avatar from app server-URL config (#21968) ... Makes `twenty-ui`'s `Avatar` render the `avatarUrl` it receives instead of building it from `window._env_`/`window.location` at module load, so the library no longer depends on the app environment. URL resolution moves to `twenty-front` via a `getAbsoluteImageUrl` helper applied at the call sites. Part of making twenty-ui a standalone library.	2026-06-22 18:38:00 +02:00
Marie	1eadef8ea0	fix(workflow): serialize object variables in resolved prompts (#21612) ... ## Problem When a workflow passes a variable into a text input (e.g. an **AI Agent** prompt) and that variable resolves to an object or array, the resolved string contained `[object Object]` instead of the actual content. The AI then received useless input. ## Cause `resolveString` in the shared variable resolver builds the final string with `String.prototype.replace`. When an embedded `{{variable}}` resolved to an object, the replace callback returned the object directly, which JS coerces to `"[object Object]"`. The rich-text resolver had the same issue via `String(resolvedValue)`. ## Fix When an embedded variable resolves to a non-null object (or array), serialize it with `JSON.stringify` before inserting it into the surrounding string. Primitive values keep their existing coercion behavior, and the single-variable case (`{{message}}` with nothing around it) still returns the raw object so non-string consumers are unaffected. Applied the same guard to both the plain and rich-text variable resolvers for consistency. ## Tests Added cases covering embedded object/array variables in both resolvers, plus a guard test confirming a standalone `{{variable}}` still returns the raw object. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21612?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-22 09:56:01 +00:00
Félix Malfait	2abf9c2930	feat(workflow): Pick Record load balanced strategy (3/3) (#21902) ... ## Overview Final PR in the Pick Record stack. Adds the **Load Balanced** strategy: pick the candidate that currently has the *fewest related records*. This is the "fair assignment" mode — e.g. assign a new company to the account owner who currently owns the fewest companies, or route a lead to the rep with the fewest open opportunities. **Stacked on #21900** (which is stacked on #21899) — merge in order. This PR's diff against `main` includes PRs 1 & 2 until they merge. ## What changed - Widened the `strategy` enum to add `LOAD_BALANCED`, and added an optional `loadBalance: { objectNameSingular, fieldName }` to the action input. - Editor: selecting **Load balanced** reveals a **Balance by** object picker and a **Count by** field picker (the related object's many-to-one relation fields). - Executor: for each candidate, counts records of the chosen related object whose chosen relation points at that candidate, then selects the least-loaded one. ## How it works Given pool = workspace members and config `{ objectNameSingular: "opportunity", fieldName: "pointOfContact" }`, the executor counts, per member, the opportunities whose `pointOfContact` is that member, and picks the member with the lowest count. ## Design decisions & tradeoffs 1. **No persistent state — computed live each run.** Unlike round robin, load balancing reads current data, so there's no cursor to store. Correct by construction even under concurrency (each run recomputes counts); the only caveat is two simultaneous runs can both see the same "least loaded" candidate before either assignment lands (a small, self-correcting skew), which is inherent to load-balancing and acceptable. 2. **Count via per-candidate queries.** One filtered count per candidate (`{ [relationField]: { id: { eq: candidateId } } }`), run in parallel. For the realistic pool sizes this targets (a team), this is simple and clear. A single `group_by` aggregate would scale better for very large pools — noted as a future optimization, deliberately not done to keep the logic obvious. 3. **Deterministic tie-break.** Candidates are pre-sorted by id (shared with round robin), and the first minimum wins — so equal-load ties resolve deterministically rather than arbitrarily. 4. **`Count by` lists all many-to-one relations of the chosen object** (not filtered to those targeting the pool object). Keeps the editor simple; picking an unrelated field just yields zero counts, which is visibly wrong. Filtering options to relations that target the pool object is a nice follow-up. 5. **Filter on the counted set** (e.g. only *open* opportunities) is intentionally out of scope for this first cut — documented as a follow-up. ## Testing Added `pick-record-load-balanced-workflow.integration-spec.ts`: creates two fresh companies (0 related opportunities each), attaches one opportunity to the second, configures `LOAD_BALANCED` counting opportunities by `company`, and asserts the step picks the **first** company (0 < 1). Passes locally alongside the random and round-robin tests (3 suites / 4 tests). `typecheck` + `lint:diff-with-main` green for shared/server/front. ## The full stack 1. #21899 — Random (the action + the whole scaffold) 2. #21900 — Round robin (atomic Redis cursor) 3. this — Load balanced Together these enable round-robin / load-balanced / random **assignment workflows** in Twenty, composed via the standard variable picker (assign the chosen record downstream with `{{step.<id>.id}}`). https://claude.ai/code/session_01MuPWZsqf2bmQSevk6fRbX8 --- _Generated by [Claude Code](https://claude.ai/code/session_01MuPWZsqf2bmQSevk6fRbX8)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21902?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-22 07:09:15 +02:00
Félix Malfait	fa6d1394af	feat(workflow): Pick Record round robin strategy (2/3) (#21900) ... ## Overview Second PR in the Pick Record stack. Adds a **Round Robin** selection strategy alongside Random, so an assignment workflow can distribute records *evenly* across a candidate pool (e.g. rotate company ownership across a set of workspace members) rather than just randomly. **Stacked on #21899** — review/merge that one first. This PR's diff against `main` includes PR 1's commits until #21899 merges. ## What changed - Widened the `strategy` enum (`RANDOM` → `RANDOM | ROUND_ROBIN`) in the shared schema and the server input type. - Editor now shows a **Strategy** selector (Random / Round robin). The candidate-pool label changed from "Pick at random from" to the neutral "Pick from" since random is no longer the only mode. - Executor implements round robin. ## Design decisions & tradeoffs 1. **State store: Redis `incrBy` (atomic), keyed `pick-record:round-robin:{workspaceId}:{stepId}`.** Round robin needs a persistent cursor, and workflow runs are **not** serialized — two runs can execute the same step concurrently — so the increment must be atomic. `CacheStorageService.incrBy` (workflow cache namespace) is a single atomic Redis op, needs no schema change, and is already injectable. Index = `(cursor - 1) % poolSize`. **Tradeoff — durability:** a Redis flush/eviction resets the cursor, which restarts the cycle from an offset. That causes a one-time *fairness drift*, never a *correctness* bug (no double-assignment, since each increment is atomic). If strict durability is ever required, the cursor can move to a Postgres counter table with `INSERT … ON CONFLICT … DO UPDATE SET cursor = cursor + 1 RETURNING cursor` (atomic + durable) — deliberately **not** done here to avoid a migration for what is, in practice, an acceptable reset. 2. **Deterministic pool ordering.** The resolved pool is sorted by `id` before the cursor is applied, so position→record mapping is stable run-to-run regardless of fetch order. Without this, round robin wouldn't reliably cycle. 3. **Cursor key uses `stepId`.** Stable across runs of a published version. Republishing a version may mint new step ids, which resets the cursor — acceptable and documented here. 4. **Slot-on-increment.** The cursor increments when the step runs (reserving a position); if a later step in the run fails, that position is effectively skipped. Minor, acceptable unfairness — flagged rather than adding cross-step compensation. ## Testing Added `pick-record-round-robin-workflow.integration-spec.ts`: builds a workflow with a 3-record pool and `ROUND_ROBIN`, runs it 4 times sequentially, and asserts the picks are exactly `[p0, p1, p2, p0]` (full cycle + wraparound) against the deterministically-ordered pool. Passes locally alongside PR 1's random test (2 suites / 3 tests). `typecheck` + `lint:diff-with-main` green for shared/server/front. ## Follow-up - PR 3: `LOAD_BALANCED` (fewest related records wins). https://claude.ai/code/session_01MuPWZsqf2bmQSevk6fRbX8 --- _Generated by [Claude Code](https://claude.ai/code/session_01MuPWZsqf2bmQSevk6fRbX8)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21900?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-21 22:16:26 +02:00
Félix Malfait	a682c8fa62	feat(sdk): declare row-level permission predicates in the role manifest (#21919) ... ## Why Apps can declare object and field permissions on a role via `defineRole`, but **not row-level security**. The RLS engine and the metadata-sync machinery already support predicates fully — they're first-class universal flat entities, the `FlatRole` already carries `rowLevelPermissionPredicateUniversalIdentifiers`, and the workspace-migration layer has builders/validators/handlers for them. The only gap was the **manifest layer**: `RoleManifest` had no field for predicates, so the sync converter always left them empty. As a result, the only way to ship RLS with an app was a post-install script that pushed predicates through the `upsertRowLevelPermissionPredicates` mutation. That mutation assigns predicates to the workspace's **generic custom application**, not the app that owns the role — so a single role's definition ends up split across two applications and drifts on every upgrade (you have to remember to re-run the script). The Partner app does exactly this today via `configure-partner-rls.ts`. ## What Adds `rowLevelPermissionPredicates` and `rowLevelPermissionPredicateGroups` to `RoleManifest` / `RoleConfig`, mirroring how `objectPermissions` / `fieldPermissions` already flow end-to-end: - **twenty-shared** — predicate + predicate-group manifest types on `RoleManifest` (referencing objects/fields by `universalIdentifier`, operand/logical-operator from the existing GraphQL enums). - **twenty-sdk** — `defineRole` accepts and validates them; the build derives deterministic predicate `universalIdentifier`s (groups keep an explicit one so predicates can reference them). - **twenty-server** — two converters turn manifest predicates/groups into universal flat entities during application-manifest sync, so they are created/updated/deleted together with the role and **owned by the app that ships it**. ### Bug fix found along the way The migration build order ran the `rowLevelPermissionPredicate(Group)` builders **before** the `role` builder, so a predicate declared alongside a brand-new role failed validation with `ROLE_NOT_FOUND`. They now run **after** the role builder, exactly like object/field permissions. ## Partner app (second commit) Converts `partner.role.ts` to declare its five predicates inline and **deletes `configure-partner-rls.ts`** + the `rls:configure` scripts — the workaround this PR is meant to retire. The predicates are byte-for-byte the same semantics as the script produced. > Live-deployment note: the existing script-created predicates are owned by the *custom* application, so the Partner app sync won't touch them. Clear them once (e.g. an empty upsert on the Partner role) around deploy to avoid duplicates. Kept as a **separate commit** so it can be split out if reviewers prefer. ## Testing - **Integration (full app):** new `successful-manifest-sync-row-level-permission-predicate.integration-spec.ts` — installs an app whose role declares a predicate and asserts the predicate row is created (and **owned by the app**, not the custom app), updated in place on re-sync, removed when dropped from the manifest, and removed on uninstall. Ran locally against a seeded test DB ✅. - Re-ran the existing cross-app permission + view-field manifest suites to confirm the build-order change doesn't regress object/field-permission sync (13/13 ✅). - **Unit (utils only):** `defineRole` validation and `fromRoleConfigToRoleManifest` deterministic-id derivation. - Docs: new "Row-level security" section in `apps/config/roles.mdx`. ## Scope notes / possible follow-ups - Surfacing RLS in the app-install permission summary UI was intentionally left out (predicates *restrict* rather than grant, and typically live on a non-default role) — easy follow-up if wanted. - The `upsertRowLevelPermissionPredicates` mutation still homes out-of-band predicates on the custom app for app-owned roles; making that consistent (or rejecting it, like field permissions already do) is a sensible follow-up. https://claude.ai/code/session_01MipAis9z9okd4oCm9HCKEf --- _Generated by [Claude Code](https://claude.ai/code/session_01MipAis9z9okd4oCm9HCKEf)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21919?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-21 22:09:19 +02:00
Félix Malfait	573fd00ea7	feat(workflow): add Pick Record action (1/3 — random selection) (#21899) ... ## Overview Adds a new workflow action, **Pick Record**, that selects **one** record from a configured candidate pool and exposes the chosen record as the step's output. Downstream steps can then reference it through the normal variable picker — e.g. assign an owner in an _Update Record_ step by setting **Account Owner = `{{step.<pickRecordId>.id}}`**. This is the foundation for building **assignment workflows** (round-robin / load-balanced owner assignment, reviewer rotation, etc.) in Twenty. ## This is PR 1 of a 3-PR stack | PR | Strategy | Adds | |----|----------|------| | **1 (this one)** | `RANDOM` | The whole `PICK_RECORD` action, end-to-end, stateless | | 2 | `ROUND_ROBIN` | A persistent, atomically-incremented per-step cursor + the strategy selector UI | | 3 | `LOAD_BALANCED` | "fewest related records wins" via an aggregate count | Each PR widens the `strategy` enum (a backward-compatible change), so no data migration is needed between them. ## How it works - **Editor**: pick an Object, then pick the candidate records (a multi-record selector). A random record is selected from that pool at run time. - **Output**: a single record of the chosen object — the same output shape as `CREATE_RECORD`/`UPDATE_RECORD` — so it drills into `{{step.x.id}}`, `{{step.x.name}}`, … in the variable picker. - **Execution**: reuses `FindRecordsService` to fetch the pool (`id IN (recordIds)`, which also transparently drops any deleted candidates), then returns one at random. ## Design decisions & tradeoffs 1. **Standalone step that outputs a variable, not an inline "random" mode on the relation field.** This mirrors Attio's round-robin block. The decisive reason is composition: the chosen record is almost always reused (assign owner **and** create a follow-up task for them **and** email them). A variable is chosen once and reused everywhere; an inline per-field value would re-roll independently in each place. It also keeps the (stateful) round-robin/load-balanced logic out of the field inputs. Tradeoff: one extra step to wire up vs. an inline control — accepted for the composability win. An inline "Assign automatically" entry point can still be layered on later as sugar that inserts this step. 2. **Co-located in the `record-crud` action module and reuses `FindRecordsService`.** Avoids duplicating module wiring (auth context, permissions, object-metadata resolution) and the data-access path. Tradeoff: "Pick" is a selection rather than a CRUD op, so the folder name is slightly broad; chose reuse + low risk over a separate module. Can be extracted if the family grows. 3. **`strategy` exists in the schema (defaulted `RANDOM`) but the selector is hidden in this PR.** A dropdown with a single option would be UX slop, and adding the field only in PR 2 would force a data backfill for any `PICK_RECORD` steps created in between. Keeping the field now (hidden) avoids both. PR 2 introduces the selector once there's a real choice. 4. **Pool is an explicit static list (`recordIds`) for v1.** Matches the most common assignment case ("rotate among these N people") and reuses the existing `FormMultiRecordPicker`. A filter-based pool (reusing the Find Records filter UI) and a list-from-a-previous-step pool are natural follow-ups, intentionally out of scope here to keep the stack focused on the three strategies. 5. **Output schema is computed on the frontend** (like `CREATE_RECORD`), derived from `input.objectName` — so it is **not** added to `PERSISTED_OUTPUT_SCHEMA_TYPES` and needs no server-side schema computation. 6. **Validation**: `PICK_RECORD` is added to object-name metadata validation (so a deleted/invalid target object is flagged) via a dedicated `OBJECT_TARGETING_ACTION_TYPES` set — deliberately **not** to `VARIABLE_CONSUMING_ACTION_TYPES`, because a static pool legitimately references no upstream variable and would otherwise raise a spurious "no variable reference" warning. 7. **Empty pool → step error** at run time (respecting the step's error-handling options) rather than a silent no-op, since an empty pool is a misconfiguration or fully-deleted set. 8. **`Math.random`** is used for selection — no cryptographic guarantee is needed for assignment fairness. ## Testing Per our testing convention (integration test over service/`.spec` tests): added `pick-record-workflow.integration-spec.ts`, which builds a workflow with a manual trigger + a `PICK_RECORD` step, configures a known two-record pool, runs it, and asserts the run completes and the picked record is **always** within the configured pool (verifying the pool filter) across repeated runs. Local verification (typecheck + lint for shared/server/front) is green; running the integration suite and attaching editor screenshots in a follow-up comment. ## Follow-ups - PR 2: `ROUND_ROBIN` + persistent atomic cursor (Redis `incrBy` vs. a Postgres counter table — tradeoff to be documented on that PR) + strategy selector. - PR 3: `LOAD_BALANCED`. - Later (not in this stack): filter-based / variable-list pools, an inline "Assign automatically" entry point on relation fields, OOO-skip / weighting. https://claude.ai/code/session_01MuPWZsqf2bmQSevk6fRbX8 --- _Generated by [Claude Code](https://claude.ai/code/session_01MuPWZsqf2bmQSevk6fRbX8)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21899?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-21 21:51:16 +02:00
Félix Malfait	a0689d1577	feat(workflow): condition filter on database-event triggers (#21868) ... ## Problem Connecting a mailbox bulk-creates contacts via the email/calendar sync, and each `person.upserted` fires the seeded **"Create company when adding a new person"** workflow. The trigger enqueues one run per record (no batching) and each run bills several `WORKFLOW_NODE_RUN` events — so a single mailbox connect can rack up tens of thousands of runs and exhaust credits on a brand-new workspace. The workflow is also redundant on that path: the sync already creates the company from the email domain and links the person to it. ## What this does Adds an optional, user-defined **filter** to database-event (listener) triggers, evaluated in the listener **before a run is enqueued**. Non-matching events never create a run, so they consume zero execution credits. This is the Filter node's capability, lifted to the trigger level, and available for all event types (created / updated / upserted / deleted). The seeded "Create company when adding a new person" workflow now carries a visible trigger filter — `Created by → Source is not Email` **and** `is not Calendar` — so it no longer runs for sync-created contacts, while still running for manually / API / CSV-added people. ## How (reuse) - **Backend:** extracted `evaluateStepFilters()`, shared by the Filter action and the trigger listener's new `eventMatchesRecordFilter` gate. The record is exposed under the `trigger` key so filters reference it exactly like steps do (`{{trigger.properties.after.…}}`). - **Shared:** one optional `filter` added to the database-event trigger zod schema; the front-end type derives from it (settings stay JSON — no codegen). - **Frontend:** extracted `WorkflowStepFilterBuilder` from the Filter action's body; both the Filter action and the trigger editor render it. The field picker needed no changes — at the trigger it already resolves to the record's own fields via `TRIGGER_STEP_ID`. ## Scope / decisions - **No migration for existing workspaces** (by request) — only newly created workspaces get the filtered default; already-created workspaces keep the always-on workflow. - Deliberately did **not** add relation-enrichment to the upsert path (it would add a DB lookup to the very bulk-sync path we're relieving). Trigger filters work on the record's own scalar/composite fields (e.g. `createdBy.source`); relation-based filters work on created/updated where enrichment already runs. ## Verification - Typecheck: `twenty-shared`, `twenty-server`, `twenty-front` all green. - Lint (diff, autofix): 0 warnings / 0 errors across all three. - Unit tests: a new `evaluate-step-filters` spec exercising the exact `createdBy.source IS_NOT` seed mechanism, plus new listener specs proving non-matching events are not enqueued. All backend filter/listener suites pass. - Not run here: integration tests (need a DB) and Storybook. https://claude.ai/code/session_013k36vfekDppwRCgM6Ha7De --- _Generated by [Claude Code](https://claude.ai/code/session_013k36vfekDppwRCgM6Ha7De)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21868?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-21 15:47:06 +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
nitin	973b35989e	Add standard record page layout for calendar events (#21857) ... Moves calendar event details from the bespoke side-panel page to the standard record page layout system. - Adds standard calendar event record page metadata, fields view, widgets, tests, snapshots, and upgrade command for existing workspaces. - Opens calendar events through the generic ViewRecord side-panel path. - Adds participants and call recordings as standard field widgets. - Removes the old custom calendar event side-panel page and related side-panel enum/config entry. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21857?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. --> https://github.com/user-attachments/assets/c1f88cac-1615-478c-a3dd-87d0c61ab9a8 <img width="3024" height="1658" alt="CleanShot 2026-06-19 at 19 01 27@2x" src="https://github.com/user-attachments/assets/c3df5705-ff08-446e-ac3c-6ccb11cf21ec" /> <img width="3024" height="1658" alt="CleanShot 2026-06-19 at 19 01 19@2x" src="https://github.com/user-attachments/assets/633525db-310c-4462-8458-a72068cc1432" />	2026-06-19 20:06:33 +05:30
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
Charles Bochet	0064ff6741	fix(ai): validate AI agent output field names against schema-key constraint (#21834) ... ## Problem On a self-hosted instance, an AI Agent workflow action fails at run time with an opaque model error: ``` The model returned the following errors: tools.0.custom.input_schema.properties: Property keys should match pattern '^[a-zA-Z0-9_.-]{1,64}$' ``` This is Anthropic's validation on tool `input_schema` **property keys**. An AI Agent's structured **Output** fields are turned into a JSON schema and passed to the model as a tool; each output **variable name** becomes a property key. Anthropic rejects any key that does not match `^[a-zA-Z0-9_.-]{1,64}$` — most commonly a name containing a **space** (e.g. `meetings brief`), but also names over 64 characters or with other symbols. Until now nothing validated this: `fieldsToSchema` writes `properties[field.name]` verbatim, so a bad name only failed once the workflow executed, with an error that gives the user no idea what to fix. It doesn't reproduce on every instance — it depends purely on how the workflow's output variables happen to be named. ## Fix Introduce a single shared check, `isValidAgentResponseSchemaPropertyKey`, and enforce it in two places: - **Backend** — `validateAgentResponseFormat` now rejects invalid output field names at agent **save time** with a clear `userFriendlyMessage`, instead of letting the broken schema reach the model. This also gates agents created via the API and re-saves of existing bad data. - **Frontend** — the output schema builder shows an inline error on the Variable Name field as soon as an invalid name is entered. ## Tests - Unit test for the shared validity check (valid + invalid cases: spaces, leading space, empty, > 64 chars, symbols, unicode). - Unit test for `validateAgentResponseFormat` covering text/json formats, valid names, a space in a name, an over-length name, and reporting multiple invalid names at once. ## Notes for the reporter The immediate unblock for an affected workflow is to rename the output variable to remove the space (e.g. `meetings brief` → `meetings_brief`) and retry the run. With this change the bad name is caught up front with an explanation rather than failing mid-run. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21834?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-19 13:50:44 +02:00
Thomas Trompette	4075018834	fix(workflow): label manual trigger record output as Record/Records (#21832) ... ## What The manual trigger output schema exposed the triggering record(s) under a node labeled **Payload**. Relabels it to match what the node actually contains: - **Single-record** availability → **Record** - **Bulk-records** availability → **Records** ## Why "Payload" was a misnomer — the node holds the record(s) that triggered the workflow. This is a display-label-only change. ## Notes for reviewers - **No migration.** The persisted output schema key stays `payload`, so existing variable references (`{{trigger.payload.x}}`) are unaffected. - The front recomputes the output schema on the fly (`computeStepOutputSchema`), so the variable picker shows the new labels immediately, including for existing triggers. - The backend (`workflow-schema.workspace-service`) is updated to match for newly persisted/re-saved schemas. Previously persisted schemas keep "Payload" until re-saved. - Added `WORKFLOW_TRIGGER_RECORD_LABEL` / `WORKFLOW_TRIGGER_RECORDS_LABEL` and removed the now-unused `WORKFLOW_TRIGGER_PAYLOAD_LABEL`. - Unit tests updated for both single and bulk cases (55/55 passing). <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21832?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-19 12:36:14 +02:00
Raphaël Bosi	3675f264f1	Infer record pickers for record-typed logic function workflow inputs (#21494) ... ## Context Logic functions can declare workflow inputs typed as records or arrays of records (e.g. the People Data Labs enrichment functions), but the workflow builder rendered those as a plain text input with a variable picker, which is not usable. ## What this does - Adds an `objectUniversalIdentifier` link on input schema properties, so a record-typed input is tied to a workspace object. - The SDK build infers it from a `TwentyRecord<'objectUniversalIdentifier'>` marker type in the handler signature, reading the object's universal identifier straight from the source; explicit input schemas can still set the field directly. - The workflow builder renders these inputs as a single record picker or a record multi-select with the variable picker on the right. Selected records are stored as record ids; `TwentyRecord<UID>` is a branded `string`, so the handler signature reflects that it receives ids (a bound variable resolves to whatever the referenced step produced). - The multi-select collapses overflowing chips into a `+N` badge (reusing `ExpandableList`) and its variable picker offers both record objects and fields. - Updates the People Data Labs enrichment inputs as the reference implementation. <img width="802" height="824" alt="CleanShot 2026-06-12 at 16 54 10@2x" src="https://github.com/user-attachments/assets/a0896d74-0aab-49bd-a173-14c578a2e533" /> <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21494?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-19 09:10:01 +02:00
Yash Singh	505094650f	fix(twenty-shared): derive short-number suffix from the rounded value (#21591) ... `formatToShortNumber` (`packages/twenty-shared/src/utils/format/formatToShortNumber.ts`) picked the unit suffix from the **raw** value but printed the **rounded** figure, so `999999` rendered as `"1000k"` instead of `"1m"`, and `999999999` as `"1000m"` instead of `"1b"`. This affects number/currency cells, column-footer aggregates, and dashboard charts. The fix replaces the hard-coded band branches with a promotion loop that derives the suffix from the rounded display value, so the suffix and figure always agree at boundaries. Adds boundary, just-below-boundary, and negative-boundary tests. Red-green proven: the two new boundary tests fail on the original source (`expected "1m" but got "1000k"`); the 11 pre-existing tests still pass; all 13 pass with the fix. Verified with a standalone strict `tsc` (0 errors) and oxlint on both changed files. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21591?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-19 08:29:47 +02: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
Félix Malfait	6a1b28bc12	feat(auth): collect the workspace logo on the sign-up creation step (#21723) ... ## What & why A single, consistent **workspace-creation step** for both multi-workspace and single-workspace self-host — collecting **name + logo** (and the **subdomain** in multi-workspace) — which **removes the duplicate name/logo prompt** that previously reappeared on the workspace subdomain (reported after #21641). ## Changes **One creation form for both modes** - With 0 workspaces, both multi-workspace and single-workspace route to the shared `SignInUpWorkspaceCreationForm`; `SignInUp` renders it for the `WorkspaceCreation` step regardless of domain/scope. - The subdomain field shows only in multi-workspace; single-workspace keeps its fixed address. **Logo on the creation step** - New scoped `uploadNewWorkspaceLogo(workspaceId, file)` mutation: the creator sets a logo on their just-created `PENDING_CREATION` workspace via the workspace-agnostic token (membership enforced — only the creator is a member at that point), reusing `uploadWorkspacePicture`. Upload size is capped via `settings.storage.maxFileSize` (also applied to the existing logo / profile-picture uploads). - The picked file is held locally (object-URL preview, revoked on unmount) and uploaded right after creation (non-fatal on failure). **Onboarding step → pure activation loader** - The old "Create your workspace" form (name + logo) is removed. The onboarding step now activates the pending workspace on mount and shows the loader, with a **Retry** action on failure. ## Testing - typecheck (front + server) ✅; oxlint + oxfmt clean on changed files ✅ - Unit tests: `auth.resolver.spec`, `useWorkspaceSubdomainField`, `SignInUpWorkspaceCreationForm` (multi + single-workspace), `useAuth` ✅ - Metadata GraphQL + `twenty-client-sdk` schema regenerated. Follow-up to #21641. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01Xw37hR5seiCyWnppG9z4op --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-18 17:56:14 +02:00
Etienne	c6309fd92b	feat(workflow): auto-layout steps on AI workflow creation via shared tidy-up (#21756) ... ## Context The workflow builder has a "Tidy up" action that auto-positions steps using a Dagre layout. However, this lived entirely in the frontend and depended on node dimensions measured by React Flow after rendering in the browser. As a result, workflows (and steps) created through AI Chat / MCP tools were never laid out: `create_complete_workflow` accepted optional `stepPositions` that the LLM had to invent, and `create_workflow_version_step` stored an optional position verbatim. In practice this produced overlapping / poorly positioned steps. ## What this does Extracts the tidy-up layout into a pure, frontend-free util in `twenty-shared` and reuses it from both the frontend tidy-up and the server, so AI/MCP-created workflows are auto-laid out at creation time. ### twenty-shared - New `computeWorkflowLayout({ nodes, edges, options? })` — a pure Dagre layout over a minimal `{ id, width, height }` / `{ source, target }` graph, returning top-left-anchored positions (matching React Flow). Ignores edges pointing to unknown nodes. - New constants: `WORKFLOW_LAYOUT_DEFAULT_OPTIONS` (ranksep/nodesep/rankdir) and `WORKFLOW_DIAGRAM_DEFAULT_NODE_DIMENSIONS` (estimated node size for server-side layout, where measured sizes are unavailable). - Added `@dagrejs/dagre` dependency. ### twenty-front - `getOrganizedDiagram` now delegates to `computeWorkflowLayout`, passing real measured node sizes. No behavior change for users. ### twenty-server - New `WorkflowVersionWorkspaceService.autoLayoutWorkflowVersion(...)` builds the graph topology via the existing `buildWorkflowGraph` (covers if-else branches and iterator loops), feeds estimated node sizes into `computeWorkflowLayout`, and persists through the existing `updateWorkflowVersionPositions`. - `create_complete_workflow`: removed `stepPositions` from the tool schema; the server always auto-lays out after creation/edges. - `create_workflow_version_step`: re-tidies the whole version after each added step (wired at the tool level so the builder UI is unaffected) and dropped the now redundant `position` field. ## Notes - Server-side layout uses estimated node sizes, so it is "good enough"; opening the workflow and running the existing FE tidy-up refines it with real measured sizes. - Auto-layout is wired in the MCP tools, not in the shared creation service, so manual step creation in the builder UI is unchanged. ## Test plan - [x] `twenty-shared` unit tests for `computeWorkflowLayout` (linear chain, if-else spread, dangling-edge safety) - [x] `twenty-shared` builds; `twenty-server` and `twenty-front` typecheck - [x] Lint/format clean on changed files - [ ] Create a workflow via AI Chat / MCP and confirm steps are laid out without overlap - [x] Add a step via MCP and confirm the version is re-tidied - [ ] Frontend "Tidy up" still behaves as before <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21756?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 14:10:04 +00:00
Etienne	39e00d5853	feat(workflow): expected output schema for runtime-output steps + validation (#21744) ... ## Summary Extends the workflow validation layer (introduced in #21422) and adds a new "expected output schema" capability for steps whose output structure is only known at runtime. Some workflow steps (HTTP Request, Code, Logic Function, AI Agent (coming soon), Webhook trigger) don't have a statically known output shape, so downstream steps can't resolve `{{step.x.y}}` variable paths or validate them. This PR lets users declare a **sample/expected output** for those steps, derives an output schema from it, and uses that schema both to power variable resolution and to surface validation issues at build time. ## What's included ### Expected output schema (shared schemas + types) - New `expectedOutputSchemaShape` reused across the HTTP request, code, logic function and AI agent action settings schemas, plus the webhook trigger schema (`expectedOutputSchema` optional loose object). - Mirrored on the server-side action/trigger settings types. ### Output schema computation (server) - `workflow-schema.workspace-service` now computes a step's output schema from the user-declared `expectedOutputSchema` sample (via `getOutputSchemaFromValue`) when no statically computed schema is available. ### Validation layer (server) - `STEP_HAS_NO_VARIABLE_REFERENCE` (warning): flags steps of `VARIABLE_CONSUMING_ACTION_TYPES` (HTTP_REQUEST, CODE, LOGIC_FUNCTION, SEND_EMAIL, record CRUD) that reference no upstream variable. - `LOGIC_FUNCTION_OUTPUT_SCHEMA_MISMATCH` / `AI_AGENT_OUTPUT_SCHEMA_MISMATCH` (warnings): compare the declared output schema against the expected sample using the new shared `getOutputSchemaMismatchIssues` util (missing keys, leaf/object mismatches, type mismatches). - Trigger is now validated alongside steps (trigger type requirements + trigger variable references). - Validation issues no longer return both `suggestions` and `availablePaths` when they are identical (avoids redundant, costly payloads). ### Shared utilities - New `getOutputSchemaMismatchIssues` (+ tests) in `twenty-shared/logic-function`. - Moved `agentResponseSchemaToOutputSchema` from `twenty-front` into `twenty-shared/ai` so it can be reused on both sides. ### Frontend - New `WorkflowExpectedOutputBodyInput` component (JSON sample editor with validation) used by HTTP request, code, logic function and AI agent step editors. - New `resolvePersistedStepOutputSchema` util + `useStepsOutputSchema` update: resolves a step's output schema from `outputSchema`, falling back to `expectedOutputSchema`, with an AI_AGENT default. - HTTP request / code / logic function editors persist `expectedOutputSchema` and derive `outputSchema` from it. - Webhook trigger default settings include `expectedOutputSchema`. BONUS : iterator loop validation <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21744?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:31:01 +02:00
Thomas Trompette	105f9565a5	feat(workflow): surface manual-trigger payload + metadata in variable picker (#21692) ... ## Summary Step 2 of the manual-trigger output schema restructuring (expand → display → migrate → contract). Builds on the now-merged #21676 (which expanded the runtime payload to serve `payload` and `metadata` siblings at the trigger root). This PR **surfaces** those in the variable picker as nested, expandable nodes: - `trigger.payload.{record fields}` — the record(s) that triggered the run - `trigger.metadata.workspaceMemberId` — who triggered it The flat root fields (`trigger.id`, etc.) remain available, so existing saved variable references keep working until a later migration phase moves them. ### Changes - **twenty-shared**: metadata/payload label constants + `build-manual-trigger-metadata-node` util + barrel exports. - **twenty-front**: `computeStepOutputSchema` MANUAL branch now nests `payload` (RecordNode for SINGLE_RECORD, array Node for BULK_RECORDS, omitted for GLOBAL) and `metadata`; `ManualTriggerOutputSchema` type updated to `{ payload?; metadata }`. - **twenty-server**: `computeTriggerOutputSchemaFromAvailability` mirrors the same nested shape for server-side validation. The key is `metadata` (not `_metadata`) — custom fields can't start with `_`, so collision risk was deemed acceptable. ## Test plan - [x] `npx nx build twenty-shared` - [x] `computeStepOutputSchema` unit tests pass (55) - [x] Manual: create a manual-trigger workflow (GLOBAL / single-record / bulk), confirm the picker shows `payload` and `metadata` as expandable folders and that selecting a field yields `{{trigger.payload.<field>}}` / `{{trigger.metadata.workspaceMemberId}}` > Note: server typecheck has pre-existing unrelated failures on main (Stripe billing mocks, gmail mocks); none touch workflow files. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21692?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:54:35 +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
Félix Malfait	eeed998c9e	Let users pick their workspace subdomain during sign-up (#21641) ... ## What & why During onboarding the workspace subdomain was auto-generated at sign-up and only editable later in Settings. This adds a subdomain picker to the workspace-creation flow, with **live availability checking** and **name-driven auto-fill**. The subdomain is chosen **on the central sign-up domain, before the redirect onto the workspace subdomain** — so there's no mid-onboarding domain switch (which would otherwise force a re-auth, like the Settings "this logs everyone out" flow). It works uniformly for credentials and SSO, since workspace creation is a post-auth mutation. ## Flow Authenticate → **Create a workspace** → new step (workspace name + address with live availability + auto-fill, seeded from the work email) → workspace is created with the chosen subdomain → the single redirect lands on the final subdomain → onboarding modal (name pre-filled). ## Changes **twenty-shared** - `getSubdomainSlugFromDisplayName` — friendly slug from a display name, built on the existing `transliteration` package (also transliterates non-Latin names, e.g. 日本語 → `ri-ben-yu`). **twenty-server** - `checkWorkspaceSubdomainAvailability(subdomain)` query (workspace-agnostic, `UserAuthGuard`) → `{ isValid, available, suggestedSubdomain }`. - `SubdomainManagerService`: availability + suggestion logic with friendly numbered suffixes (`acme`, `acme-2`, …) instead of random hex; `generateSubdomain` reuses it. - `signUpInNewWorkspace` accepts an optional `{ displayName, subdomain }` input (validated; falls back to auto-generation when omitted — backward compatible, so existing callers are unaffected). Concurrent same-subdomain sign-ups return a clear "already taken" error instead of a generic DB error. **twenty-front** - New `SignInUpStep.WorkspaceCreation` step + `useWorkspaceSubdomainField` hook (debounced, stale-response-safe; auto-fills from the name until the user edits it, with a one-click "use suggested" when taken; ignores Enter during IME composition; surfaces a clear error if the availability check fails). - Onboarding modal name pre-filled from the chosen name. ## Testing - Unit tests: shared slug util, the `useWorkspaceSubdomainField` hook (real auto-fill/availability flows via `MockedProvider`), and the workspace-creation component; existing sign-up tests still pass. - Typecheck, lint, and format green across twenty-shared / twenty-server / twenty-front. ## Notes / out of scope - No DB migration — the `subdomain` column already existed. - Self-hosted single-workspace sign-up is unchanged; the step is gated to multi-workspace (global scope). - Low-priority follow-ups: length bounds on the subdomain / displayName inputs, and an integration test for the availability query. --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-17 10:52:51 +02:00
neo773	1ad919955a	Support variables file email attachment (#21613) ... <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21613?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-16 18:11:37 +02:00
Thomas Trompette	ff03e935ef	feat(workflow): expand manual-trigger runtime payload with payload + _metadata (#21676) ... ## Summary Step 1 (**expand**) of restructuring the manual-trigger output so record fields live under a `payload` key and trigger-level metadata (the running workspace member) lives alongside it. This step is **additive and runtime-only** — no behavior changes for existing workflows, and nothing new is surfaced in the variable picker yet. The manual-trigger runtime payload now additively carries: - `payload`: a mirror of the incoming record fields, reachable at `{{trigger.payload.*}}` - `_metadata.workspaceMemberId`: the member who ran the workflow, reachable at `{{trigger._metadata.workspaceMemberId}}` Record fields are still served at the trigger root, so existing `{{trigger.id}}` references keep working unchanged. The output schema / variable picker is intentionally left untouched here. ### Why `_metadata` (underscore) During the transition, record fields still sit at the `trigger` root next to the injected keys. Field API names can't start with `_`, so `_metadata` is collision-proof against any record field; picking the name now avoids a later variable-path rename migration. ### Phasing - **Step 1 (this PR):** write `payload` + `_metadata` at runtime; keep using direct `trigger.*`; don't display the new paths. - **Step 2:** surface `payload` + `_metadata` in the variable picker. - **Step 3:** migrate existing variables to `trigger.payload.*` and contract the root record fields. ## Test plan - [x] `twenty-shared` builds, `twenty-server` typechecks, lint clean on changed files - [x] Manual: run a manually-triggered (SINGLE_RECORD) workflow and confirm the run's trigger payload contains `payload.*` mirroring the record and `_metadata.workspaceMemberId` - [x] Manual: confirm existing `{{trigger.id}}` references still resolve <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21676?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-16 15:49:12 +00:00
nitin	8a866dba54	Add call recording schema and meeting bot scaffold (#21584) ... ## Summary - add 2.13 upgrade commands for call recording request status and dropping CalendarEvent recordingPreference - remove the recording preference from the core CalendarEvent standard object - add a scaffold-generated twenty-meeting-bot app with logo and the CalendarEvent meetingBotPreference field ## Tests - yarn install - yarn lint - yarn twenty dev:typecheck - git diff --check <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21584?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 15:33:12 +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
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	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
martmull	e293c33311	Normalize defaultValue properly (#21511) ... <img width="1506" height="338" alt="image" src="https://github.com/user-attachments/assets/3ee0d5c9-af32-4ef3-83c9-2f4671219126" />	2026-06-12 23:10:51 +02:00
Charles Bochet	926cf2d0cf	fix(zapier): support Select and Multi Select fields (#21509) ... ## Context Closes #15970 Select and Multi Select fields did not show up in the Zapier integration. ## Root cause `computeInputFields` only emitted input fields for an explicit allow-list of field types and silently dropped everything else, so `SELECT` and `MULTI_SELECT` were never surfaced. On top of that, `SELECT`, `MULTI_SELECT` and `RATING` are **GraphQL enums** in Twenty's API. Their values must be sent as unquoted enum literals in a mutation (`stage: SCREENING`), but `handleQueryParams` quoted every string value (`stage: "SCREENING"`), which produces an invalid mutation. So even surfacing the fields would not have been enough to create/update records. ## Changes - Surface `SELECT` (string) and `MULTI_SELECT` (string list) as input fields in `computeInputFields`. - Fetch field `options` in the metadata query and expose them as Zapier `choices` (`value -> label`) so users pick from the real options instead of typing raw enum values. - Emit enum field values **unquoted** in create/update mutations. This is derived from the object schema in `crud_record` and threaded into `handleQueryParams`. This also fixes `RATING`, which was silently broken for the same reason. ## Tests - `computeInputFields`: new test asserting `SELECT`/`MULTI_SELECT` produce the right fields with `choices` and `list`. - `handleQueryParams`: new test asserting enum values are emitted unquoted (scalar and array). ``` Test Suites: 2 passed Tests: 5 passed ``` <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21509?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:54:49 +02:00
Thomas Trompette	a8a8bbb2ed	feat(workflow): add offset to Find Records node for pagination (#21484) ... <img width="471" height="362" alt="Capture d’écran 2026-06-12 à 15 38 45" src="https://github.com/user-attachments/assets/9656d3a6-6f56-4587-add6-55c0a0a32482" /> ## Summary The workflow Find Records (search) node previously exposed only `objectName`, `filter`, `sort`, and `limit` (capped at `QUERY_MAX_RECORDS` = 200), with no way to page beyond the first page of results. This adds an optional **Offset** to the node so a workflow can fetch an arbitrary page (`offset = pageIndex * limit`) while keeping the same filter and sort. The underlying `FindRecordsService` already accepts `offset` (it forwards it to the query runner's `skip`, and stabilizes ordering with an `id` tiebreaker), so this change just threads `offset` through the remaining layers: - `workflowFindRecordsActionSettingsSchema` (shared zod schema) — new optional `offset` - `FindRecordsInput` type — new optional `offset?: number` - `find-records.workflow-action.ts` — forwards `offset` to `FindRecordsService.execute` - `WorkflowEditActionFindRecords.tsx` — new "Offset" number input (non-negative, defaults to 0) with form state + persistence - Default `FIND_RECORDS` step settings — `offset: 0` ### Notes / non-goals - Offset-only, single page: the node returns one page. Looping over all pages inside one run is not included (the Iterator action loops a static array and cannot re-query). The node output already returns `totalCount`, so a workflow can compute total pages as `ceil(totalCount / limit)`. - Offset on very large/changing datasets can be slow or skip/duplicate rows; cursor/keyset pagination would be a future follow-up. ## Test plan - [x] Create a Find Records node, set Limit=50, Offset=0 → returns first page - [x] Set Offset=50 with the same filter/sort → returns the second page (no overlap) - [x] Negative offset shows a validation error and is not saved - [x] Existing Find Records nodes (no offset stored) still run, defaulting to offset 0 - [x] Typecheck/lint pass in CI <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21484?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-12 14:11:53 +00:00
Etienne	fefd9d7704	feat(workflow) - Add validation layer (#21422) ... Add workflow validation framework and consolidate output schema types/search logic into twenty-shared This PR introduces a comprehensive workflow validation system that catches configuration errors at build-time, and consolidates the fragmented output-schema type definitions and variable-search logic from the front-end into twenty-shared **Workflow validation** — A new system that checks workflows for errors before activation: graph connectivity (unreachable steps, dangling references), step parameter schemas (via Zod), variable references (typos, wrong step order), and workspace metadata (non-existent objects). Returns structured errors/warnings with "did you mean?" suggestions. Runs automatically after create_complete_workflow and update_workflow_version_step, and is also available as a standalone validate_workflow tool. **Output schema consolidation** — Moves all output schema types and the variable-search logic from scattered front-end files into twenty-shared, replacing ~800 lines of duplicated per-schema-type code with a single unified searchVariableInOutputSchema dispatcher. To do : - validation on CODE and AGENT step --------- Co-authored-by: Cursor <cursoragent@cursor.com>	2026-06-12 08:23:03 +00:00
Félix Malfait	cf70565976	feat(twenty-server): allow shouldHideEmptyGroups in app view manifest (#21370) ... ## Context The view **Hide empty groups** setting (`shouldHideEmptyGroups`) can be toggled in the UI, is persisted on the `View` entity, exposed in the `CreateView`/`UpdateView` GraphQL inputs, and tracked by the flat-view sync machinery — but it could **not** be set from an app's view manifest. Root cause: the field postdates the manifest plumbing (added in #16385, Dec 2025). Two spots were never updated to thread it through: - `ViewManifest` didn't declare the field. - `fromViewManifestToUniversalFlatView` hardcoded `shouldHideEmptyGroups: false`. Ref: twentyhq/core-team-issues#414 ## Changes - Add optional `shouldHideEmptyGroups?: boolean` to `ViewManifest`. - Read it in the converter (`?? false`), mirroring the existing `isCompact` handling. - Cover it in the converter unit test (default + explicit value). No migration or schema change — the column already exists, and downstream sync (`FLAT_VIEW_EDITABLE_PROPERTIES` + the universal-flat compare type) already handles it. ## Test - `npx jest from-view-manifest-to-universal-flat-view` → 5 passed - `tsgo -p tsconfig.json` (twenty-server) → no new errors - oxlint + oxfmt clean	2026-06-09 14:33:58 +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
martmull	77d1e8ced6	feat(app-dev): sync error hints, flatEntity labels, dev-mode summary UI, and docs (#21252) ... Split out of #21240 — all remaining app-dev improvements. Stacked on #21251 (review/merge that first). - Actionable recovery hints on failed syncs; unified diff renderer; `--dry-run` guard. - Return `flatEntity` on update/delete sync actions and unify the diff label. - Summarize the dev-mode entity list unless `--verbose`. - Docs: syncing & recovery guide + dry-run + open-an-issue prompt. - Live execution mode for synced logic functions; clearer manifest warnings. <img width="1018" height="700" alt="image" src="https://github.com/user-attachments/assets/5e9ce19e-0f1d-4f99-8524-4e118bde932b" />	2026-06-08 15:43:28 +00:00
Marie	2151a414f5	Remove IS_WORKFLOW_RUN_STEP_LOGS_ENABLED feature flag (#21323)	2026-06-08 15:08:20 +00:00
Parship Chowdhury	e04eef0461	fix: wrong record count on deleted and normal records (#21292) ... ## Summary - Resolves #11977 - When looking into the deleted records from People tab (or any object list), the record detail header showing 0/(total records) instead of the correct position among deleted records only, e.g. 1/3 or 3/7. So, this PR makes the count match what users see in the deleted-records list. - Also normal records showing `0/N` in the header when opened from a list view (e.g. `0/48` -> `2/48`). ## Approach I tried to keep the change small and avoid extra server requests: - when a user came from a deleted-records view, we tell our existing queries to include soft-deleted records. - for the position number, we use the record list the user already had open (from the index view they came from) instead of apollo cache, which didn’t include records, especially deleted ones, but also normal records. - normal list behavior is not changed on the server side. ## Test plan - Open people/company, delete a record - Use the side menu -> “see deleted records” - open a deleted record’s details - confirm the header showing the correct position and total (e.g. 1/2, not 0/100) - for normal list: open People (normal list, not deleted) -> click a record -> open full page -> confirm header shows correct position and total (e.g. `2/48`, not `0/48`) ## Screenshots ### Before: <img width="1513" height="309" alt="Screenshot 2026-06-07 135204" src="https://github.com/user-attachments/assets/4754f1a7-8315-4a7a-815f-dda977b09331" /> <img width="1514" height="261" alt="Screenshot 2026-06-07 141735" src="https://github.com/user-attachments/assets/dd5b1834-5d84-49fe-8d20-633428d73502" /> ### After: <img width="1511" height="224" alt="Screenshot 2026-06-07 134946" src="https://github.com/user-attachments/assets/9450af7d-84b9-40bb-95e9-5a8665cc0923" /> <img width="1514" height="288" alt="Screenshot 2026-06-07 135045" src="https://github.com/user-attachments/assets/029ae632-ad7e-451e-8170-a4e4e71ac6f9" /> <img width="1512" height="229" alt="Screenshot 2026-06-07 141642" src="https://github.com/user-attachments/assets/576f4cad-a9e9-4380-aa67-e5f0e976a193" /> --------- Signed-off-by: Parship Chowdhury <parshipchowdhury@gmail.com> Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-08 16:44:03 +02:00
martmull	f20d04eb6e	feat(app-dev): surface metadata diff in dev sync and name failing migration actions (#21249) ... Split out of #21240. - Render the applied metadata changes (created/updated/deleted + identifiers) in the dev sync output instead of a bare `✓ Synced`. - Include the failing entity's `universalIdentifier` in `WorkspaceMigrationRunnerException` messages so conflicts are diagnosable. <img width="637" height="114" alt="image" src="https://github.com/user-attachments/assets/61422a16-370c-4e9b-a2f6-c29ce17f3b1b" /> <img width="497" height="104" alt="image" src="https://github.com/user-attachments/assets/d493c398-da29-49c9-ac5e-aa0f26cd7389" /> <img width="593" height="127" alt="image" src="https://github.com/user-attachments/assets/15e26edc-c0e4-4427-bd34-909040e970c9" /> --------- Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-05 16:35:50 +02:00