381 Commits

Author	SHA1	Message	Date
Thomas Trompette	9dd9709e97	test(workflow): cover the workflow core mirror end to end (#23434) ... ## What Adds the integration coverage `core.workflow` mirroring never had: create, rename, delete, restore and destroy, asserting the core row appears, follows the rename, disappears and comes back. No production code changes. The async `WorkflowCoreDualWriteListener` stays as the mirror for the workflow entity. ## Why this PR changed shape It originally replaced the listener with query hooks, to remove the last async best-effort write path. That was the wrong call, for three reasons found while reviewing it: 1. **It would have introduced drift, not removed it.** `workflow-trigger.workspace-service.ts` updates `lastPublishedVersionId` via `workflowRepository.update(...)` when a version is activated. That is a repository write, not an API mutation, so query hooks never fire for it and `core.workflow.lastPublishedVersionId` would have gone stale on **every workflow activation**. The consistency cron compares that field, so it would surface as `fieldMismatch` drift. The listener catches it because events are emitted at the ORM layer. 2. **Hooks are no more atomic than the listener here.** Workflow CRUD goes through the generic API, so there is no dedicated mutation to wrap and the generic runner holds no transaction: it commits, then runs post-hooks. Both approaches are post-commit, with the same drift guarantees. 3. **Events carry the full record; hook payloads do not.** `workspace-insert-query-builder` passes the full formatted result to the event while the client response is filtered by `returning`. That partial payload is what forced the re-fetches, the `coreWorkflowId` pre-hook injection, and the destroy pre-commit special case. All three were workarounds for a problem the listener does not have. The principle we settled on: **use the transaction where one exists, use the listener where there isn't one.** Post-hooks were the worst of both here. Version *content* writes keep their transactional mirror, since those go through dedicated mutations that own a transaction. ## Note on the test The mirror is asynchronous, so the assertions poll (20 attempts, 250ms) rather than reading core immediately after the mutation returns. Without that it would be racy. ## Verification - `nx typecheck twenty-server` green - `oxfmt` + `oxlint --type-aware` green	2026-07-29 11:20:56 +00:00
martmull	942755d0dd	fix(applications): display the installed application icon (#23411) ... ## Problem After installing an app, its icon is missing across the UI, while application *registration* icons render fine. `Application.logo` holds the manifest path (`public/logo.svg`), which is package-relative and not displayable. The server exposes a `logoUrl` resolve field that turns it into `/public-assets/{workspaceId}/{applicationId}/{logo}`, but on the front end: - `APPLICATION_FRAGMENT` and `FIND_MANY_APPLICATIONS` never selected `Application.logoUrl`. - So the only source of a usable logo url was `currentWorkspace.installedApplications`, which is fetched by `GetCurrentUser` at bootstrap. Nothing refreshed it after `installApplication`, so a freshly installed app was absent from that list. - `useApplicationChipData` then fell through to `fallbackApplicationData`, which callers populated with the raw `logo` path. `getAbsoluteImageUrl('public/logo.svg')` yields `{serverUrl}/public/logo.svg`, which 404s, so the avatar rendered as a letter placeholder. ## Before / After An app installed while the applications page is open, so the workspace snapshot loaded at bootstrap does not know about it yet: | Before | After | |---|---| | <img src="https://raw.githubusercontent.com/twentyhq/twenty/e27a817fd95c5e44c1fbb64fd4fd68525daeee61/.pr-assets/app-icon-before.png" width="480"> | <img src="https://raw.githubusercontent.com/twentyhq/twenty/e27a817fd95c5e44c1fbb64fd4fd68525daeee61/.pr-assets/app-icon-after.png" width="480"> | ## Changes - Select `logoUrl` on `Application` in `APPLICATION_FRAGMENT` and `FIND_MANY_APPLICATIONS`. - Drop `logo` from `ApplicationDisplayData` and from the `AppChip` / subtable fallback props, so a package-relative path can no longer reach an `img` src. Call sites that already passed a url under `logo` now pass `logoUrl`. - `SettingsApplicationDetails` and `SettingsApplicationsTable` pass the application's own `logoUrl`. - On install, add the returned application to `currentWorkspace.installedApplications` instead of reloading the current user, so the chips that resolve by `applicationId` only (nav menu items, object/field tables, tool rows, workflow nodes) pick it up. - Stop exposing `logo` on the `Application` GraphQL type: nothing selects it anymore, and having both `logo` (package-relative path) and `logoUrl` (display url) was the source of the bug. The column is still read server-side to build `logoUrl`. - Regenerated `generated-metadata/graphql.ts`. ## Verification Ran the stack locally against a seeded workspace with an installed app whose logo lives at `public/logo.png`: - `findManyApplications` returns a `logoUrl` under `/public-assets/...`, and that url serves `200 image/png`. - Reproduced the bug and the fix in the browser with the scenario shown above (screenshots taken on the base commit and on this branch). - `npx nx typecheck twenty-front`, `npx nx typecheck twenty-server`, `npx nx lint:diff-with-main` on both, and the application settings jest suites pass. --- _Generated by [Claude Code](https://claude.ai/code/session_01N8r4z2dZ553nAnCNe7GxMH)_ [Review in cubic](https://cubic.dev/pr/twentyhq/twenty/pull/23411?utm_source=github)	2026-07-28 14:59:13 +00:00
Thomas Trompette	2c49c4169c	feat(workflow): remove async workflowVersion core dual-write listener (#23374) ... ## What Removes `WorkflowVersionCoreDualWriteListener` (and its now-empty module), replacing the last async best-effort core writes for workflow versions with synchronous mirrors. Adds one missing synchronous funnel so nothing is left uncovered. ## Why After #23356, the listener's `handleRestored` / `handleDeleted` / `handleDestroyed` handlers are redundant with the synchronous lifecycle mirror, so the async path (which can silently drift on failure) can go. While removing it I found one path the listener was **not** redundant on: **direct `deleteOneWorkflowVersion` (discard draft)** is an allowed operation (discard a DRAFT version that isn't the only version, via the `DISCARD_DRAFT_WORKFLOW` command) and had **no** synchronous post-hook. The async listener was the sole thing deleting its core row. Removing the listener without a replacement would have drifted on every draft discard. So this PR also adds a `workflowVersion.deleteOne` post-hook that mirrors the deletion to core. ## Coverage after this change | version lifecycle path | synchronous coverage | | --- | --- | | `deleteOneWorkflowVersion` (discard draft) | **new** `workflowVersion.deleteOne` post-hook | | delete via workflow cascade | `handleWorkflowSubEntities` -> `deleteCoreVersionsByWorkflowIds` (#23356) | | restore via workflow cascade | `handleWorkflowSubEntities` -> `recreateCoreVersionsByWorkflowId` (#23356) | | destroy via workflow | `workflow.destroy*` post-hooks (#23356) | | `deleteMany` / `destroyOne|Many` / `restoreOne|Many` version | blocked by pre-hooks ("Method not allowed") | ## Notes - The new post-hook re-fetches the version (`withDeleted`) to resolve its `coreWorkflowVersionId`, because the delete post-hook payload only carries the columns the client selected (the delete `RETURNING` set is built from `selectedFieldsResult.select`), so `coreWorkflowVersionId` is not reliably present. - `deleteCoreVersionsByWorkspaceVersionIds` deletes precisely by `coreWorkflowVersionId` (not by `workflowId`), so discarding one draft does not touch the core rows of the workflow's other versions. - The workflow-side `WorkflowCoreSyncModule` listener is intentionally left in place (separate migration track). ## Verification - `nx typecheck twenty-server` green - `nx lint:diff-with-main twenty-server` green - Added integration test `workflow-version-discard-draft-core-mirror`: activate v1, create a draft, discard it, assert only the draft's core row is removed and the active version's core row remains. - Live run on a dev instance still pending. ## Merge gate Per the migration plan, removing the async backstop should land only after the drift cron reports zero drift over a soak period. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23374?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-07-27 15:52:15 +00:00
Thomas Trompette	79bf20515d	feat(workflow): mirror version delete/restore/destroy to core transactionally (#23356) ... Next step in the workflowVersion -> core soft-ref migration. The transactional mirror (#23243) made **content** writes (create/update) drift-free. This does the same for the **lifecycle** events (delete / restore / destroy), which were still handled only by the async best-effort listener. It's the prerequisite for dropping that listener. ## What changed `delete` and `restore` already soft-delete / restore the workflow's versions inside `handleWorkflowSubEntities` (twenty doesn't cascade soft-deletes, so it does each sub-entity explicitly). So the core delete/recreate just sits next to the existing version write: - **delete** — after `workflowVersionRepository.softDelete({ workflowId })`, `deleteCoreVersionsByWorkflowIds` removes the `core.workflowVersion` rows (`workflowId IN (...)`). (`deactivateVersionOnDelete` no longer re-mirrors the deactivated version — that was recreating the core row it just deleted; it only flips the workspace status to `DEACTIVATED` so a restore comes back deactivated.) - **restore** — after `workflowVersionRepository.restore({ workflowId })`, `recreateCoreVersionsByWorkflowId` re-reads the restored versions and reuses the existing `upsertToCore` (which reuses the stored `coreWorkflowVersionId` soft-ref, so rows come back with their original ids and current status). - **destroy** — version destroy isn't done in `handleWorkflowSubEntities` (it happens via the generic cascade), so there's no existing place to hang the core delete. New `workflow.destroyOne`/`destroyMany` **post**-hooks call `deleteCoreVersionsByWorkflowIds` (batched `IN`) only after the destroy commits, so a rejected destroy can't remove core rows while the workspace versions survive. No new transactional wrappers or raw SQL — the delete/recreate reuse the existing `WorkflowVersionCoreSyncService` methods (`deleteFromCore`-style delete, `upsertToCore`). The async listener stays as an idempotent backstop until the cron soaks zero drift. ## Async listener kept as backstop `handleRestored` / `handleDeleted` / `handleDestroyed` stay for now. Both paths are idempotent (delete-of-deleted is a no-op; upsert converges), so they don't conflict. Those handlers come out in a follow-up once the consistency cron soaks zero drift - which this PR unblocks. ## Verification Lifecycle integration test — creates a workflow, **activates** the version (the active path is where the delete re-mirror bug bit), then asserts the core row: present -> gone after delete -> back after restore (as `DEACTIVATED`, same id) -> gone after destroy. Plus the existing `workflow-resolver` delete/restore suite (regression, since `handleWorkflowSubEntities` is shared). Also verified **live** on a running instance against the real DB: the full active-version lifecycle above, plus a batched `destroyWorkflows` on two workflows removing both core rows in one `IN` delete. `nx typecheck` + oxlint + oxfmt clean. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23356?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-07-27 14:43:59 +00:00
Raphaël Bosi	56245a35af	Stop leaking the refresh token in the social SSO redirect URL (#23061) ... The Google/Microsoft callback for a sign-in with no target workspace redirected to `/sign-in-up?tokenPair={...}`, putting a 60-day refresh token in a query string. Those persist in browser history, `Referer` headers and access logs. It now carries a single-use, 5-minute opaque token in the URL fragment, which the frontend exchanges over POST. Browsers never send the fragment on the wire, so the token stays out of access logs, proxies and `Referer` headers entirely. Redemption claims the row with a `DELETE` guarded on `revokedAt`/`deletedAt` being null, so concurrent requests cannot each mint a refresh token and a revoked token cannot redeem. Enterprise SSO (OIDC/SAML) already used a POST exchange and is unchanged. ```mermaid sequenceDiagram participant Browser participant Server participant DB Note over Browser,Server: before, the redirect carried access + 60-day refresh in ?tokenPair Browser->>Server: GET /auth/google/redirect Server->>DB: store sha256(token), expires in 5 min Server-->>Browser: 302 /sign-in-up#ssoExchangeToken=opaque Note over Browser: fragment never sent back to any server Browser->>Server: POST getAuthTokensFromSSOExchangeToken Server->>DB: guarded DELETE, single-use claim Server-->>Browser: access + refresh token, in the response body ``` Since the token is single-use, the refresh token is minted at redemption instead of at callback, so an abandoned redirect leaves an inert expired hash rather than a live credential. Redemption lives in its own `SignInUpSSOExchangeTokenEffect` + `useRedeemSSOExchangeToken`, mirroring the existing `VerifyLoginTokenEffect` + `useVerifyLogin` pair, so `SignInUpGlobalScopeFormEffect` only loses the vulnerable branch. Like `useVerifyLogin`, the hook clears any stale token pair before exchanging. The effect reads `window.location.hash` live and strips it synchronously, which doubles as the StrictMode double-invocation latch. Remaining exposure is the browser itself (history until the synchronous strip, client-side scripts), same as any fragment-based OAuth response. `loginToken` on the workspace-targeted branch still travels as `/verify?loginToken=` and is replayable for 15 minutes; moving it to the fragment too is a separate change. A fast instance command adds a unique partial index on `("type", "value")` for live SSO exchange tokens, so redemption is an index lookup instead of a full scan of the shared token table and at most one row can ever match.	2026-07-27 12:58:42 +00:00
Thomas Trompette	46a3a83866	feat(workflow): mirror all workflowVersion writes to core in-transaction, drop async create/update dual-write (#23243) ... Switches the workflowVersion -> core dual-write from the async, best-effort listener to a **transactional mirror**, wires every content-write funnel through it, and drops the async create/update handlers. Core can no longer drift from the workspace on any covered path: the core copy commits or rolls back atomically with the workspace write. ## Helper (`WorkflowVersionCoreSyncService`) Two entry points, both writing `core.workflowVersion` and stamping the `coreWorkflowVersionId` soft-ref on the **caller's transaction manager**: - `writeWorkflowVersionAndMirror(workspaceId, write)` - for funnels that don't own a transaction. Opens a workspace queryRunner, runs the caller's workspace write on that manager, re-reads the row, mirrors to core in the same tx, commits, then invalidates the trigger-map cache post-commit. - `mirrorWorkflowVersionWrite({ workspaceId, entityManager, workflowVersion })` - for funnels that already own a queryRunner tx (activation / deactivation / delete-cascade); they just gain this one call on their existing manager before commit. `invalidateAutomatedTriggerMaps` is public so tx-owning callers run it post-commit. ## Funnels wired (all content writes now mirror in-transaction) - `updateWorkflowVersionStepsAndTrigger` (central builder step/trigger edit) - edge create/delete (4 trigger/step writes) - `createDraftFromWorkflowVersion` (update + insert), `duplicateWorkflow` (content update), `updateWorkflowVersionPositions` - iterator / if-else empty-node step writes - `workflow.createOne` / `createMany` post-hooks (v1 draft insert) - AI `create_complete_workflow` tool (v1 insert) - activation / deactivation status writes (ACTIVE / ARCHIVED / DEACTIVATED) on their existing tx - `deactivateVersionOnDelete` cascade (ACTIVE -> DEACTIVATED) on its existing tx Direct `workflowVersion.createOne/createMany` is forbidden by a pre-hook, so there is no un-funneled create path. ## Async listener trimmed `handleCreated` and `handleUpdated` are removed: every create/update now mirrors in-transaction, so the post-commit handlers were redundant and were the source of the rollback-drift (an edit that rolls back still emitted an `UPDATED` event carrying the uncommitted payload, which the async listener wrote to core). `handleRestored`, `handleDeleted`, `handleDestroyed` are **kept**. Soft-delete/restore go through the generic ORM (not a funnel): `handleDeleted` drops the core row on soft-delete, and `handleRestored` recreates it on restore (the restore path just calls `workflowVersionRepository.restore()`). Removing the restore handler would leave restored versions with no core row, so the delete/restore pair stays async. ## Why the core write is raw SQL `core.workflowVersion` is on the core DataSource, not the workspace DataSource, so a repository can't be pointed at it from the workspace queryRunner's manager. But both schemas are one Postgres DB and a queryRunner is a single connection, so a schema-qualified `INSERT INTO core."workflowVersion" ... ON CONFLICT` on that manager participates in the workspace transaction (the prefill util's pattern). The workspace write and soft-ref write-back go through the ORM's `repository.update(criteria, data, undefined, queryRunner.manager)`, so the source-of-truth workspace write keeps its ORM machinery (actor stamping, search vector, events); only the dumb core mirror is raw, confined to the helper. **jsonb:** the raw insert has no entity transformer, so `triggers`/`steps` are passed as JSON strings (Postgres parses them) - the inverse of the prefill core insert (the #23204 double-encode trap), covered by the test. `universalIdentifier` is minted only for a new link; on conflict only `triggers`/`steps`/`status` are updated. ## Test In-process integration test: opens a workspace queryRunner, calls the helper, asserts the core row is visible inside the tx with correct native jsonb, rolls back, asserts the core row is gone - empirically confirming one workspace queryRunner writes `core.*` in the same tx. ## Review feedback addressed - **Duplicate atomicity:** `duplicateWorkflow` now inserts the draft version with its final steps/trigger inside `writeWorkflowVersionAndMirror`, so a mirror failure rolls back the whole version instead of leaving an unmirrored empty draft. - **Delete cascade:** `deactivateVersionOnDelete` moved its command-menu cleanup after commit, so a rolled-back deactivation can no longer strip the menu item from a still-active version. - **Rollback drift / unlinked rows:** resolved structurally by the in-transaction mirror + removal of the async CREATED/UPDATED handlers, and by the soft-ref-field guard that skips mirroring (returns null) on workspaces without `coreWorkflowVersionId`. - **Unit suites:** the step-helpers, step-operations and edge suites now provide a `WorkflowVersionCoreSyncService` mock whose `writeWorkflowVersionAndMirror` runs the write callback against the test repo; all three pass (35 tests). ## Verification Rebased onto `origin/main`. `nx typecheck twenty-server` is green, the three affected unit suites pass (35 tests), and every changed file passes type-aware oxlint + oxfmt. Integration suites were failing only on behind-main DB-init drift (`core.keyValuePair` / data-migration), which the rebase resolves. Live end-to-end test on a running instance still pending.	2026-07-27 09:17:17 +00:00
Thomas Trompette	cbcfba0de2	feat(workflow): dedicated updateWorkflowVersionTrigger mutation + close version CRUD holes (#23207) ... Prerequisite for the workflow-core soft-ref migration: every `workflowVersion` content write must go through a dedicated, draft-guarded server mutation so it can later be wrapped in a transactional core mirror. This closes the generic-CRUD holes that let writes bypass that path. ## Part A - dedicated `updateWorkflowVersionTrigger` mutation The builder saved a version's trigger through generic `updateOneWorkflowVersion` - the only content write not going through a dedicated mutation. Added: - Server: `updateWorkflowVersionTrigger(input: { workflowVersionId, trigger })` resolver + `WorkflowVersionStepWorkspaceService.updateWorkflowVersionTrigger`, draft-guarded via `getValidatedDraftWorkflowVersion` then `updateWorkflowVersionStepsAndTrigger` (reuses existing write logic). - Front: `useUpdateWorkflowVersionTrigger` now calls the dedicated mutation instead of `useUpdateOneRecord`. ## Part B - restrict generic `updateOneWorkflowVersion` `validateWorkflowVersionForUpdateOne` previously allowed writing `trigger`, `position`, `workflowId` (re-parenting), `coreWorkflowVersionId`, and let `steps: null` slip through on a draft. It now rejects any update that sets `steps`, `trigger`, `status`, `workflowId`, or `coreWorkflowVersionId`, or that clears the `name`, while still allowing a plain rename. (A name-only allowlist was tried first but blocked legitimate renames - at the pre-hook the generic update payload is not single-key - so it was replaced by this denylist, verified live.) ## Part C - close the destroy/restore hole `workflowVersion` had no `destroyOne/destroyMany/restoreOne/restoreMany` query hooks, so a caller with object permission could hard-destroy any version (including active) or resurrect one with no validation. Added pre-hooks that forbid all four via the API ("Method not allowed"), matching the existing forbidden generic mutations (`createOne`, `deleteMany`, ...). Rationale: there is no legitimate API use for standalone version destroy/restore - retention purging happens through the trash-cleanup cron (internal, not hook-gated) and restore happens through the workflow-restore cascade or create-draft-from-version. ## Tests Integration specs that set a trigger through the generic mutation were migrated to the new `updateWorkflowVersionTrigger` mutation (new `update-workflow-version-trigger.util.ts`). Unit test for the front hook updated. ## Verification - `twenty-server` + `twenty-front` typecheck: clean. - oxlint + oxfmt on all changed files: clean. - `graphql.ts` regenerated for the new mutation; its types match the server DTOs exactly. Local `graphql:generate` introspects a running server, so it only succeeds against a server built from this branch - CI regenerates against the PR server and verifies. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23207?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: prastoin <paul@twenty.com>	2026-07-24 14:32:09 +00:00
Raphaël Bosi	d1c6b8ee72	Show relation record labels instead of UUIDs in dashboard charts (#23163) ... https://github.com/user-attachments/assets/d012a013-2c90-49a1-a27e-b8e4b684a84f Charts grouped by a relation without a sub-field rendered raw FK UUIDs on axis ticks, legends and tooltips. The server now batch-resolves the grouped record ids to their label identifier through a permission-scoped query and formats every bucket with the record's display name. Unresolvable records (deleted or not readable) render as Unknown and their ids are stripped from the response payload. Same-named records get an ordinal suffix so their buckets don't merge. Covers bar, line and pie, plain and morph relations. ```mermaid flowchart TD A["Dashboard widget load"] --> B["Chart data service<br/>(bar / line / pie)"] B --> C["executeGroupByQuery:<br/>group by relation FK id,<br/>ORDER BY target label identifier,<br/>scoped to source object permissions"] C --> D["filterOutEmptyChartBuckets"] D --> E{"Bare relation axis?<br/>(no sub-field)"} subgraph RL["ChartRelationLabelService.resolveRelationLabels"] direction TB G1["Collect distinct record ids<br/>per target object"] --> G2["Batch SELECT label identifier columns,<br/>scoped to TARGET object permissions"] G2 --> G3["buildRawLabelByRecordId:<br/>display name per record"] G3 --> G4["buildUniqueRelationLabels:<br/>suffix duplicates, Unknown for unresolved"] end E -- No --> H["formatDimensionValue per bucket"] E -- Yes --> G1 G4 --> H H --> I["Strip unresolved ids from<br/>formattedToRawLookup"] I --> J["Chart DTO to frontend"] ``` The chart settings sub-field dropdown gains a Record option to group by the related record itself, and now only offers sub-fields the backend accepts (system fields like a workspace member's updatedBy were selectable but rejected at query time). Chart-data errors are now logged server-side. Also fixes two latent bugs on this path: sorting a bare-relation chart by field threw `Cannot orderBy unknown field: agentId`, and the pie chart truncated slices before sorting. The AI dashboard tool guidance and the seeded dashboards no longer force the sub-field workaround. The group-by query orders buckets by the related record's label identifier at the database level (the engine now accepts ordering by a target field when grouping by its id), so with more than 100 distinct related records the surviving buckets match the label order.	2026-07-24 14:12:22 +00:00
Thomas Trompette	25f28ee299	Fix TWENTY-SERVER-60Y: register permissions exception filter globally (#23104) ... ## Context Sentry [TWENTY-SERVER-60Y](https://twenty-v7.sentry.io/issues/6633503406) ("Permission Denied: Entity performing the request does not have permission") has ~12.9k occurrences / 151 users. It groups by the shared throw site `settings-permission.guard.ts:57`, so it's a **catch-all bucket** for settings-permission denials across many resolvers, not a single operation. Sampled events include `findOneApplication` (app runtimes reading their own `applicationVariables`), `uploadFilesFieldFileByUniversalIdentifier`, `UpdatePageLayoutWithTabsAndWidgets`, `CreateFileUpload`, etc. ## Root cause Settings-permission denials are only converted to a client-appropriate `FORBIDDEN` when a resolver manually attaches `PermissionsGraphqlApiExceptionFilter`. **28** GraphQL resolvers do; **~35** guarded resolvers do not. On those, the guard-thrown `PermissionsException` (a `CustomException`, not a `BaseGraphQLError`) falls through to the Yoga error hook, is serialized as `INTERNAL_SERVER_ERROR`, and `shouldCaptureException` reports it to Sentry as a 500-class error. REST is not affected: every `SettingsPermissionGuard` controller already carries `PermissionsRestApiExceptionFilter` (15/15). ## Fix Register `PermissionsGraphqlApiExceptionFilter` globally via `APP_FILTER` in the core and metadata engine modules, mirroring the existing global GraphQL filters `BillingGraphqlApiExceptionFilter` and `FlatEntityMapsGraphqlApiExceptionFilter`. The filter is guarded on the GraphQL context (`host.getType()`), so REST keeps its existing per-controller filter untouched and no request-scoped dependency is pulled into a global provider. Every settings-guarded resolver now returns `FORBIDDEN` for denials, which is both the correct client error code and excluded from Sentry. Existing per-resolver `@UseFilters(PermissionsGraphqlApiExceptionFilter)` entries remain valid (handler-scoped takes precedence, identical result); collapsing them into the global registration is a possible follow-up. ## Test Added a case to `granular-settings-permissions.integration-spec.ts`: a member without the `APPLICATIONS` flag calling `findOneApplication{applicationVariables{key value}}` (the exact Sentry query, and a resolver with **no** resolver-scoped filter) must receive `FORBIDDEN`, exercising the global filter. Verified against the local test DB: - With the global filter: passes (`FORBIDDEN`). - Without it: fails with `INTERNAL_SERVER_ERROR`, reproducing the leak. - The existing roles / workspace-members / api-keys denial tests (per-resolver filters) still pass, confirming no precedence conflict and no boot issue from dual `APP_FILTER` registration. Fixes TWENTY-SERVER-60Y	2026-07-22 12:10:49 +02:00
Raphaël Bosi	240e185323	Show connect emails step to invited users without granting credits (#23058) ... Invited users never saw the connect-emails onboarding step, so they could not connect their inbox while onboarding. Now they do, but only the first user (the workspace creator) earns the import-contacts reward for it. The credit is gated on the workspace having a single member, reusing the same "first user" signal the frontend already uses to gate the invite-team step. The connect-account step is still claimed for everyone so invited users' onboarding advances normally. The frontend hides the "free credits" tag and the header counter bump for invited users, so we do not promise credits they will not receive. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23058?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-07-20 17:00:39 +02:00
Charles Bochet	39082cf787	Only show the install-apps onboarding step to workspace creators (#22990) ... New users joining an existing workspace through an invite link were routed through the "Install your first apps" onboarding step, which is meant for workspace creation only. #22347 set `ONBOARDING_INSTALL_APPS_PENDING` inside `activateOnboardingForUser`, which is shared by both sign-up paths. Gate it per path like the connect-account step: `true` on `signUpOnNewWorkspace`, `false` on `signInUpOnExistingWorkspace`. Verified locally: invited users now go straight from create-profile into the workspace, and workspace creators still get the install-apps step. Covered by a unit test on the invite path and integration tests asserting the onboarding status per sign-up path (invite → `PROFILE_CREATION`; workspace creation → `SYNC_EMAIL` then `APPS_INSTALLATION`).	2026-07-17 15:33:42 +02:00
Weiko	a5108d512f	Block filters on restricted fields (#22873) ... ## Summary - Reject filter conditions that target fields without read access, including relation traversals - Add unit and integration coverage for denied field filter access The issue is an information leak through filtering: a user who cannot read a field can still infer its values from totalCount ### Manual reproduction - Create or use a non-admin role. - Give it read access to People records. - Disable read access to the Person jobTitle field. - Assign a test member to that role. - Authenticate as that member. Run: ```gql query People($filter: PersonFilterInput) { people(filter: $filter, first: 0) { totalCount } } Variables: { "filter": { "jobTitle": { "like": "Par%" } } } ``` Ensure at least one Person has a matching jobTitle. Before the fix, the request succeeds: ```gql { "data": { "people": { "totalCount": 1 } } } ``` The caller can probe restricted values using different filters. After the fix, it returns a permission error: ```gql { "errors": [ { "message": "Permission denied" } ] } ``` The same should happen through a relation filter, for example filtering Companies by a restricted Person field: ```gql query Companies($filter: CompanyFilterInput) { companies(filter: $filter, first: 0) { totalCount } } { "filter": { "people": { "jobTitle": { "like": "Par%" } } } } ```	2026-07-16 15:19:46 +02:00
martmull	7381038452	Paginate admin panel app registrations list (#22734) ... ## Context The `findAllApplicationRegistrations` query on the admin panel Apps page (`/settings/admin-panel#apps`) loaded every application registration at once, with search and filtering done client-side. ## Changes **Server** - `findAllApplicationRegistrations` now takes `limit` / `offset` / `searchTerm` / `isPreInstalledOnly` args and returns a `PaginatedApplicationRegistrations` object (`registrations`, `totalCount`, `hasMore`), following the same pattern as `getQueueJobs`. - `ApplicationRegistrationService.findAll` uses `findAndCount` with `take`/`skip`, and moves the search (name, source package, universal identifier via `ILIKE`) and the pre-installed filter into the SQL query, mirroring how `getInstalledWorkspacesGlobal` filters installed workspaces. **Frontend** - `SettingsAdminApps` passes the page, the debounced search term (300ms, like the installed workspaces table), and the pre-installed toggle as query variables instead of filtering client-side. - Adds a Previous / Next pagination footer (25 per page) matching the queue jobs table, shown only when there is more than one page. - The "unconfigured first" ordering is kept within each page (`isConfigured` is a dataloader-resolved field, so it can't be sorted in SQL). ## Notes - Regenerated `generated-admin/graphql.ts` follows in a subsequent commit. --- _Generated by [Claude Code](https://claude.ai/code/session_015erumgPozkbNA3zPeKrrFW)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22734?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: Weiko <corentin@twenty.com>	2026-07-13 14:07:11 +02:00
Thomas Trompette	cb2e325c4b	fix(workflow): make prefilled workflow ids unique per workspace (#22800) ... ## Problem \`prefillWorkflows\` (run for every workspace on \`activateWorkspace\`) inserts workflows and versions with **hardcoded ids** (\`QUICK_LEAD_WORKFLOW_ID = 8b213cac...\`, etc.). So every workspace carries the same workflow/version record ids. Within a workspace schema that's harmless, but it means workspace record ids are **not unique across workspaces**, which: - breaks the workflowVersion backfill on the shared core table (surfaced as the \`IDX_WORKFLOW_VERSION_ONE_ACTIVE_PER_WORKFLOW\` duplicate-key error, since multiple workspaces claim the same active \`workflowId\`), and - collides on \`core.workflow\`/\`core.workflowVersion\` PKs once workflows migrate to core (the core row reuses the workspace record id), causing cross-workspace clobbering. ## Fix Derive the prefill ids **deterministically per workspace**: \`getWorkflowPrefillIds(workspaceId)\` returns \`v5(label:workspaceId, namespace)\` for each of the workflow/version/trigger ids. Deterministic (stable across the idempotent \`orIgnore\` re-runs) but unique per workspace. The command-menu-item prefill uses the same helper so its \`workflowVersionId\` reference stays consistent. Only affects **new** workspaces; existing workspaces keep their current ids (prefill is skipped on re-activation). ## Test Reset seeds two workspaces; both now get a Quick Lead workflow with a **distinct** v5-derived id (not the old \`8b213cac\`), and internal references stay consistent (\`version.workflowId == workflow.id\`, \`lastPublishedVersionId == version.id\`). Typecheck + lint clean. Companion to #22795 (which scopes the active index to workspace). Together they fix the backfill duplicate-id failures. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22800?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-07-10 16:21:04 +02:00
Abdul Rahman	ffdda50afc	remove nestjs-query auto-resolver from index-metadata (#22775) ... ## Summary Removes the `NestjsQueryGraphQLModule.forFeature` block from `IndexMetadataModule`, continuing the incremental migration off `@ptc-org/nestjs-query`. - Drops the dead auto-generated read surface: `index` and `indexMetadatas` queries, the `IndexConnection` / `IndexObjectMetadataConnection` types, and the `Index.objectMetadata` field. No client consumes these — the frontend reads indexes via `ObjectMetadata.indexMetadatas`. - Keeps `IndexMetadataDTO` nestjs-query-compatible (`@Authorize`, `@FilterableField`, `@QueryOptions`, `@IDField`) because `ObjectMetadataDTO` still references it via `@CursorConnection('indexMetadatas')` until object-metadata is migrated. - Hand-written `createOneIndex` / `deleteOneIndex` mutations and the `indexFieldMetadataList` resolve-field are unchanged. - Deletes the now-obsolete `index-metadatas` integration test and regenerates the GraphQL schema artifacts (frontend + client-sdk). ## Breaking change This is an intentional GraphQL schema breaking change (`api-breaking-changes` CI will flag it) <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22775?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-07-10 14:00:23 +02:00
Paul Rastoin	163c96c2e5	Validate range version app dev sync (#22625) ... # Introduction Also now validating the workspace version when running a sync manifest <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22625?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-07-08 16:37:42 +00:00
Etienne	54aa52d11c	feat(index): support composite unique indexes in create-many upsert conflict resolution (#22604) ... ## Context The `createMany` upsert path resolved conflicts by scanning individual field metadata and only treating a field as a conflict target when it was flagged `isUnique` (plus the primary `id`). This ignored **composite unique indexes** (multi-column unique constraints), so upserting against a multi-field unique key never matched an existing row and could either insert a duplicate or fail. ## What changed - **Conflict groups are now derived from unique indexes**, not from per-field `isUnique` flags. `getConflictingFields` reads the object's index metadata (`flatIndexMaps`) and builds one `ConflictingFieldGroup` per unique index (the primary `id` remains its own group). - Each index group correctly expands its fields into DB columns, handling: - **Composite field types** — expands to the sub-columns included in the unique constraint (or a specific sub-field when the index targets one). - **`MANY_TO_ONE` relation fields** — resolves to the join column name. - **Scalar fields** — used directly. - `ConflictingFieldGroup.baseField: string` → **`baseFields: string[]`**, since a composite index spans multiple fields. - **Clearer multi-match error message**: conflicting values are now grouped per index (`baseFields (fullPath: value, ...)`, groups joined by `;`) so it's obvious which unique key caused the ambiguity when a payload matches different rows across different indexes. - `CommonCreateManyQueryRunnerService` now fetches `flatIndexMaps` via `WorkspaceManyOrAllFlatEntityMapsCacheService` and passes them into `getConflictingFields`; the cache module is wired into `CoreCommonApiModule`. ## Tests - New integration suite `composite-unique-index-upsert.integration-spec.ts`: - single composite unique index — insert, update-on-match, and insert-when-key-differs - **two independent composite unique indexes** — happy path (single row matches both) and failure path (payload matches different rows across the two indexes → `Multiple records found with the same unique field values` / `BAD_USER_INPUT`). - Updated unit specs for `get-conflicting-fields`, `get-matching-record-id`, `build-where-conditions`, and `categorize-records` to reflect the index-driven grouping and the `baseFields[]` shape. ## Test plan - [ ] `npx nx run twenty-server:test:integration:with-db-reset -- composite-unique-index-upsert` - [ ] `npx nx test twenty-server -- get-conflicting-fields get-matching-record-id build-where-conditions categorize-records` - [ ] Manual: upsert against a composite unique index updates the matching row instead of inserting a duplicate. fixes https://github.com/twentyhq/twenty/issues/22580#issuecomment-4894266699 <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22604?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-07-07 13:54:33 +02:00
martmull	d6b6962604	feat(files): content-verify direct uploads and pin pending files to octet-stream (#22533) ... ## Context Follow-up to #22449 (direct-to-storage upload endpoints). In that flow `createFileUpload` inserts a `PENDING` file record before any bytes exist, and until now it guessed the mime type from the **filename extension** — an untrusted, client-controlled value. This PR makes a pending file opaque and only trusts a mime type that was verified against the actual stored bytes. ## What this does **1. A pending file is always `application/octet-stream`.** `createFileUpload` records the pending file — and signs the presigned PUT — as `application/octet-stream`. The extension is still kept on the stored object name so the content can be checked against it later. **2. Content verification at completion.** `completeFileUpload`, after the existing size check, reads a **bounded prefix** of the stored object (`readReadablePrefix`, capped at 64 KiB — a large object is never buffered in full) and runs the existing `extractFileInfoOrThrow` util to detect the real mime type from the content. It: - writes the detected type alongside `status = UPLOADED`, and - rejects a file whose bytes don't match its declared extension (the record stays `PENDING`, so it can never be served or attached, and is reaped by the pending-file cleanup cron). Serving already overrides `Content-Type` from the DB record, so storing the object as octet-stream is fine. **3. A database constraint as backstop.** `CHK_FILE_PENDING_MIME_OCTET_STREAM` — `"status" != 'PENDING' OR "mimeType" = 'application/octet-stream'` — added to `FileEntity` and applied by a fast instance command (`2-19`). It is added `NOT VALID` on purpose: an instance freshly upgraded past #22449 may still hold `PENDING` rows whose mime came from the old extension-guess path, and `NOT VALID` enforces the invariant on every new/updated row without failing on that legacy backlog (those rows get overwritten to octet-stream when completed — `status` flips to `UPLOADED`, so the check passes — or are reaped while pending). ## Tests - `read-readable-prefix.spec.ts` — prefix reader: short source, early stop on a large source (asserts it tears the stream down without draining it), error propagation, empty stream. - `file-upload.service.spec.ts` — create records octet-stream; complete sniffs and sets the detected type, overrides a spoofed extension with the real content type, and rejects content that can't be matched to the declared extension. - `direct-file-upload.integration-spec.ts` — end-to-end case rejecting a `.png` upload whose bytes are plain text. ## Verification `typecheck` green, `lint:diff-with-main` clean, unit suites pass (17 tests). No GraphQL schema change, so no codegen drift. ## Scope Server-only, part of the incremental direct-upload rollout being split into small PRs. Independent of the reaper-cron PR (#22531). https://claude.ai/code/session_015UH8KWmsB9zdYaog8MFG1d --- _Generated by [Claude Code](https://claude.ai/code/session_015UH8KWmsB9zdYaog8MFG1d)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22533?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-07-06 08:12:30 +00:00
neo773	f14e62ec0c	Run integration tests against the real BullMQ driver (#22551) ... Migrate whole suite to real BullMQ Shard times unchanged, still 5-6 min.	2026-07-05 00:30:21 +02:00
martmull	1a85b88d38	feat(files): direct-to-storage upload endpoints with pending file lifecycle (#22449) ... <img width="1484" height="404" alt="image" src="https://github.com/user-attachments/assets/b2d363bf-d9e1-49fb-9811-8cc98041aa79" /> ## Context Uploading large files currently OOMs the server: every upload resolver buffers the whole file in memory (`streamToBuffer`) before writing it to storage. This PR is the first of a series introducing direct client-to-storage uploads. It adds the server-side endpoints and driver support only — it is non-breaking and nothing consumes the new flow yet. Follow-up PRs will migrate the frontend upload paths, add a stale-pending-file cleanup cron, and cap the legacy buffered resolvers. ## What it does **New upload flow (initiate → PUT → confirm):** - `createFileUpload(filename, size, fileFolder, fieldMetadataId?)` validates the request (folder allowlist: `FilesField`/`Workflow`, max size, extension-derived mime type), creates the file record in a new `PENDING` status, and returns an upload target: - **S3 with presign enabled** → a presigned PUT URL with `Content-Type`/`Content-Length` pinned in the signature, so the client uploads straight to the bucket; - **local storage, or S3 without presign** → a token-authenticated streaming endpoint on the server (`PUT /file-upload/:id?token=…`, new `FILE_UPLOAD` JWT type) that pipes the request body to the storage driver with constant memory usage and a declared-size cap. - `completeFileUpload(fileId)` verifies the bytes actually landed in storage (HEAD + size match against the declared size) and flips the record to `UPLOADED`. Idempotent. **Pending lifecycle safety:** - New `status` column on `core.file` (`PENDING`/`UPLOADED`, default `UPLOADED` so all existing rows and the legacy upload path are unaffected) + fast instance command. - Files are refused by the serving endpoints and by FILES-field sync while `PENDING`. **Driver support (both drivers):** - `getPresignedUploadUrl` (S3: presigned PUT; local: `null` → server-endpoint fallback) - `writeFileStream` (local: `fs` pipeline with the existing symlink/containment hardening, partial-file cleanup on error; S3: `@aws-sdk/lib-storage` `Upload` for bounded-memory streaming) - `getFileMetadata` (HEAD/stat for confirm-time verification) ## Tests - `file-upload.service.spec.ts`: initiate validation (folder allowlist, size), presigned vs fallback target, confirm verification (missing object, size mismatch, happy path, idempotency) - `local.driver.spec.ts`: `writeFileStream` (content, symlink rejection, partial-file cleanup on stream error), `getFileMetadata` - `s3.driver.spec.ts`: `getPresignedUploadUrl` (disabled → null, PUT command with signed content-type/content-length) - `direct-file-upload.integration-spec.ts`: full end-to-end flow against the local driver (initiate → PUT → complete → download), plus error paths (complete without upload, oversized PUT → 413, invalid token → 403, unsupported folder, size above max) ## Notes for reviewers - The upload-size ceiling for direct uploads is `settings.storage.maxDirectUploadFileSize` (1GB), separate from the 10MB `maxFileSize` used for pictures. - Since content can't be sniffed before it reaches storage, the mime type is derived from the file extension (with the existing `TWENTY_MIME_POLICY` override) and unknown extensions fall back to `application/octet-stream`; the serving path already forces `Content-Disposition: attachment` for anything not on the inline-safe allowlist. - Self-hosters using S3 presign will need a bucket CORS policy allowing `PUT` from the frontend origin (config variable description updated). https://claude.ai/code/session_015UH8KWmsB9zdYaog8MFG1d --- _Generated by [Claude Code](https://claude.ai/code/session_015UH8KWmsB9zdYaog8MFG1d)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22449?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-07-03 15:11:53 +02:00
martmull	27dea0ed0b	Add installed workspaces view to application registration (#22359) ... ## After <img width="895" height="344" alt="image" src="https://github.com/user-attachments/assets/33591753-f248-45ce-b32d-cc1112f50579" /> <img width="889" height="425" alt="image" src="https://github.com/user-attachments/assets/469ee228-9abb-486f-b2ec-9efb490bb2c8" /> <img width="766" height="343" alt="image" src="https://github.com/user-attachments/assets/2d88444a-6d98-4f97-8e5d-109197cfad27" /> ## Summary Add a new "Installed workspaces" section to the application registration settings page that displays all workspaces that have installed a given application, with pagination support. ## Key Changes - **Backend Service**: Added `getInstalledWorkspaces()` method to `ApplicationRegistrationService` that queries installed applications across workspaces with pagination support - **Backend DTO**: Created `ApplicationRegistrationInstalledWorkspacesDTO` and `InstalledWorkspaceDTO` to structure the response with workspace details (id, displayName, logo, version), total count, and hasMore flag - **GraphQL Resolver**: Added `findApplicationRegistrationInstalledWorkspaces` query resolver with pagination (page parameter, default page size of 10) and proper authorization guards - **Frontend Component**: Created `SettingsApplicationRegistrationInstalledWorkspaces` component that: - Displays installed workspaces in a table with workspace logo, name, and version - Shows initial 3 workspaces with "Show all" button to expand - Implements pagination with "Show more" button to load additional pages - Handles empty state (returns null if no workspaces installed) - **GraphQL Query**: Added `FindApplicationRegistrationInstalledWorkspaces` query document for frontend data fetching - **Integration**: Integrated the new component into `SettingsApplicationRegistrationGeneralTab` ## Implementation Details - Pagination uses offset-based approach with configurable page size (10 workspaces per page) - Query results are ordered by workspace displayName and id for consistent ordering - Soft-deleted applications and workspaces are excluded from the list and counts - Apollo Client's `fetchMore` with `updateQuery` merges paginated results into the cache - Component respects existing authorization (API_KEYS_AND_WEBHOOKS permission required) - Uses existing UI components (Table, Card, Avatar, Button) from twenty-ui library - Supports internationalization with Lingui ## Screenshots The new "Installed workspaces" section on the app registration General tab (admin app detail page), captured against a local instance with a demo app installed in 14 workspaces. The three PNGs are committed under `.github/assets/screenshots/installed-workspaces/` and render inline in the **Files changed** tab of this PR: - `1-first-3-show-all.png` — Collapsed: the first 3 installed workspaces (avatar + name + installed version) with a "Show all" button. - `2-expanded-show-more.png` — "Show all": the first page of 10 workspaces, with a "Show more" button (more remain). - `3-all-paginated.png` — "Show more": all 14 workspaces loaded, button gone. Review in cubic: https://cubic.dev/pr/twentyhq/twenty/pull/22359?utm_source=github https://claude.ai/code/session_012nWtviSBdfFeHEASTtwvJ7	2026-07-01 14:38:51 +00:00
Raphaël Bosi	2e6077383b	Add install your first apps onboarding V2 step (#22347) ... https://github.com/user-attachments/assets/5326d48f-1842-4db1-bc7c-94852145c035 <img width="838" height="754" alt="CleanShot 2026-06-30 at 16 25 05@2x" src="https://github.com/user-attachments/assets/5c7d53d7-4d65-4e35-aed1-edf0c104e140" /> Adds an "Install your first apps" step to the V2 onboarding, shown right after import-contacts. It lets users opt into installing marketplace apps (Call recorder and People Data Labs for now) during onboarding. - New backend `OnboardingStatus.APPS_INSTALLATION` (between SYNC_EMAIL and PROFILE_CREATION); V1 auto-skips it. - The primary button sends the selected app ids to the server via `triggerInstallAppsOnboardingStep`, which enqueues a dedicated job that installs them asynchronously so onboarding isn't blocked. Skip continues without installing. - The workspace is credited per app on successful installation. Credits are env-driven via `ONBOARDING_INSTALL_APPS_CREDITS_REWARD_PER_APP`, shown as "Earn +N free credits (1 per tool)". <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22347?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-07-01 12:25:16 +00:00
Félix Malfait	1df00698cf	feat(server): make workspace Custom application carry an applicationRegistration so custom labels are translatable (#22378) ... ## Why Custom objects/fields belong to a per-workspace **Custom** application (`workspace.workspaceCustomApplicationId`). That application was created with `applicationRegistrationId = null`. Because the metadata label resolver loads a translation catalog from `core.applicationTranslation` **keyed by `applicationRegistrationId`** (`ApplicationTranslationCacheService.getCatalog` → `applicationTranslationCatalogLoader` → `resolveObjectMetadataStandardOverride` / `resolveFieldMetadataStandardOverride`), the Custom app had no catalog and custom labels always resolved to the raw source string. This is the foundational slice: it wires up the missing key so custom labels can be translated **exactly like any installed third-party app**. The read/resolve path already works once a catalog exists — confirmed end-to-end. `flatApplicationMaps` carries `applicationRegistrationId` straight from the entity column, so setting it + recomputing that cache is all that's needed. ## What changed - **`ApplicationService.createWorkspaceCustomApplication`** now creates a workspace-scoped `applicationRegistration` and links it to the Custom application. This covers both production creation sites (sign-in-up and the dev-seeder), which are the only callers. - **New idempotent workspace upgrade command** `upgrade:2-18:backfill-workspace-custom-application-registration` creates a registration for each existing workspace's Custom application that lacks one and links it. It delegates the registration lifecycle (create + link + `flatApplicationMaps` recompute) to `ApplicationService`, so the command only decides *which* workspaces need it. - New `WORKSPACE_CUSTOM_APPLICATION_NAME` constant; the registration creation lives in `ApplicationService.createWorkspaceCustomApplicationRegistration`. ## Design decisions - **Per-workspace registration (not a shared "custom" registration).** `applicationTranslation` is keyed *only* by `applicationRegistrationId` (cross-workspace). A shared registration would force every workspace's custom translations into one catalog keyed by `generateMessageId(sourceText)`, guaranteeing cross-workspace collisions and leakage (two workspaces both naming an object "Project" would clash). Each workspace's Custom app gets its own registration (`ownerWorkspaceId = workspaceId`, `universalIdentifier = the Custom app's per-workspace uuid`) and thus an isolated catalog — matching installed-app behaviour, where `application.universalIdentifier === registration.universalIdentifier`. - **Source-label keying kept** (`generateMessageId(sourceLabel)`). The resolve path and the third-party manifest pipeline both key catalogs this way. Re-keying by a stable `universalIdentifier` would require changing the shared resolver/dataloader for *all* apps and would break marketplace manifest translations — out of scope for this slice. Consequence: renaming a label orphans its catalog entry (it falls back to the source label until re-translated) — the same behaviour an installed app has when it changes a source string. Re-keying on rename can be handled later by the interactive write path. - **Workspace command (not instance command)** for the backfill: it is per-workspace data logic that must recompute the per-workspace `flatApplicationMaps` cache the resolver reads from. It is idempotent (skips Custom apps that already have a registration), supports `--dry-run`, and is forward-only by design. - **Interactive write path deferred** as an explicit follow-up. This slice proves the read/resolve path; an editor that writes custom translations into `applicationTranslation` (+ cache invalidation) is the natural next step. ## Tests - **Unit test** for the backfill command: creation + linking, idempotency, dry-run, and the skip paths. - **Integration test** (`custom-application-translation.integration-spec.ts`): on a freshly created workspace (so the registration's translation cache is guaranteed cold), it asserts the Custom application is created with a registration, seeds an `applicationTranslation` row, and verifies a custom object's label resolves from that catalog while a label with no catalog entry falls back to its source label. ## Notes for reviewers - No new entity columns or migrations beyond the workspace command — `ApplicationRegistrationEntity` already supports a workspace-scoped `workspaceId`. - The backfill follows the established upgrade-command pattern: it imports `ApplicationModule` and delegates to `ApplicationService` (consistent with the other version-command modules). https://claude.ai/code/session_018heTgu4ew4AJ99VVz4bjqd --- _Generated by [Claude Code](https://claude.ai/code/session_018heTgu4ew4AJ99VVz4bjqd)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22378?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-30 23:08:38 +02:00
Etienne	56deba351b	feat(ai): reliable bulk data import via code-interpreter (#22209) ... ## Summary Makes AI-assisted bulk data import (CSV/Excel/spreadsheets) reliable and token-efficient by letting an entire import run inside a single code-interpreter call, with a persistent sandbox session and server-side bulk helpers. Also includes supporting improvements to attachment handling, upsert reporting, and field-permission error messages. ## Changes ### Code interpreter - **Persistent per-session kernel** in `LocalDriver`: a long-lived Python process per `sessionId` keeps variables, imports, and files alive across calls (matching E2B behavior). Falls back to the existing ephemeral per-call path when no session is provided. CAN BE REMOVED, INTERESTING FOR DEV X - Idle watchdog that self-terminates the kernel, configurable via the new `CODE_INTERPRETER_IDLE_TIMEOUT_MS` config variable; the process also exits on parent shutdown (EOF on control fd). CAN BE REMOVED, INTERESTING FOR DEV X - New `bulk_upsert` and `lookup_by` helpers on the sandbox `twenty` object for idempotent batched writes (≤200/batch) and bounded relation-ID resolution. ### Records - `upsert_many_*` now reports a `created` / `updated` / `total` split in its result and log line (new `isFreshlyCreatedRecord` util). ### AI chat - `replaceUnsupportedFileParts`: user-attached files whose MIME type the model can't handle natively (and that aren't code-interpreter-supported) are downgraded to a descriptive text note instead of being sent as unsupported file parts. Modality→MIME mapping drives native support detection. - Finalize dangling tool parts before `convertToModelMessages` to avoid malformed model messages. - Extracted shared types/constants for code-interpreter file extraction. ### Permissions - Field permission-denied exceptions now include the field name and entity name for easier debugging. ### Skill docs - Added the bulk-import recipe ## To do in following PR - [ ] Skill command migration ## Test plan - [x] Unit tests for `getNativeMimeTypesForModalities` and `replaceUnsupportedFileParts` pass - [x] Run a bulk import (>50 rows) end-to-end through the code interpreter and verify a single sandbox call handles read → resolve relations → upsert → summary - [x] Verify session persistence: define a variable in one call, use it in the next within the same session - [x] Verify the kernel self-terminates after `CODE_INTERPRETER_IDLE_TIMEOUT_MS` - [x] Verify unsupported attachments are replaced with a text note for models lacking the modality - [x] Verify `upsert_many_*` returns correct created/updated counts - [x] Verify field-restricted role triggers a permission error naming the field and entity - [ ] Test with [hotel_business.xlsx](https://github.com/user-attachments/files/29376307/hotel_business.xlsx) and simple "import record" prompt <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22209?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-29 09:54:27 +00:00
Félix Malfait	538b180824	feat(dpa): self-serve Data Processing Agreement generator (#22243) ... ## What A single, region-aware DPA that serves all customers, generated automatically from the customer's deployment. Two layers: 1. **Click-through DPA** — recorded at signup (acceptance = execution), resolving merge fields from the deployment region. Cloud only. 2. **In-app signed-PDF generator** — Settings → Legal → Generate DPA: preview the agreement, enter legal entity + authorized signatory, download a PDF pre-signed by Twenty, and store the executed copy against the workspace with its template version + timestamp. Deep-linkable at `/dpa` (login-gated) for `twenty.com/dpa`. ## How it resolves A typed variable matrix (`dpa-region-config.constant.ts`) maps the deployment region to the contracting Processor entity and terms: - **EU (default)** → Twenty.com SAS, hosting EU/Frankfurt, governing law France, SCC section dormant. - **US (custom)** → Twenty, Inc., hosting US, SCC section active. Region is a deployment-wide setting (`DPA_DEPLOYMENT_REGION`, default EU) behind a `DpaRegionService` seam so it can later become per-workspace without touching callers. The legal text is verbatim from the template (generated into `dpa-template.constant.ts` directly from the source `.docx`); only the 6 merge fields are filled and the SCC sections (7.2–7.5) stay in the document for every region per the spec — only field values branch. Sub-processors are deferred to trust.twenty.com (not enumerated). Billing stays decoupled (Twenty, Inc. remains merchant of record regardless of Processor). ## UI Standard list + create-page pattern (mirrors API keys / webhooks): a list of executed copies (with re-download) — or the agreement preview when none exists — and a top-right blue **Generate DPA** CTA opening a standard create page. The "Legal" item is intentionally **not** in the settings menu; the page is reached via the `/dpa` deep link. ## Notable implementation details - **PDF** is rendered server-side with `@react-pdf/renderer`. The built-in standard-14 fonts only encode ASCII and crash on the template's curly quotes / em–en dashes / accented Latin, so Liberation Sans (OFL) is **subset to a Latin glyph set and embedded as base64 data: URLs** — no font files to ship or resolve at runtime (works in dev, prod-Docker and CI). - New `core.dpaAgreement` table via a fast instance command (FK hash reproduced to match TypeORM). - Self-hosted deployments (billing disabled) skip click-through recording and stamp a prominent "not a valid agreement" banner on the preview and PDF. ## Tests - Unit: resolver (per-region entity/law/SCC state, EU default, no unresolved `{{ }}`, SCC sections present in both regions, self-hosted notice) and HTML renderer. - Integration (`test/integration/graphql/suites/dpa`): preview has no unresolved fields; `generateSignedDpa` renders + persists + returns a downloadable PDF (asserted with accented input to guard the font regression); list re-download. ## ⚠ Needs legal input before go-live (marked `TODO_CONFIRM` in `dpa-region-config.constant.ts`) - Registered-office addresses for Twenty.com SAS and Twenty, Inc. - US deployment governing law (the template only specifies France). - DPO name and the Twenty pre-signed authorized signatory name/title. ## Out of scope (flagged per spec) Intra-group legal agreement and any Stripe/billing-entity changes. A future e-sign provider would plug in at `DpaService.generateSignedDpa` + the signatory input. > Draft until the integration test passes in CI and the legal `TODO_CONFIRM` values are supplied. https://claude.ai/code/session_01Ahjydxx6J1souz1s1NeA9a --- _Generated by [Claude Code](https://claude.ai/code/session_01Ahjydxx6J1souz1s1NeA9a)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22243?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-27 17:46:38 +02:00
Félix Malfait	2a21eb46c0	perf: cap to-many relation records per parent and inline chips in table (#22206) ... ## Problem Record table views that show a to-many relation column (e.g. Workflows with a "Runs" column) get slow and janky to scroll when some records have many related records. Two root causes, found by profiling the page live: 1. **Backend over-fetch + unfairness.** Nested one-to-many relations were loaded with a single flat limit of `QUERY_MAX_RECORDS_FROM_RELATION * parentCount` shared across *all* parents in the page (`WHERE parentColumn IN (ids) LIMIT 60*N`, no per-parent cap). A single hot parent can consume the entire budget — returning thousands of rows for one cell, and potentially starving sibling parents of records they actually have. The `limit * parentCount` shape shows the original intent *was* a per-parent budget; it was just implemented as a global limit. 2. **Frontend DOM explosion.** `ExpandableList` mounts the *entire* child array inline (clipped with `overflow: hidden`) when unfocused, and mounts all children for measurement when focused. A cell with 2,000+ relation chips mounts ~14k DOM nodes — one observed page reached ~55k nodes for 43 rows, producing 100–300 ms main-thread long tasks on every scroll. ## Fix - **Backend:** load one-to-many relations with a true **per-parent** cap via a `LATERAL` join — each parent runs its own indexed, `LIMIT`-ed scan that stops after the per-parent budget. This is `O(perParentLimit × parentCount)` and never reads or sorts a parent's full relation set. The per-parent query is built through the workspace query builder (so it stays schema-qualified and keeps the soft-delete predicate) and wrapped as a `FROM` subquery; read/row-level permissions are enforced when records are hydrated by id, as elsewhere in the relation loader. Many-to-one is unchanged. - **Frontend:** add an opt-in `maxInlineCount` to `ExpandableList` so to-many relation cells mount only a small inline preview; the expand dropdown still renders the full fetched set. Fully backward compatible (no cap → identical behavior). ## Why LATERAL over a window function A windowed `ROW_NUMBER() OVER (PARTITION BY parent) <= limit` is correct and fair too, but a window function **cannot stop early within a partition** — it must read every matching row (and sort it). Measured on skewed data (one parent with ~4k children, on the existing single-column join index, PG16): | Approach | Time | Buffers | Rows read from the hot partition | |---|---|---|---| | Pre-PR (`LIMIT 60×N`) | 1.6 ms | 91 | ~180 total, early-stops, but **unfair** (starves siblings) | | Window (`ROW_NUMBER`) | 3.7 ms | 128 | **all ~4k + sort** | | **LATERAL (`per-parent LIMIT`)** | **0.5 ms** | **57** | **~60, index early-stop** | LATERAL matches the pre-PR read cost while being fair, needs no new index, and scales independently of how large any single relation is. ## Verification - Backend integration test (`nested-relation-per-parent-limit`): a parent with 65 children is capped at 60 while a sibling with 3 keeps all 3 — passes. - `EXPLAIN ANALYZE` on the generated SQL: Index Scan with the `LIMIT` pushed into the per-parent lateral (early-stop). - Frontend unit test for the `ExpandableList` cap. - Manual check on a table cell with 40 related records: exactly 10 chips mount inline (down from 40), no console errors, chips still clickable and the overflow count reflects the true total.	2026-06-27 15:12:43 +02:00
Félix Malfait	0e22ae0521	feat: create calendar events on Google and Microsoft accounts (#22231) ... ## Context Twenty can import calendar events and send emails, but cannot create calendar events. This adds calendar event creation on connected **Google** and **Microsoft** accounts, mirroring the existing email-send architecture (`message-outbound-manager`). ## What it adds The capability is exposed three ways, all backed by the same composer → driver → persist pipeline: - **GraphQL mutation** `createCalendarEvent` (metadata API) - **AI agent tool** `create_calendar_event` (flows to MCP automatically), gated by a new `CREATE_CALENDAR_EVENT_TOOL` permission flag - **Workflow builder node** "Create Calendar Event" in the **Core** section, with a full settings form (variable interpolation supported) CalDAV/IMAP is intentionally out of scope for now (different long pole). ## Design notes - **Reuse over reinvention** — the created event is run through the existing inbound formatters (`formatGoogleCalendarEvents` / `formatMicrosoftCalendarEvents`) and persisted immediately via the existing `CalendarSaveEventsService`, so it appears in Twenty right away and is reconciled by the next provider sync (dedup on external id). Persistence is best-effort. - **OAuth scopes** — Google already requests `calendar.events` (read+write), so no change there. Microsoft moves `Calendars.Read` → `Calendars.ReadWrite`; existing Microsoft accounts must re-consent (surfaced as a clear "reconnect" error via a missing-scope check). - **Deliberate invitation semantics** — `sendInvitations` is off by default. When off, the event is created with **no attendees** on either provider, so creating an event never silently emails external people. When on, attendees are attached and notified (Google `sendUpdates: all`, Microsoft's default). This sidesteps Microsoft Graph having no per-request suppression. - **Timezone correctness** — Microsoft Graph interprets `dateTime` as wall-clock in the supplied `timeZone` and ignores the offset, so the absolute instant is converted to its wall-clock form before sending (Google honors the offset directly). Both providers end up scheduling the same instant. - **Conferencing** — optional Google Meet (`conferenceData.createRequest`, with a follow-up `events.get` to resolve the async link) / Microsoft Teams (`isOnlineMeeting`). - Attendees are a comma-separated string everywhere (tool input, GraphQL DTO, workflow input), consistent with `send_email` recipients; the composer parses to its internal list. ## Test plan - **Unit**: 45 tests covering the composer (validation, all-day boundaries, offset enforcement, timezone, scope checks, default-account resolution), both provider drivers, the dispatcher, and the workflow step-log builder. - **Integration**: `createCalendarEvent` on the `/metadata` API fails closed with a structured error for a non-existent account (the auth/ownership/validation path that doesn't require provider mocking). - **Manual**: verified the workflow node appears in the Core section, the settings form renders and round-trips (edit → autosave → reload), and the live mutation returns a structured failure for a bogus account. ## Open question for reviewers The metadata mutation `createCalendarEvent` shares a name with the core schema's auto-generated `createCalendarEvent(data:)` CRUD mutation for the CalendarEvent object — they live on different endpoints (`/metadata` vs `/graphql`) so there's no runtime conflict, but it's a potential point of confusion for API consumers. Happy to rename (e.g. `createCalendarEventOnConnectedAccount`) if preferred. ## Out of scope / follow-ups - CalDAV/IMAP support - Event update/delete and recurrence - Existing Microsoft accounts need re-consent for the widened scope <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22231?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: neo773 <neo773@protonmail.com>	2026-06-27 14:05:58 +02: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
Abdul Rahman	02a966bb7f	make mergeMany atomic and optimize relation/field-map handling (#21885) ... Closes [core-team-issue#2333](https://github.com/twentyhq/core-team-issues/issues/2333) ## Summary Hardens and optimizes `CommonMergeManyQueryRunnerService`: - **Atomicity**: wrap relation migration + duplicate deletion + survivor update in a single transaction so a mid-merge failure rolls back fully (previously failures were swallowed and could leave orphaned/half-merged data). - **Perf**: drop the redundant `find`-before-`update` in relation migration (2N → N queries, no row hydration) and hoist `buildFieldMapsFromFlatObjectMetadata` out of the per-field loops. ### Why a transaction (not parallelization) The relation migrations could be parallelized with `Promise.all`, but merge is a destructive operation: a partial failure leaves orphaned or half-merged records. We prioritize correctness, so the steps run inside one transaction. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21885?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Félix Malfait <felix@twenty.com> Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-22 13:05:06 +02: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	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
Félix Malfait	7eafbd91c6	test(server): make timeline integration test self-seed its data (#21896) ... ## Problem `timeline-from-object-record.integration-spec.ts` is flaky depending on Jest shard composition. Its `beforeAll` scans the dev-seeded people for one with message threads and one with calendar events, and throws when none is found: ``` Expected the seeded workspace to contain a person with message threads and calendar events ``` This was observed as a deterministic failure of `server-integration-test (2)` (failed on re-run too), while the other 15 shards were green. ## Root cause The suite depends on **mutable shared fixture state** under two fragile assumptions: 1. **That no sibling suite wiped the seeded people.** `deleteAllRecords('person')` is a common pattern across the REST/GraphQL suites — `rest-api-core-find-many`, `rest-api-core-find-one`, `all-people-resolvers`, `search-resolver`, etc. — each hard-deletes every person (`DELETE FROM "...".person`) and leaves only its own handful behind, without restoring the seed. Within a shard, Jest runs files serially (`maxWorkers: 1`) ordered by file size descending (no timing cache in CI). `rest-api-core-find-many` (~16 KB, runs 2nd) executes **before** `timeline-from-object-record` (~12 KB, runs 5th), so by the time the timeline `beforeAll` runs, only 4 company-linked test people remain — none with threads or events. 2. **That the seeder's `Math.random` participant assignment** happened to land a thread and an event on a company-linked person within the first 100 results — itself non-deterministic across DB resets. It surfaced now because an unrelated PR added a new integration test file, which changed the total file set and therefore Jest's shard distribution, moving `timeline-from-object-record` and `rest-api-core-find-many` into the **same shard** for the first time. It is a latent test-isolation issue, not a product regression. ### Reproduced locally Against a DB where `rest-api-core-find-many` had already run (person count = 4), the timeline suite fails with the exact CI error; on a freshly seeded DB it passes. So the failure is purely order/seed dependent. ## Fix Make the suite self-contained: in `beforeAll` it now provisions its own graph via the GraphQL API and tears it down in `afterAll`: ``` company → person → messageThread → message → messageParticipant(personId) ↘ calendarEvent → calendarEventParticipant(personId) ``` The timeline resolvers count threads via `messageThread → messages → messageParticipants.personId` and events via `calendarEvent → calendarEventParticipants.personId`, so this graph is sufficient and minimal. The suite no longer reads any ambient seeded data, making it independent of execution order and seeding randomness. ## Validation - Self-seeding suite passes against the **polluted** DB (4 people, no seeded threads/events) — the exact CI failure condition. - Idempotent across repeated runs and leaves **no residue** (all fixtures destroyed in `afterAll`). - Full `--shard=2/16` run green except a pre-existing environmental failure (`successful-save-imap-smtp-caldav-account`, fails locally with no mail server, identical before/after this change). 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/21896?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-20 14:29:28 +02:00
Félix Malfait	23f5ba9ebf	feat: add resizable kanban column width (#21828) ... ## What & why Lets users resize the columns of a Kanban (record board) view. Requested by a user; the design avoids the "ragged board" problem by making the width a **single shared value**. ## Behaviour - A drag handle appears on the right edge of every column header. - Because all columns read **one** width value, dragging any handle resizes **every** column together — they can never end up mismatched. - Width is clamped between **150px** and **400px** (default **200px**). - The width is **persisted per view** and restored on reload. ## Approach **Backend** — a new nullable `View.kanbanColumnWidth` field, threaded through the existing view-level setting pattern (the same one `kanbanAggregateOperation` / `shouldHideEmptyGroups` use), so it gets create/update/manifest/override support for free: - entity column + `ViewOverrides` + `@WasIntroducedInUpgrade` - `CreateViewInput` / `UpdateViewInput` (`Int`, `@Min(150)`/`@Max(400)`) + `ViewDTO` - flat-view editable properties, entity-properties config, compare-type, standard-view + manifest converters - a fast instance command adding the `core.view` column **Frontend** — the value hydrates into a view-scoped atom and drives a single CSS variable set on the board container, which both column headers and bodies read. Live dragging only writes that CSS variable (no per-move React re-render); the final width is committed to the atom and persisted via `updateView` on pointer-up. ## Nullability / defaults `kanbanColumnWidth` is nullable — `null` means "never resized" and the UI falls back to the 200px default, so existing rows need no backfill. ## Validation - `nx typecheck twenty-server` ✅ and `nx typecheck twenty-front` ✅ - `nx lint:diff-with-main twenty-server` ✅; frontend lint fixes applied (split constants to one-per-file, removed `useRef`-for-state in favour of `useState`). - Draft pending a final green CI run (the dev container reclaimed `node_modules` mid-session; re-running locally). ## Test plan - [ ] Drag a kanban column edge → all columns resize together, clamped 150–400px - [ ] Reload → width persists for that view; other views unaffected - [ ] A view that was never resized still renders at 200px https://claude.ai/code/session_016Qe6oDBkhVbrq2QkXBJ5nE --- _Generated by [Claude Code](https://claude.ai/code/session_016Qe6oDBkhVbrq2QkXBJ5nE)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21828?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Claude <noreply@anthropic.com>	2026-06-19 15:58:13 +02:00
neo773	814b43ca41	feat(server): derive email/calendar timelines from object relations (#21684) ... Simplifies our existing implementation that uses three different GraphQL endpoints to just one `getTimelineEventsFrom{Person, Company, Opportunity}Id` to `getTimelineCalendarEventsFromObjectRecord` /closes https://github.com/twentyhq/twenty/issues/19676 <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21684?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-19 02:22:27 +02:00
Weiko	9f30915f6f	fix(metadata): remove deprecated isCustom from Objects and Fields (#21799) ... ## Context Follow-up to #21228, which deprecated `isCustom` on object/field metadata but kept it exposed because the frontend still relied on it. This removes it from the GraphQL API and the frontend entirely. ## Implementation ### Server - Remove `isCustom` `@Field` from the `Object`, `Field`, and `MinimalObjectMetadata` GraphQL types - Remove the `isCustom` `@ResolveField` resolvers and the `isCustomLoader` dataloader (+ payload/interface) - Remove `isCustom` as an internal `@HideField()` on the Object/Field DTOs used by the i18n standard-override gate > Use an explicit isStandard instead (which is the correct gating) ### Frontend - Add `getIsMetadataItemCustom` helper + `useGetIsMetadataItemCustom` hook: an item is custom when `applicationId === currentWorkspace.workspaceCustomApplication.id` - Migrate all consumers off `objectMetadataItem.isCustom` / `fieldMetadataItem.isCustom`; `isRecordFieldReadOnly` now takes a precomputed `isFieldCustom` - Drop `isCustom` from the metadata fragment/mutations/minimal query, FE types, zod schemas, and mock generators; regenerate GraphQL types ## Notes - Breaking change on the (already-deprecated) `Object.isCustom` / `Field.isCustom` GraphQL fields and the `isCustom` filter - FE semantic is "belongs to the workspace custom app" (third-party-app objects/fields are treated as non-custom) - `isCustom` on IndexMetadata / View / Skill / Agent is a separate column and is untouched - Breaking changes on REST metadata API	2026-06-19 01:19:49 +02:00
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
Paul Rastoin	e7e99247e8	Centralize and standardize impersonation validation rules (#21717) ... # Introduction Followup https://github.com/twentyhq/twenty/pull/21707 ## Behavioral change worth calling out Server-level impersonation now requires verified 2FA outside development at every checkpoint (generation, exchange, and per-request). In main the 2FA gate only existed in ImpersonationService. This is the right tightening, but it means existing server-admin impersonation sessions in production for admins without verified 2FA will now be rejected on the next request, not just at token creation. cc @s0yd4RK <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21717?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: s0yd4RK <285671363+s0yd4RK@users.noreply.github.com> Co-authored-by: Cursor <cursoragent@cursor.com>	2026-06-18 13:13:50 +02:00
Paul Rastoin	60b559a659	Provide custom workspace id while seeding (#21721) ... # Introduction Currently working on e2e test ci that will iterate over dedicated twenty instance. In order to allow multi concurrent tests to be performed we need to isolate testing context Allowing to provide custom workspaceId allow easy isolation and post test cleanup on aws related account close https://github.com/twentyhq/core-team-issues/issues/2556 <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21721?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 14:29:27 +00:00
Weiko	3ee93b5ec9	feat(server): add isSystemSideEffect & merge createOneObject/createOneField side-effect migrations (#21673) ... ## Context When an object is created via the metadata API, `createOneObject` creates its side-effect entities (INDEX view + viewFields, indexes, navigation menu item, "go to" command menu item, record-page fields view, page layout/tabs/widgets) across **three separate `validateBuildAndRunWorkspaceMigration` calls**, purely because the protection behavior (mutations → overrides, delete → deactivate, reset → reactivate) was keyed on *"owned by the standard app"*, forcing the side effects into batches with different application owners. This misrepresents ownership and breaks atomicity. This PR separates two orthogonal concepts: - **Ownership** (`applicationId`), the true owner: the caller's application (the workspace custom app today, 3rd-party apps later). - **Protection** (`isSystemSideEffect`), the row was generated by the system, so user mutations route to overrides, deletion becomes deactivation, and reset restores defaults. Once side effects are re-owned to the caller, the old `applicationId === standardApp` check can no longer tell an original side-effect row from a user-added one so a dedicated `isSystemSideEffect` flag carries the protection instead. This is **PR 1 of 2** (forward-only). It makes newly created objects and fields correct; existing workspaces are handled by a follow-up backfill (see *Out of scope*). ## What this PR does - **`isSystemSideEffect` column** on the 8 affected entities (`view`, `viewField`, `indexMetadata`, `commandMenuItem`, `pageLayout`, `pageLayoutTab`, `pageLayoutWidget`, `fieldMetadata`), with `@WasIntroducedInUpgrade` + an entry in the flat-entity property configuration (`toCompare: true`, read-only). - **Single atomic migration in `createOneObject`**: the three `validateBuildAndRunWorkspaceMigration` calls are merged into one, owned by the caller (`resolvedOwnerFlatApplication`) and the record-page view/fields, page layout, and navigation command item are re-owned to the caller and flagged `isSystemSideEffect: true`. `buildNavigationFlatCommandMenuItem` is parameterized with `applicationUniversalIdentifier` (no longer hardcoded to the standard app). - **Field-creation side effects** (`createManyFields`/`createOneField` already run as a single caller-owned migration, so no re-ownership/merge was needed): the auto-created viewField is flagged `isSystemSideEffect: true`, and a new field now also propagates to the object's **INDEX/table view** (added there as a **hidden** column, `isVisible: false`) in addition to the record-page FIELDS widget. The INDEX view is targeted directly by `key = INDEX` (it is not a page-layout widget), de-duplicated per `(viewId, fieldMetadataUniversalIdentifier)` to respect the per-view unique index. The unique-field index is likewise flagged the inverse relation field stays unflagged (`isSystem: false`). - **Protection predicate** extended: `isCallerOverridingEntity` and the removal/reset split strategies now treat `isSystemSideEffect` rows as protected even when caller-owned (route to overrides / deactivate / reset) and the page-layout-reset guards allow resetting flagged entities. - **Standard compute maps** set the flag consistently so a re-sync produces no diff (standard-object side effects stay `false`; per-object nav command items and custom-object base fields are `true`). - **Read-only GraphQL exposure** of `isSystemSideEffect` on the view / view-field / page-layout / tab / widget / command-menu-item DTOs (not exposed on create/update inputs). => Todo: needs to take this new flag into account. This is fine for now because isSystem remains on object/field. - **Fast instance command** (`2-14`) adding the 8 columns (`NOT NULL DEFAULT false`). ## Scope decisions - **`pageLayout` is not an `OverridableEntity`**, its own row has nothing user-overridable (all customization lives on tabs/widgets). It's dual-purpose (`RECORD_PAGE` side-effect vs. user `DASHBOARD`), so it gets `isSystemSideEffect` for protection only, no `overrides` jsonb. - **`navigationMenuItem` is out of scope.**: Those are side effects only for the metadata API and not marked as "system" (they can be deleted/updated etc...) - **`viewFieldGroup` is not a side effect**, it's only created via the explicit view-field-group API, never by object/field creation, so it gets no flag. ## Out of scope (follow-ups) **PR 2** — slow per-workspace backfill (re-own + flag existing side effects, recreate missing ones) and deterministic v5 identifiers for base fields / pageLayout / tab. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21673?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-17 15:56:27 +02:00
Thomas Trompette	b36c0c51c3	fix(server): keep workflow command menu item label in sync with workflow name (#21490) ... ## Summary Fixes #20766 — manual-trigger workflows showed `Manual Trigger` in the command menu instead of the workflow's name. Root cause (confirmed against a live instance): the command menu item's `label` is written **only at activation** in `createOrUpdateCommandMenuItem`, from `workflow.name`, with a hardcoded `'Manual Trigger'` fallback. So: - a workflow activated while unnamed gets the misleading `Manual Trigger` label, and - renaming the workflow afterwards never updates the label (`workflow.updateOne` had no label-related hook). Changes: - Add `getWorkflowCommandMenuItemLabel` helper and use it in activation; the empty-name fallback is now `Untitled Workflow` (consistent with the rest of the UI) instead of `Manual Trigger`. - Add `WorkflowCommandMenuSyncWorkspaceService` that updates the active version's command menu item label/shortLabel from the workflow name (idempotent, no-op for non-manual / inactive workflows). - Add `workflow.updateOne` and `workflow.updateMany` post-query hooks that call the sync service, registered in `WorkflowQueryHookModule`. Out of scope (separate follow-up): the activation create path can produce duplicate command items for one `workflowVersionId`; recommend making it idempotent / adding a unique constraint. ## Test plan - [x] `oxlint --type-aware` + `oxfmt` clean on changed files - [x] Editor TS diagnostics clean (full `nx typecheck` was starved by local dev servers) - [ ] New integration test `workflow-command-menu-label.integration-spec.ts`: - labels the command menu item with the workflow name on activation - updates the label when the workflow is renamed - falls back to `Untitled Workflow` when the name is cleared <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21490?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:54:32 +00:00
Marie	e334551da9	(Fix) Upsert no longer rewrites position on existing records (#21375) ... ## Fix: upsert no longer rewrites `position` on existing records ### Problem `createX(..., upsert: true)` resets the `position` of records that resolve to an **update**, even when the payload doesn't include a `position`. The create-many/upsert runner backfills `position` (to `"first"`) in `computeArgs` over the **whole batch**, before records are split into insert vs update. So existing rows get a freshly recomputed `position` written on every upsert. For callers that re-upsert their full dataset on a schedule (e.g. a daily sync), this rewrites `position` for every record on each run and drifts the values steadily negative — and it floods audit/event logs with position churn. The dedicated `updateOne`/`updateMany` runners already pass `shouldBackfillPositionIfUndefined: false`; the upsert path did not. ### Fix Only backfill `position` for records that are actually inserted: - `computeArgs` now passes `shouldBackfillPositionIfUndefined: !args.upsert` in both the create-many and create-one runners, so undefined positions are left untouched on upsert. - `performUpsertOperation` backfills `"first"` positions for `recordsToInsert` only, **after** categorization, via `RecordPositionService`. Explicit `position` values (`"first"`, `"last"`, or a number) in the payload are still honored. Plain (non-upsert) create behavior is unchanged. ### Behavior | Scenario | Before | After | |---|---|---| | Upsert updates existing row, no `position` sent | `position` rewritten | `position` untouched | | Upsert inserts new row, no `position` sent | gets `"first"` | gets `"first"` (unchanged) | | Explicit `position` on upsert | applied | applied | | Plain create | unchanged | unchanged |	2026-06-12 08:50:09 +00:00
Charles Bochet	615c3d8dbe	security: drop end-of-life apollo-server-core (#735, #736) (#21418) ... Closes the `apollo-server-core` alerts (**#735**, **#736**) by **removing the dependency** — no Apollo migration, no resolution. ### Why these were flagged "no patch available" `apollo-server-core` is **Apollo Server v3, which is end-of-life** (per its npm deprecation notice). No patched release of this package will ever exist — the CVE fix lives only in the renamed `@apollo/server` v4 package. ### Why we can just drop it twenty-server **doesn't use Apollo Server** — its GraphQL runtime is **GraphQL Yoga** (`YogaDriver`). `apollo-server-core` was imported for one thing only: the `gql` template tag in **6 integration test files**. `gql` from `graphql-tag` is identical (apollo-server-core merely re-exports it), `graphql-tag` is **already a direct dependency**, and **15 other twenty-server tests already import `gql` from it**. ### Change - Swapped `import { gql } from 'apollo-server-core'` → `import { gql } from 'graphql-tag'` in the 6 test files. - Removed `apollo-server-core` from `packages/twenty-server/package.json`. - Result: `apollo-server-core` (and its transitive surface) is gone from `yarn.lock` entirely. ### Verification - `yarn install --immutable` ✓ - No `apollo-server-core` references remain in source or lockfile - Integration tests (which exercise the swapped `gql` imports) run in CI	2026-06-10 19:08:07 +02: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
Félix Malfait	91f2f08995	feat(server): unify workspace-event ingestion behind one EventSink pipeline (#21197) ... ## Why The five event-log streams (`workspaceEvent`, `pageview`, `objectEvent`, `usageEvent`, `applicationLog`) each wrote to ClickHouse through their own fire-and-forget writer (`AuditService`, `UsageEventWriterService`, and the `application-logs` driver), with the per-type knowledge (table names, normalization, access rules) spread across several modules. Three of them reimplemented the same ClickHouse insert, and the read side, the live stream, and the producers lived in different modules under two different names. This consolidates them into one `core-modules/event-logs/` subsystem (emit, write, live, read), with the per-type config in a single registry so adding an event type is roughly one file. The base Logs settings tab and free application logs shipped separately in #21180 (merged). This PR adds the unified backend, the registry, and the viewer's live mode and entitlement gating. ## Pipeline ```mermaid flowchart TB subgraph PROD["Producers"] A["auth, billing, impersonation,<br/>webhook, custom-domain"] U["usage listener"] F["logic-function executor (app logs)"] R["record CRUD (entity events)"] end EM["EventLogEmitterService<br/>createContext().insert* / dispatch()"] EQ(["entityEventsToDbQueue<br/>(existing, shared with timeline)"]) CIE["CreateEventLogFromInternalEvent"] SINK["WorkspaceEventSinkService.ingest()"] C1["ClickHouseEventSink"] C2["ConsoleEventSink"] LIVE["EventLogLiveService.publishWatched()<br/>(presence-gated)"] CH[("ClickHouse, 5 tables, async_insert")] CHAN(["WORKSPACE_EVENTS_CHANNEL"]) RS["EventLogsService (registry-driven read)"] LR["EventLogsLiveResolver"] UI["Settings > Logs"] A --> EM U --> EM F --> EM EM -->|direct| SINK R --> EQ --> CIE -->|ingest| SINK SINK --> C1 --> CH SINK --> C2 SINK --> LIVE -.->|if a viewer is watching| CHAN --> LR --> UI CH --> RS --> UI ``` ## What it does - Producers call `EventLogEmitterService.createContext().insert*()`, which builds a typed `WorkspaceEventEnvelope` and writes it through `WorkspaceEventSinkService` to the configured sinks (ClickHouse, Console) plus a presence-gated live fan-out. Record/CRUD events reach the same sink through the existing `entityEventsToDbQueue`. There is no dedicated queue; ClickHouse `async_insert` batches server-side. Writes are best-effort, as on main today. - `EVENT_LOG_TYPES[table]` is the per-type source of truth: the ClickHouse table, the required entitlement, the free-text filter column, and the row-to-GraphQL mapping. Read row shapes derive from the write rows. - Four modules along their dependency boundaries: `EventLogEmitterModule` (producer API), `EventLogIngestionModule` (sink layer), `EventLogLiveModule` (fan-out), and `EventLogsViewerModule` (the entitlement-gated GraphQL read, which is where billing/enterprise/permissions stay so producers stay light). - Logs viewer: per-table columns, filters (text, date, record), live mode, and an upgrade card that points to Billing on Cloud or the Admin Panel on self-hosted. Application logs are free on every plan; the other four require the `AUDIT_LOGS` entitlement (with a `NO_ENTITLEMENT` fallback to the upgrade card). - Renames `AuditService` to `EventLogEmitterService`, and the generic `Monitoring` event to a typed `Impersonation` event (`level` + `action`). - Removes `UsageEventWriterService`, the `application-logs` driver/module, and `AuditService`'s direct inserts. ## Durability Writes are best-effort, the same as main today (the old writers were fire-and-forget). A dedicated queue was tried mid-PR and removed: `async_insert` already batches server-side, so the queue only added durability, which isn't a requirement right now. The `EventSink` seam keeps a durable transport (e.g. a Redis-Streams buffer) easy to add later without touching producers. ## Out of scope S3 peer sink (seam only), Postgres or any second read path, `ReplicatedMergeTree`, ClickHouse table-schema changes, and the record-data `EVENT_STREAM_CHANNEL` (unchanged, separate concern). ## Testing Unit tests cover the registry definitions and row normalization, the entitlement gating, the envelope builders, and the producers. Integration tests cover the write paths (record create produces an `objectEvent`; the track mutation produces a `workspaceEvent`) and the read/query path across all five tables. Verified with typecheck, lint, a server boot, and GraphQL/SDK codegen.	2026-06-06 10:32:56 +02:00
Ratish jain	979047d004	fix: allow email change verification on self-hosted instances (#20123) ... fixes #20117 ## Technical Details Flow after fix: 1. User submits email change request 2. user.service.ts:517-524 calls sendVerificationEmail() with verificationTrigger: EMAIL_UPDATE 3. Guard checks: verificationTrigger === SIGN_UP → false → guard skipped 4. Verification token generated, email rendered and sent via emailService.send() 5. User receives confirmation email at new address 6. User clicks confirmation link → email update completes --- Impact - Minimal change: Only 3 lines modified in a single file - No breaking changes: Sign-up verification behavior unchanged - Security preserved: Email changes always require verification (correct security behavior) - Self-hosted friendly: Instance admins can disable sign-up verification while keeping email change verification active --------- Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-04 18:56:15 +00:00
Raphaël Bosi	41d5d80a65	Migrate Company and Person standard fields in preparation for the enrichment app (#21171) ... # Migrate Company and Person standard fields in preparation for the enrichment app ## Why Our standard `Person`/`Company` objects accumulated fields that aren't generic to every business, while missing a more universal revenue field that essentially every CRM ships. This PR makes the **Standard application** hold a tighter, more universal set of fields, and sets the stage for a follow-up PR that introduces a **People Data Labs enrichment app** to populate them. ## What changes ### Standard fields **Demoted (Standard → Workspace Custom application)** — not generic enough to ship as standard: | Object | Field | Type | | ------- | ------------------------------ | -------- | | Company | annualRecurringRevenue (ARR) | CURRENCY | | Company | employees | NUMBER | | Company | idealCustomerProfile (ICP) | BOOLEAN | | Company | xLink (X/Twitter) | LINKS | | Person | xLink (X/Twitter) | LINKS | | Person | city | TEXT | **Added (new generic Standard field)** — present in Salesforce/HubSpot/Zoho, PDL-populatable: | Object | Field | Type | | ------- | ------------- | -------------------------------------------------------- | | Company | annualRevenue | CURRENCY (generic total revenue; replaces the niche ARR) | ### Behavior by workspace * **New workspaces:** demoted fields are gone; `annualRevenue` is **active**. * **Existing workspaces:** demoted fields are **preserved as active custom fields, data intact**; `annualRevenue` is created **inactive (opt-in)** with its column ready, so a later activation is a metadata-only toggle. ### Upgrade commands (v2.9) Three idempotent, per-workspace commands, run in timestamp order: 1. **`upgrade:2-9:move-demoted-standard-fields-to-custom-application`** (1799000040000) — re-owns the 6 demoted fields to the workspace custom application (`isCustom = true`, new `applicationId` + fresh `universalIdentifier`), keeping their data and active state. 2. **`upgrade:2-9:rename-conflicting-custom-fields`** (1799000045000) — if a workspace already has a *custom* field named `annualRevenue`, renames it to `annualRevenueCustom` (data preserved via column rename) so the standard field can be added. Skips non-custom matches. 3. **`upgrade:2-9:add-inactive-generic-standard-fields`** (1799000050000) — creates `Company.annualRevenue` on existing workspaces as inactive, guarded to skip workspaces missing the target object or where the name is still taken. **Failure model:** the workspace iterator isolates failures per workspace (one workspace failing never affects others); within a workspace the runner records per-command status and resumes on the next run, and every command is idempotent, so partial runs self-heal. ### Supporting changes * **Field-option color palette:** widened the `TagColor` union (`twenty-shared` `FieldMetadataOptions` + the field-metadata `options.input` DTO) from 10 colors to the full theme palette, benefiting any future SELECT/MULTI_SELECT field. * **Dev seeder:** * The default "Annual Recurring Revenue" dashboard widget now points at the generic `annualRevenue` field (renamed to "Annual Revenue"). * Removed the "Companies by Size (Stacked by City)" widget (relied on the demoted `employees`). * `employees` is dropped from company data seeds and re-added as a **custom** field seed, so dev workspaces still get an `employees` column matching the demoted behavior. ### Cleanup Front-end record types (`Company.ts`/`Person.ts`), the `getDisplayNameFromParticipant` test mock, metadata integration specs, the Zapier `crud_record` test, and the regenerated `get-standard-object-metadata-related-entity-ids` snapshot. ## ⚠️ Breaking change (intentional) Removes standard fields `Company.annualRecurringRevenue`, `Company.employees`, `Company.idealCustomerProfile`, `Company.xLink`, `Person.xLink`, and `Person.city` from the core GraphQL schema (replaced by `Company.annualRevenue`). This is why the breaking-changes check reports a large number of removals — `graphql-inspector` flags any removed object field plus its derived aggregate/order-by/filter/update types. **Mitigation:** the `upgrade:2-9:move-demoted-standard-fields-to-custom-application` command re-owns these fields as custom fields per workspace, preserving their name and data, so existing tenants keep working. New workspaces won't have them.	2026-06-04 15:54:04 +00:00
Paul Rastoin	3d49642d12	[AUDIT] Run knip over twenty-server (#21159) ... # Introduction Run [knip](https://knip.dev/) over twenty-server Used config: ```json { "$schema": "https://unpkg.com/knip@5/schema.json", "workspaces": { "packages/twenty-server": { "entry": [ "src/main.ts", "src/command/command.ts", "src/queue-worker/queue-worker.ts", "src/database/scripts/setup-db.ts", "src/database/scripts/truncate-db.ts", "src/database/clickHouse/migrations/run-migrations.ts", "src/database/clickHouse/seeds/run-seeds.ts", "src/instrument.ts", "lingui.config.ts", "test/integration/graphql/codegen/index.ts", "test/integration/utils/setup-test.ts", "test/integration/utils/teardown-test.ts", "scripts/**/*.ts", "**/*.spec.ts", "**/*.integration-spec.ts" ], "project": ["src/**/*.ts", "test/**/*.ts", "scripts/**/*.ts"], "ignore": [ "src/database/typeorm/**/migrations/**", "src/database/typeorm/**/*.entity.ts", "**/*.workspace-entity.ts", "**/logic-function-resource/constants/seed-project/**" ], "ignoreDependencies": ["@types/psl", "@types/aws-lambda"], "ignoreBinaries": ["nest", "lingui", "typeorm"] } } } ```	2026-06-04 10:05:22 +00:00
Charles Bochet	58907b733c	feat(logic-function): add LIVE / PREBUILT execution modes (#20873) ... ## Summary ### Why 1. Sending the code to the lambda (~1Mb usually) is heavy on network and results to a constant traffic of ~30Mb/s on AWS which results into TB of network data every month 2. eval(1MB of code) is not that fast, it's heavy on memory and CPU on lambda side ### High level Adds two execution modes for logic functions, gated behind the new `IS_LOGIC_FUNCTION_PREBUILT_MODE_ENABLED` workspace feature flag (off everywhere by default): - **LIVE** (current behavior, preserved bit-for-bit): the compiled bundle is read from object storage and shipped in every Lambda invoke payload. Used for fast iteration in the workflow editor / Settings test runs. - **PREBUILT** (new): the bundle is installed onto the per-function Lambda alongside the unified executor, and invocations carry only `{ params, env, handlerName }` — saving JSON payload egress and warm-start `import()` cost on every call. ### Key design choices - **Unified Lambda handler** (`constants/executor/index.mjs`) dispatches at runtime: `event.code` present ? LIVE (write to `/tmp`, dynamic import) : `import('./prebuilt-logic-function.mjs')`. Both code paths always coexist on the deployment package, so the same Lambda can serve either mode without redeploying. - **Install runs inside the `validateBuildAndRun` migration pipeline**, not at execute time. `Create/UpdateLogicFunctionActionHandlerService` calls `driver.installPrebuiltBundle` when `executionMode` flips LIVE?PREBUILT or `checksum` changes while PREBUILT, gated on `isBuildUpToDate=true` and a fresh checksum. - **Strict execute, no reconciliation**: `LogicFunctionExecutorService.execute` resolves `effectiveExecutionMode` (caller override > feature flag > entity column). For PREBUILT it asks the driver `getInstalledBundleChecksum` (Lambda `twenty:bundle-checksum` tag for AWS, sidecar file locally) and throws `LOGIC_FUNCTION_PREBUILT_BUNDLE_NOT_INSTALLED` on mismatch. - **Feature flag gates every side effect**: with the flag off the executor forces LIVE, the action-handler install hooks bail before AWS, and workflow activation does not flip the mode. Rollback is just turning the flag off. ### Lifecycle - New workflow CODE step ? `LIVE`, no install. - Workflow activated ? build + activation flips `executionMode=PREBUILT` ? action-handler installs the bundle + sets the Lambda tag. - Draft from active version ? duplicated logic function reset to `LIVE`. - App install ? manifest converter sets `PREBUILT`, create-action handler installs. - Test runs (`executeOneFromSource`, workflow editor) pass `executionMode=LIVE` explicitly. ### Observability `[lambda-timing]` log lines now include `effectiveExecutionMode` and `payloadBytes`; the action handler logs `install_duration_ms` for each install. ## Test plan - [x] `npx nx typecheck twenty-server` ? passes - [x] `npx oxlint --type-aware` on all changed files ? 0 warnings, 0 errors - [x] `npx nx test twenty-server` ? 588 suites / 5009 tests pass (no regressions vs main) - [x] New unit suite `flat-logic-function-validator.service.spec.ts` ? 9/9 - [x] Existing `workflow-version-step-operations.workspace-service.spec.ts` ? 8/8 (verified the new token-based DI avoids a circular-import regression) - [x] Snapshot for `ALL_UNIVERSAL_FLAT_ENTITY_PROPERTIES_TO_COMPARE_AND_STRINGIFY` updated to include `executionMode` - [x] Integration suite `logic-function-execution.integration-spec.ts` extended to assert `executionMode=LIVE` on newly-created functions and continues to exercise the LIVE happy path - [ ] Manual staging rollout: flip `IS_LOGIC_FUNCTION_PREBUILT_MODE_ENABLED` per workspace, observe `[lambda-timing]` `payloadBytes` drop + `install_duration_ms`, then ramp in prod.	2026-06-02 11:14:39 +00:00