twenty

Author	SHA1	Message	Date
Paul Rastoin	b0d7516951	Deprecate `asExpression` from field metadata search_vector (#22287 ) ## Summary Fully deprecates the cached `asExpression` / `generatedType` settings on `TS_VECTOR` (searchVector) fields. Previously the generated-column expression was stored in `FieldMetadataSettings` and kept in sync via imperative recompute side-effects. It is now derived at DDL time from the `searchFieldMetadata` rows that describe which fields feed the search vector, making `searchFieldMetadata` the single source of truth and removing a whole class of cache-drift bugs. This is delivered across the milestones tracked in #2587 and coordinates with the frontend migration (#1428). ## Why - The searchVector expression lived in two places (stored `settings.asExpression` + the actual generated column), kept consistent by bespoke side-effects (`recompute-search-vector-on-field-rename`, label-identifier recompute, etc.). - The frontend reconstructed the searchable-fields list by regex-parsing the stored `asExpression`. - Both are brittle. Deriving the expression from `searchFieldMetadata` rows at build/run time removes the cache and the parsing. ## What changed ### Server - data model & derivation - Introduce the `tsVectorFieldMetadata` relation on `searchFieldMetadata` (`tsVectorFieldMetadataId` / universal identifier) linking each searchable-field row to its target `TS_VECTOR` field. - New runtime derivation `deriveSearchVectorAsExpressionForTsVectorField` (`flat-search-field-metadata/utils/...`) used by the create-object and update-field handlers to generate the column expression from `searchFieldMetadata` rows. - Remove `asExpression` / `generatedType` from stored settings: `FieldMetadataSettings.TS_VECTOR` is now `null`; the column builder (`generate-column-definitions.util.ts`) hardcodes `generatedType: 'STORED'` and requires the derived expression. - Delete the imperative recompute side-effects and the `compute-search-vector-universal-settings-from-object-manifest` path; drop the `settings` block from all 28 standard `compute-*-standard-flat-field-metadata` utils. ### Server - migration runner - New `rebuildSearchVector` marker on `update-field` actions: the orchestrator synthesizes targeted column rebuilds (`compute-search-vector-rebuild-target-universal-identifiers.util.ts` + the deprioritize aggregator) only when a searchFieldMetadata change or indexed-field rename actually requires it - instead of rebuilding on every settings touch. - Deferrable FKs + in-flight ID resolution so a `searchFieldMetadata` row and its `TS_VECTOR` field can be created in the same transaction (deterministic UUIDs). ### Frontend (contract change, #1428) - New `SearchFieldMetadataDTO` + dataloader exposing `searchFieldMetadataList` on object metadata. - `SettingsObjectSearchSection` now reads `objectMetadataItem.searchFieldMetadatas` instead of parsing `asExpression`; new `SearchFieldMetadataItem` type, fragment, and mapping updates. ### Upgrade commands (2.18) - `2-18-instance-command-fast-...-add-ts-vector-field-metadata-id-to-search-field-metadata` - `2-18-instance-command-fast-...-make-search-field-metadata-fks-deferrable` - `2-18-instance-command-slow-...-backfill-ts-vector-field-metadata-id-on-search-field-metadata` (These were relocated from 2.16 to 2.18 and re-timestamped into an ordered block - add column -> make FK deferrable -> backfill data - since 2.16/2.17 are released.) ### Tests - Updated search-vector side-effect integration specs to assert behavior (search works) rather than the now-removed `asExpression`; removed the obsolete expression-validation specs; refreshed the application-sync snapshot (`universalSettings: null`). ## Upgrade / compatibility notes - Existing workspaces keep their stored `settings` until a later cleanup; nothing reads it anymore. The new derivation drives all DDL going forward. - Schema changes are gated behind the 2.18 instance commands above. ## Known follow-up (separate PR) https://github.com/twentyhq/core-team-issues/issues/2620 - The column rebuild (`DROP`/`ADD` of the `searchVector` STORED column) cascade-drops its GIN index and does not recreate it - a pre-existing regression on `main` inherited here. A follow-up PR will fix the rebuild handler to recreate the GIN index and add a 2.18 workspace command to recompute every search vector + strip the deprecated settings. (Planned.) ## Test plan - [ ] `npx nx typecheck twenty-server` / `twenty-front` - [ ] `npx nx lint:diff-with-main twenty-server` / `twenty-front` - [ ] Server integration: create/update/delete field, rename indexed field, update object - search returns expected records - [ ] Run the 2.18 instance commands on a seeded DB; verify `tsVectorFieldMetadataId` backfilled and FKs deferrable - [ ] Frontend: object Search settings tab lists the correct searchable fields (no `asExpression` parsing) close https://github.com/twentyhq/core-team-issues/issues/2587 <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22287?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 09:16:01 +00:00
Félix Malfait	71370d9e66	fix(server): dedupe in-flight application translation catalog loads (#22285 ) ## Problem After v2.17.0 shipped app-owned metadata translations (#22235), `POST /metadata` got slower for workspaces with translation-carrying apps installed. Sentry flagged it as an N+1 (`performance_n_plus_one_db_queries`): a single request fires many concurrent identical queries: ```sql SELECT … FROM "core"."applicationTranslation" WHERE "applicationRegistrationId" = $1 AND "deletedAt" IS NULL ``` Span aggregates since the deploy: 272 such spans, avg 74 ms, p95 556 ms, max 694 ms, all on `POST /metadata`. HTTP stays 200 — it's latency, not errors. Reported via Sentry `TWENTY-SERVER-HQY` (`twenty-v7`). ## Root cause `ApplicationTranslationCacheService` kept a TTL value cache but had no in-flight de-duplication. The object/field metadata resolvers call `getCatalog` directly, per record. On a cold/expired (30 s TTL) cache, many fields of the same app resolve concurrently, all miss, and each fires its own `repository.find` — a classic cache stampede, which queues on the connection pool and produces the 556–694 ms tail. Each read also pulls the full per-locale `messages` JSON, so the redundant reads aren't free. ## Fix Rebuild the service on the shared `PromiseMemoizer` primitive — the same one `WorkspaceCacheService` and `CoreEntityCacheService` already use. It pairs the 30 s TTL value cache with a `pending` promise map, so concurrent callers for the same registration share a single in-flight query instead of stampeding. Per-request query count for a given app goes from N → 1. - Public API (`getCatalog` / `invalidate`) is unchanged — no caller touched. - `invalidate` now clears via `memoizer.clearKeys(...)` (clears both the cached value and any in-flight read), matching `WorkspaceCacheService`. - Adds a unit test asserting 10 concurrent `getCatalog` calls trigger exactly one `repository.find`, plus cache-hit / empty-locale / post-invalidation reload cases. ## Notes - Process-local 30 s TTL behaviour is unchanged (deliberate; no cross-process invalidation), this only removes the redundant concurrent reads. - Verified formatting with oxfmt locally; couldn't run the server test suite in this environment, so relying on CI for typecheck/test. https://claude.ai/code/session_01NiE7o3cd3zCLZarVkJa6UA --- _Generated by [Claude Code](https://claude.ai/code/session_01NiE7o3cd3zCLZarVkJa6UA)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22285?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 10:08:40 +02:00
Félix Malfait	41c10b9ee7	feat(server): resolve app-owned metadata translations at runtime (#22235 ) ## Summary First of a 4-PR stack that lets apps built with `twenty-sdk` translate their metadata, resolved at runtime. The standard Twenty app is modelled as "an app like any other" — `NULL applicationRegistrationId` ⟺ the standard app, no special-casing. This PR adds the server foundation and wires runtime resolution for object and field metadata: - New `applicationTranslation` core table + entity (nullable `applicationRegistrationId`, `locale`, `messages` jsonb), one row per (app, locale) to avoid multi-MB rows. - `ApplicationTranslationCacheService` (process-local, 30s TTL) + `ApplicationTranslationSyncService` (upsert + soft-delete from a manifest). - Shared `translateStandardLabel` util: application catalog → i18n bundle → source value. - Object/field resolvers + dataloaders prefetch and apply the per-app catalog. The new `applicationCatalog` param is optional, so standard behaviour is byte-unchanged. - Fast instance command to create the table. ## Stack PR 1/4, targets `main`. Followed by: (2) twenty-sdk extract/compile → `manifest.translations`, (3) resolution across the remaining metadata resolvers, (4) the per-locale standard-override editor. ## Tests Unit: `translateStandardLabel`, `resolveObjectMetadataStandardOverride` (including the application-catalog path). ## Verification note The remote dev environment for this branch could not complete `yarn install` (no package-registry egress), so typecheck/lint/tests were not run locally — CI is the source of truth for this stack. Changes follow existing patterns. https://claude.ai/code/session_01NiE7o3cd3zCLZarVkJa6UA --- _Generated by [Claude Code](https://claude.ai/code/session_01NiE7o3cd3zCLZarVkJa6UA)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22235?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-28 07:36:21 +02:00
martmull	e747bc3e42	Add backfill installation feature for pre-installed apps (#22199 ) ## After <img width="1070" height="514" alt="image" src="https://github.com/user-attachments/assets/9cbd2ff5-1678-4c2f-84da-074568f37c51" /> ## Summary Adds the ability to backfill application installations across all existing workspaces. This allows admins to retroactively install a pre-registered application on every active and suspended workspace through a background job, making the feature idempotent and non-blocking. ## Key Changes - Backend Service: Added `backfillApplicationOnAllWorkspaces()` method to `PreInstalledAppsService` that: - Validates the application registration exists - Iterates through all workspaces using `WorkspaceIteratorService` - Installs the app on each workspace - Swallows `APP_ALREADY_INSTALLED` errors for idempotency - Logs success/failure counts - Background Job: Created `BackfillApplicationInstallationJob` to process backfill requests asynchronously via the message queue - GraphQL Mutation: Added `backfillApplicationInstallation` mutation to `AdminPanelResolver` that: - Validates the application registration exists - Enqueues the background job - Returns immediately without blocking the request - UI Components: Enhanced `SettingsAdminApplicationRegistrationGeneralToggles` with: - New "Pre-install on new workspaces" toggle for the `isPreInstalled` flag - "Backfill on all workspaces" button with confirmation modal - Loading state and success/error snack bar feedback - Data Model: Added `isPreInstalled` field to `UpdateApplicationRegistrationPayload` input type - Tests: Added comprehensive unit tests for `PreInstalledAppsService.backfillApplicationOnAllWorkspaces()` covering: - Missing registration validation - Successful multi-workspace installation - Idempotent handling of already-installed errors - Proper error propagation for unexpected failures ## Implementation Details The backfill operation is designed to be: - Idempotent: Already-installed apps are skipped without error - Non-blocking: Runs as a background job via message queue - Resilient: Per-workspace failures don't block other installations - Observable: Logs aggregated success/failure counts for monitoring <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22199?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>	2026-06-26 16:21:27 +00:00
martmull	05df528fd5	Add logging on sync catalog job (#22192 )	2026-06-25 19:03:48 +00:00
Parship Chowdhury	1076866820	fix(server): preserve anyFieldFilterValue in view manifest sync (#22004 ) ### Summary - Fixes #19978 - `shouldHideEmptyGroups` was already wired up in the type and converter; this PR only closes the remaining gap for `anyFieldFilterValue`. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22004?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. --> --------- Signed-off-by: Parship Chowdhury <parshipchowdhury@gmail.com> Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-25 18:11:35 +02:00
martmull	a20ebfa880	feat(applications): remove the application custom settings tab (#22156 ) ## Summary Removes the application custom settings tab feature. This is one half of #22059, split out so it can be reviewed/merged independently from the variable-types enrichment. ## Changes - Remove the `SettingsApplicationCustomTab` component and its tab entry/rendering in `SettingsApplicationDetails`. - Stop syncing `settingsCustomTabFrontComponent` from application manifests — `ApplicationManifestMigrationService` now only syncs the default role. - Deprecate the now-unused fields (kept for backward compatibility, no longer read or synced): - `ApplicationDTO.settingsCustomTabFrontComponentId` (GraphQL `@deprecated`) - `ApplicationManifest.settingsCustomTabFrontComponentUniversalIdentifier` - the `settingsCustomTabFrontComponentId` column comment on `ApplicationEntity` The DB column is intentionally not dropped, so existing installations upgrade cleanly.	2026-06-25 12:29:45 +02:00
martmull	b5958fb331	Enforce server route app configuration requirements (#22091 ) ## Summary This PR enforces that applications exposing server route logic functions must be claimed (have an owner workspace) and installed on that owner workspace to be considered "configured". This ensures server route resolvers have a valid workspace context to execute in. ## Key Changes - ApplicationRegistrationVariableService: Enhanced `isConfiguredBatch()` to check server route configuration in addition to required variables - Added `ApplicationEntity` repository injection to track app installations - Implemented `isServerRouteConfigured()` private method that validates: - If app exposes server route logic functions, it must have an owner workspace - If it has an owner workspace, it must be installed on that workspace - Added comprehensive test suite covering all configuration scenarios - ServerRouteTriggerService: Removed feature flag check (`IS_SERVER_LOGIC_FUNCTION_ENABLED`) - Deleted `TwentyConfigService` dependency - Removed feature disabled exception handling - Server route triggers are now always enabled (gated by app configuration instead) - Configuration: Removed `IS_SERVER_LOGIC_FUNCTION_ENABLED` config variable from `ConfigVariables` - Exception handling: Removed `FEATURE_DISABLED` exception code from `ServerRouteTriggerExceptionCode` - UI & Documentation: Updated messaging and docs to reflect that server route apps require claiming and installation on owner workspace ## Implementation Details - Server route configuration is checked alongside required variable validation in `isConfiguredBatch()` - Uses efficient batch queries with `Promise.all()` to fetch variables, registrations, and installations in parallel - Installs are tracked via a Set of `${registrationId}:${workspaceId}` keys for O(1) lookup - Apps without server route functions are unaffected by this change https://claude.ai/code/session_01Ub3K25p2q4XE1LW1LGJbkG <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22091?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-24 16:20:05 +00:00
Félix Malfait	614bc7b7e6	feat: serve HTTP logic functions on isolated .withtwenty.com domain (#22045 ) ## Summary Implements [core-team-issues#2473](https://github.com/twentyhq/core-team-issues/issues/2473): serve HTTP-triggered logic functions from a dedicated, cookieless* public domain (`{workspaceSubdomain}.withtwenty.com`) instead of the same-site `/s/` route, so functions can safely return arbitrary headers — custom headers, `Permissions-Policy` (camera/mic/geolocation), `Cross-Origin-Opener-Policy: same-origin`, `Cross-Origin-Embedder-Policy: require-corp`, `Set-Cookie`, etc. The `/s/` route stays the strict, same-site path it is today. Self-hosting is unchanged — everything new is gated on `PUBLIC_DOMAIN_URL` being set. ### Why Today user-authored function responses are served same-site with the Twenty app, so the response-header allow-list is restricted to 5 safe headers and request headers are limited to a per-function allow-list. Serving from an origin that shares nothing with `.twenty.com` removes that constraint safely — the same "user content domain" pattern as GitHub (`.githubusercontent.com`) and CodeSandbox (`.csb.app`). ## What's in here Routing* - The root-path → `/s` rewrite happens at the nginx ingress, not in app code. The existing `api-ingress.yaml` already rewrites root paths onto `/s` (host-agnostically) when the edge sets `X-Twenty-Public-Domain: true`, so `.withtwenty.com` and registered custom public domains are handled by the same mechanism. (An earlier in-app middleware was removed as a redundant, wrong-layer duplicate.) - `WorkspaceDomainsService.resolveWorkspaceAndPublicDomain` recognizes `.` subdomains, resolves the workspace by subdomain, and returns `isIsolatedOrigin`. Explicitly registered public-domain rows still take precedence and keep their application scoping. The ingress preserves the `Host` header, so this resolution still fires. Headers (server) - Isolated origin → all response headers pass through and all request headers are forwarded. Same-site `/s/` keeps the strict allow-lists. (Global CORS already handles preflight/ACAO.) `/s/` deprecation for new routes (cloud only) - New `LOGIC_FUNCTION_LEGACY_ROUTE_CUTOFF` config var (ISO date, optional). When `PUBLIC_DOMAIN_URL` is set, functions created on/after the cutoff return 410 Gone on `/s/` with the new URL. Existing routes and self-hosted instances are untouched. Frontend education - `publicFunctionDomain` added to `ClientConfig` (from `PUBLIC_DOMAIN_URL`). - The logic-function Live URL now resolves to `https://{workspaceSubdomain}.{publicFunctionDomain}{path}` on cloud, falling back to `/s/` for self-hosting. - Front components call their functions through the SDK (`RestApiClient`), which now targets the isolated domain via the injected `TWENTY_FUNCTIONS_URL`. - New "Public URL" section on the application Settings tab explaining the isolated domain (shown when the app exposes HTTP-triggered functions). Docs: note the `withtwenty.com` domain for external callers in the apps guide. ## Infra prerequisites (not code — needs dashboard work) - Wildcard DNS `.withtwenty.com` (proxied) + wildcard TLS in the public-domain Cloudflare zone. - Edge (Cloudflare) sets `X-Twenty-Public-Domain: true` for `.withtwenty.com` requests, so the existing nginx ingress rewrites them onto `/s` (same header the custom-domain flow already relies on). - Set `PUBLIC_DOMAIN_URL=https://withtwenty.com` on cloud. - Submit `withtwenty.com` to the Public Suffix List (required for cross-tenant cookie isolation before relying on `Set-Cookie`). ## Test plan - [x] `nx typecheck twenty-server`, `nx typecheck twenty-front` - [x] `lint:diff-with-main` + oxfmt clean (server + front) - [x] `npx jest route-trigger public-function-domain domain-server-config workspace-domains build-logic-function-event client-config` → server unit tests passing (resolution tiers, header passthrough vs allow-list, `/s/` cutoff 410) - [x] `npx jest getLogicFunctionHttpUrl` (front) and `nx test twenty-client-sdk` (RestApiClient routing) passing - [x] CI green (server, front, sdk, renderer, ui, zapier, example apps) - [ ] Manual: hit `{subdomain}.withtwenty.com/` end-to-end once infra is provisioned <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22045?utm_source=github" rel="nofollow noreferrer noopener" target="_blank">``<img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg">``</a>	2026-06-24 15:57:01 +02:00
martmull	b5a1aed24b	feat(server): run server-exposed logic functions in the owner workspace (#22002 ) ## Summary Implements the server-level logic-function tier in the simplest shape: a logic function is "server-exposed" iff its manifest entry carries `serverWebhookTriggerSettings`. Execution delegates to the owner-workspace copy of that function — billing, throttling, env vars, and the existing executor all apply uniformly against that workspace. Supersedes #21971 with the simplified design from that discussion (no `applicationRegistrationLogicFunction` registry, no dedicated manifest type, no separate SDK helper, no special throttling). ## Design - Manifest: `LogicFunctionManifest` gains `serverWebhookTriggerSettings?`. The declarative `workspaceIdResolver` shape is dropped. - Materialization: those settings become two new jsonb columns on `LogicFunctionEntity`. The manifest → flat converter and the create-from-source DTO/util forward them; the property-config map and editable-properties list are extended. - Lookup: a single QB query joins `logicFunction → application → applicationRegistration` and filters on `lf.workspaceId = reg.workspaceId` to get only the owner workspace's copy. - Webhook: `POST /webhooks/server/:logicFunctionUniversalIdentifier` → `ServerWebhookTriggerService.handle` → join lookup → `LogicFunctionTriggerService.run`. No registry table, no `:applicationRegistrationUniversalIdentifier` segment, no resolver. - Gate: `IS_SERVER_LOGIC_FUNCTION_ENABLED` config var (disabled by default). ## Test plan - [x] `npx jest server-webhook-trigger` — 9 unit tests across the webhook service. - [x] `npx jest logic-function` — 88 existing tests stay green. - [x] `npx nx typecheck twenty-server`. - [x] `npx nx lint:diff-with-main twenty-server`. - [x] Reset DB → init → run `database:migrate:prod` → run `database:migrate:generate --name pending-migration-check` → no drift. - [ ] Manual: hit `/webhooks/server/<uid>` end-to-end against a manifest carrying `serverWebhookTriggerSettings`. https://claude.ai/code/session_01GgsnCGmYJ26xRirx8va1Yh --- _Generated by [Claude Code](https://claude.ai/code/session_01GgsnCGmYJ26xRirx8va1Yh)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22002?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-24 13:34:12 +00:00
Paul Rastoin	e9d5d71cd3	Wire up search field metadata (#21964 ) ## Part 1 - Exact scope of the current PR (#21964) close https://github.com/twentyhq/core-team-issues/issues/2586 This PR introduces `searchFieldMetadata` as a first-class flat metadata entity and migrates the existing search surface onto it, with no change to which records are searchable (ISO with `main`). In scope (what the PR does): - New flat entity `searchFieldMetadata` (universalIdentifier, applicationId, `position`, maps, conversions), registered in the central flat-entity constants and the migration build orchestrator. - `searchVector.asExpression` is derived server-side from `searchFieldMetadata` rows (validated by `isSafeTsVectorExpression`); never trusted from client input. - Derivation order is deterministic, driven by each row's `position` ([compute-search-vector-as-expression-from-search-field-metadatas.util.ts](packages/twenty-server/src/engine/metadata-modules/flat-search-field-metadata/utils/compute-search-vector-as-expression-from-search-field-metadatas.util.ts)), replacing the previous non-deterministic `(createdAt, id)` sort. That sort collapsed to random UUIDs for standard fields (same `createdAt`), so any rename/relabel rewrote the `STORED` generated column to a logically-identical-but-textually-different expression and produced a permanent per-workspace diff vs the standard definition. Ordering now equals provisioning order; ties break on `universalIdentifier`. - Provisioning at object creation mirrors the existing surface exactly and seeds `position`: - custom objects -> the `name` field only, at `position: 0` ([build-default-search-field-metadatas-for-custom-object.util.ts](packages/twenty-server/src/engine/metadata-modules/object-metadata/utils/build-default-search-field-metadatas-for-custom-object.util.ts)) - standard objects -> their curated `SEARCH_FIELDS_FOR_` sets, `position` = the curated index - Backfill (instance + workspace commands in `2-16`) provisions rows for existing workspaces with the same surface and the same positions* (standard from the curated standard maps, custom `name` = `0`), scoped to the workspace's own custom application ([build-search-field-metadata-backfill-operations.util.ts](packages/twenty-server/src/database/commands/upgrade-version-command/2-16/utils/build-search-field-metadata-backfill-operations.util.ts)). The `position` column is added in the same `2-16` fast instance command as `universalIdentifier`/`applicationId`. - Field rename of an already-indexed field recomputes `asExpression` (positions preserved, so order is stable) ([recompute-search-vector-on-field-rename.util.ts](packages/twenty-server/src/engine/metadata-modules/flat-field-metadata/utils/recompute-search-vector-on-field-rename.util.ts)). - Field delete drops the matching row(s) and recomputes; remaining rows keep their relative order (no renumber) ([from-delete-field-input-to-flat-field-metadatas-to-delete.util.ts](packages/twenty-server/src/engine/metadata-modules/flat-field-metadata/utils/from-delete-field-input-to-flat-field-metadatas-to-delete.util.ts)). - Object relabel is additive and ISO/regression-fix only: it indexes the new label identifier appended last (`position = max(existing) + 1`) without dropping `name` ([recompute-search-vector-on-label-identifier-update.util.ts](packages/twenty-server/src/engine/metadata-modules/flat-object-metadata/utils/recompute-search-vector-on-label-identifier-update.util.ts)). This is a deliberate, temporary bridge. Explicitly OUT of scope (deferred): - No API to edit `searchFieldMetadata` (no user-facing search-field configuration, including `position` — it is internal and only written by provisioning/backfill/recompute). - No auto-indexing of arbitrary searchable fields. Creating a custom TEXT/EMAILS/etc. field does NOT add it to search (the `computeSearchFieldMetadataCreationForFields` behavior was removed in `e6820ad`). - No field-type-transition handling (field type is immutable - not in `FLAT_FIELD_METADATA_EDITABLE_PROPERTIES`, so that path was dead code). - No `position` validation (uniqueness/range) and no multi-vector / per-field `weight` config — deferred to the configurable-search follow-up (#1428). Net: `searchFieldMetadata` becomes the source of truth for the same surface as `main`. The only intentional divergences from `main` are "relabel preserves `name`" (additive) and the deterministic `position`-ordered `asExpression` (a correctness/perf fix that is byte-identical to provisioning order, so it does not change the searchable surface). --------- Co-authored-by: Félix Malfait <felix@twenty.com>	2026-06-23 16:27:13 +02:00
Raphaël Bosi	c52c983b90	Source app About description from README and improve internal app READMEs (#22012 ) ## What - The SDK manifest build now sources an app's `aboutDescription` (the long-form "About" tab content) from its `README.md`. An explicit `aboutDescription` in the config still wins, matching the existing marketplace CDN fallback. - Removed the now-duplicated `aboutDescription` from internal app configs and deleted the standalone `ABOUT_DESCRIPTION` constant files. - Rewrote internal app READMEs to read as user-facing About content: stripped developer/build/source-path noise, and expanded the thin ones. `call-recording` and `self-hosting` (one-liners over substantial apps) and `people-data-labs` were rewritten from a close reading of the code; `twenty-exa` was verified for accuracy. - Added a unit test (and a fixture README) covering README → `aboutDescription` in the build. ## Why The README and the About description were maintained separately and drifted. Making the README the single source keeps the About tab accurate and removes duplicated copy. ## Notes for reviewers - Internal apps depend on the published `twenty-sdk`, so the build change takes effect for them after an SDK release + dependency bump. Until then, published apps still get README → `aboutDescription` via the marketplace CDN sync. - Standard/Custom app descriptions are unchanged (they are resolved in the frontend, not via the manifest). <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22012?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-23 15:27:52 +02:00
Félix Malfait	a682c8fa62	feat(sdk): declare row-level permission predicates in the role manifest (#21919 ) ## Why Apps can declare object and field permissions on a role via `defineRole`, but not row-level security. The RLS engine and the metadata-sync machinery already support predicates fully — they're first-class universal flat entities, the `FlatRole` already carries `rowLevelPermissionPredicateUniversalIdentifiers`, and the workspace-migration layer has builders/validators/handlers for them. The only gap was the manifest layer: `RoleManifest` had no field for predicates, so the sync converter always left them empty. As a result, the only way to ship RLS with an app was a post-install script that pushed predicates through the `upsertRowLevelPermissionPredicates` mutation. That mutation assigns predicates to the workspace's generic custom application, not the app that owns the role — so a single role's definition ends up split across two applications and drifts on every upgrade (you have to remember to re-run the script). The Partner app does exactly this today via `configure-partner-rls.ts`. ## What Adds `rowLevelPermissionPredicates` and `rowLevelPermissionPredicateGroups` to `RoleManifest` / `RoleConfig`, mirroring how `objectPermissions` / `fieldPermissions` already flow end-to-end: - twenty-shared — predicate + predicate-group manifest types on `RoleManifest` (referencing objects/fields by `universalIdentifier`, operand/logical-operator from the existing GraphQL enums). - twenty-sdk — `defineRole` accepts and validates them; the build derives deterministic predicate `universalIdentifier`s (groups keep an explicit one so predicates can reference them). - twenty-server — two converters turn manifest predicates/groups into universal flat entities during application-manifest sync, so they are created/updated/deleted together with the role and owned by the app that ships it. ### Bug fix found along the way The migration build order ran the `rowLevelPermissionPredicate(Group)` builders before the `role` builder, so a predicate declared alongside a brand-new role failed validation with `ROLE_NOT_FOUND`. They now run after the role builder, exactly like object/field permissions. ## Partner app (second commit) Converts `partner.role.ts` to declare its five predicates inline and deletes `configure-partner-rls.ts` + the `rls:configure` scripts — the workaround this PR is meant to retire. The predicates are byte-for-byte the same semantics as the script produced. > Live-deployment note: the existing script-created predicates are owned by the custom application, so the Partner app sync won't touch them. Clear them once (e.g. an empty upsert on the Partner role) around deploy to avoid duplicates. Kept as a separate commit so it can be split out if reviewers prefer. ## Testing - Integration (full app): new `successful-manifest-sync-row-level-permission-predicate.integration-spec.ts` — installs an app whose role declares a predicate and asserts the predicate row is created (and owned by the app, not the custom app), updated in place on re-sync, removed when dropped from the manifest, and removed on uninstall. Ran locally against a seeded test DB ✅. - Re-ran the existing cross-app permission + view-field manifest suites to confirm the build-order change doesn't regress object/field-permission sync (13/13 ✅). - Unit (utils only): `defineRole` validation and `fromRoleConfigToRoleManifest` deterministic-id derivation. - Docs: new "Row-level security" section in `apps/config/roles.mdx`. ## Scope notes / possible follow-ups - Surfacing RLS in the app-install permission summary UI was intentionally left out (predicates restrict rather than grant, and typically live on a non-default role) — easy follow-up if wanted. - The `upsertRowLevelPermissionPredicates` mutation still homes out-of-band predicates on the custom app for app-owned roles; making that consistent (or rejecting it, like field permissions already do) is a sensible follow-up. https://claude.ai/code/session_01MipAis9z9okd4oCm9HCKEf --- _Generated by [Claude Code](https://claude.ai/code/session_01MipAis9z9okd4oCm9HCKEf)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21919?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-21 22:09:19 +02:00
Abdullah.	d74b6aeadf	fix(security): bump nodemailer to 9.0.1 (raw-option SSRF / file read) (#21903 ) ## fix(security): bump nodemailer to 9.0.1 (raw-option SSRF / file read) Resolves [Dependabot Alert #1518](https://github.com/twentyhq/twenty/security/dependabot/1518) and [#1519](https://github.com/twentyhq/twenty/security/dependabot/1519). ### What `nodemailer` `<= 9.0.0` lets the message-level `raw` option bypass `disableFileAccess`/`disableUrlAccess`, enabling arbitrary file read and full-response SSRF in the delivered message ([GHSA advisory](https://github.com/twentyhq/twenty/security/dependabot/1518), High). Patched in `9.0.1`. ### How — direct bump, no resolution - twenty-server: `nodemailer ^8.0.5 -> ^9.0.1` (major bump). - seed-dependencies: the application-package template `nodemailer ^8.0.5 -> ^9.0.1`; both `DEFAULT_PACKAGE_JSON_CHECKSUM` and `DEFAULT_YARN_LOCK_CHECKSUM` regenerated to match the recomputed seed files (the deps-layer cache key). ### Compatibility — verified nothing breaks It is a major upgrade, so the 9.0 breaking change was checked against the current tree. The only behavior change is stricter TLS validation when nodemailer fetches remote content (attachment `href`/`path` URLs, built-in OAuth2 token endpoints, HTTP/HTTPS proxy `CONNECT`). None of those paths are reachable here: - Attachments are passed as content buffers, never `path`/`href`. - Gmail OAuth uses googleapis, not nodemailer's built-in OAuth2. - No proxy on any transport. - The SMTP socket TLS is governed separately (unchanged). Verification: `typecheck twenty-server` passes (with `@types/nodemailer ^7.0.3`), and the `email-sender`, `gmail-message-outbound`, and `imap-smtp-caldav-connection` suites pass (10 tests). ### Not covered (follow-up) Root alert #1521 will stay open: `imapflow@1.3.6` exact-pins `nodemailer@8.0.10`. The clean fix is `imapflow 1.4.2` (which pins nodemailer `9.0.1`), but it published 2026-06-19 and is age-gated until ~2026-06-22 — it will land then as a parent-bump (no resolution). ### Verification - `nodemailer` resolves to `9.0.1` for twenty-server; seed lockfile has `9.0.1`; both seed checksums match the canonical recompute. - `yarn install --immutable` passes.	2026-06-21 15:05:00 +02:00
Félix Malfait	23f5ba9ebf	feat: add resizable kanban column width (#21828 ) ## What & why Lets users resize the columns of a Kanban (record board) view. Requested by a user; the design avoids the "ragged board" problem by making the width a single shared value. ## Behaviour - A drag handle appears on the right edge of every column header. - Because all columns read one width value, dragging any handle resizes every column together — they can never end up mismatched. - Width is clamped between 150px and 400px (default 200px). - The width is persisted per view and restored on reload. ## Approach Backend — a new nullable `View.kanbanColumnWidth` field, threaded through the existing view-level setting pattern (the same one `kanbanAggregateOperation` / `shouldHideEmptyGroups` use), so it gets create/update/manifest/override support for free: - entity column + `ViewOverrides` + `@WasIntroducedInUpgrade` - `CreateViewInput` / `UpdateViewInput` (`Int`, `@Min(150)`/`@Max(400)`) + `ViewDTO` - flat-view editable properties, entity-properties config, compare-type, standard-view + manifest converters - a fast instance command adding the `core.view` column Frontend — the value hydrates into a view-scoped atom and drives a single CSS variable set on the board container, which both column headers and bodies read. Live dragging only writes that CSS variable (no per-move React re-render); the final width is committed to the atom and persisted via `updateView` on pointer-up. ## Nullability / defaults `kanbanColumnWidth` is nullable — `null` means "never resized" and the UI falls back to the 200px default, so existing rows need no backfill. ## Validation - `nx typecheck twenty-server` ✅ and `nx typecheck twenty-front` ✅ - `nx lint:diff-with-main twenty-server` ✅; frontend lint fixes applied (split constants to one-per-file, removed `useRef`-for-state in favour of `useState`). - Draft pending a final green CI run (the dev container reclaimed `node_modules` mid-session; re-running locally). ## Test plan - [ ] Drag a kanban column edge → all columns resize together, clamped 150–400px - [ ] Reload → width persists for that view; other views unaffected - [ ] A view that was never resized still renders at 200px https://claude.ai/code/session_016Qe6oDBkhVbrq2QkXBJ5nE --- _Generated by [Claude Code](https://claude.ai/code/session_016Qe6oDBkhVbrq2QkXBJ5nE)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21828?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Claude <noreply@anthropic.com>	2026-06-19 15:58:13 +02:00
Paul Rastoin	98c35ea804	App uninstall lambda, layers cleanup (#21749 ) # Introduction On a logic function deletion also remove the driver entry On a app uninstall also remove the sdk layer ( keeps the dep one as it can be shared across several lambda ) \| Resource \| Scope \| Before this PR \| After \| \|---\|---\|---\|---\| \| DB metadata (functions, objects, fields…) \| per-app \| deleted \| deleted \| \| Source folder (`FileFolder.Source`) \| per-function \| deleted \| deleted \| \| Built handler file (`FileFolder.BuiltLogicFunction`) \| per-function \| deleted \| deleted \| \| Lambda function \| per-function \| leaked \| deleted (driver `delete`) \| \| SDK layer `sdk-<wsId>-<appId>` (all versions) \| per-app \| leaked \| deleted (driver `deleteApplicationResources` → `deleteSdkLayer`) \| \| Deps layer `deps-<checksum>` \| shared across apps/workspaces \| not deleted \| intentionally not deleted (content-addressed, GC'd) \| ## What I don't like about all that Right now there's some non reversible side effect inside the workspace migration transaction - If the transaction fails we're facing data loss - It also slows down everything I'm about to create a new PR that allow population post transaction commit side effect / cleanup to be run later <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21749?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-19 13:10:39 +00:00
Paul Rastoin	26db3f5735	Deprecate legacy encryption (#21831 ) # Introduction Still preserving the cross-upgrade flow close https://github.com/twentyhq/core-team-issues/issues/2465 <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21831?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-19 11:32:39 +00:00
Abdullah.	8ff494e5e8	fix(security): bump tar to 7.5.16 in seed-dependencies (PAX file smuggling) (#21829 ) ## fix(security): bump tar to 7.5.16 in seed-dependencies (PAX file smuggling) Resolves [Dependabot Alert #1500](https://github.com/twentyhq/twenty/security/dependabot/1500). ### What `tar` (`node-tar`) `<= 7.5.15` applies a PAX size override to intermediary GNU long-name/long-link headers, causing a tar-parser interpretation differential (file smuggling) — [GHSA-vmf3-w455-68vh](https://github.com/advisories/GHSA-vmf3-w455-68vh). Patched in `7.5.16`. This is the seed-dependencies holdout deferred from the main tar PR (#21813): that lockfile + its checksum constants were also touched by the form-data PR, so it was carved out to avoid a conflict. The form-data PR has since merged, unblocking it. ### How - Refreshed `tar` `7.5.13 -> 7.5.16` in `seed-dependencies/yarn.lock` (transitive via `^7.5.4`, which already permits it) — an in-range refresh, no override. - Regenerated `DEFAULT_YARN_LOCK_CHECKSUM` in `get-default-application-package-fields.util.ts` so the row-stored checksum matches the value recomputed from file content in `application.service.ts` (the deps-layer cache key; `logicFunctionCreateHash` = SHA-512, first 32 hex). `package.json` is unchanged, so `DEFAULT_PACKAGE_JSON_CHECKSUM` is unaffected. ### Verification - No `tar <= 7.5.15` remains in the seed lockfile. - Both checksum constants verified to match the canonical recompute of the current seed files. - Lint + format pass on the changed `.ts` file.	2026-06-19 11:46:28 +02:00
Abdullah.	26b4d6caed	fix(security): bump form-data to 4.0.6 (CRLF injection) (#21808 ) Resolves [Dependabot Alert #1473](https://github.com/twentyhq/twenty/security/dependabot/1473), [#1475](https://github.com/twentyhq/twenty/security/dependabot/1475), [#1477](https://github.com/twentyhq/twenty/security/dependabot/1477), [#1478](https://github.com/twentyhq/twenty/security/dependabot/1478), [#1480](https://github.com/twentyhq/twenty/security/dependabot/1480), [#1482](https://github.com/twentyhq/twenty/security/dependabot/1482), [#1484](https://github.com/twentyhq/twenty/security/dependabot/1484), [#1486](https://github.com/twentyhq/twenty/security/dependabot/1486), [#1488](https://github.com/twentyhq/twenty/security/dependabot/1488), [#1490](https://github.com/twentyhq/twenty/security/dependabot/1490), [#1492](https://github.com/twentyhq/twenty/security/dependabot/1492), [#1494](https://github.com/twentyhq/twenty/security/dependabot/1494), [#1495](https://github.com/twentyhq/twenty/security/dependabot/1495), [#1497](https://github.com/twentyhq/twenty/security/dependabot/1497), [#1499](https://github.com/twentyhq/twenty/security/dependabot/1499), [#1501](https://github.com/twentyhq/twenty/security/dependabot/1501) and [#1506](https://github.com/twentyhq/twenty/security/dependabot/1506).	2026-06-19 08:46:32 +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
Weiko	cc4659ce11	fix(server): type WasRemovedInUpgrade columns with WasRemovedInUpgrade<> (#21785 ) ## Context WasRemovedInUpgrade type brand was introduced in https://github.com/twentyhq/twenty/pull/21228/changes#diff-1b6d688610669a46b3ee8e3a41b1c7eb0ee03e19146d0d249f95df6e56164a92R15 for the `isCustom` property deprecation. The @WasRemovedInUpgrade decorator and the WasRemovedInUpgrade<T> type are meant to go together: the type brand makes the property optional in every derived flat-entity type, so the column only needs to be declared on the entity itself. RolePermissionFlagEntity.flag had the decorator but was typed as a plain PermissionFlagType, forcing the property to be supplied everywhere. This PR: - Types flag as WasRemovedInUpgrade<PermissionFlagType> (matching the isCustom reference impl on object/field metadata). - Removes the now-redundant flag from the flat-entity construction sites, the create input, and the service call site — leaving it only on the entity. The GraphQL RolePermissionFlagDTO.flag is kept (it's an API field derived from permissionFlag.key, not the removed column). - Fixes a latent brand-leak in the flat-entity config type: toStringify is computed via object-detection, and a branded type reads as an object. This was harmless for boolean but wrongly forced toStringify: true for enum/string columns. Added UnwrapWasRemovedInUpgrade<T> and applied it so the brand is transparent making the pattern work for any type, not just booleans. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21785?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-18 15:23:24 +02:00
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
martmull	306a1454aa	Update Connection provider path (#21678 ) ## Before After connecting to oAuth linear app connection: <img width="1512" height="851" alt="image" src="https://github.com/user-attachments/assets/39b94aaf-648f-46a6-8f4d-deb1cb7e22c5" /> ## After Redirects to Linear <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21678?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-16 13:53:13 +00:00
Charles Bochet	97871131a1	fix(server): mitigate integration-test OOM flakiness (#21588 ) ## Problem `server-integration-test` shards have been failing intermittently across unrelated PRs with a distinctive signature: the shard exits code 1 with no jest assertion failure, no `Test Suites:` summary, and no V8 `JavaScript heap out of memory` error — the process just dies mid-run. Failures hit random shards and clear on re-run (e.g. an unrelated branch failed shard 6 once, then passed 3× on identical code), while the `merge_group` gate stays green. ### Root cause Each shard runs a single in-band jest process that boots one shared NestJS app (`globalSetup` → `app.listen`) and holds it for the entire shard, driving heavy metadata migrations + cache rebuilds in that one process. `NODE_OPTIONS=--max-old-space-size=12288` let V8 grow to 12 GB — above the `ubuntu-latest` runner's available RAM (16 GB, shared with Postgres/Redis/ClickHouse). V8 therefore deferred aggressive GC and grew past physical memory, so the OS OOM-killer killed the process before V8 hit its own ceiling — which is why there's no heap error and no jest summary, just a silent exit. ## Changes (CI/test-only — prod runtime untouched) - Lower the integration jest heap cap `12288` → `6144` so V8 self-limits below physical headroom instead of being OS-killed. Counterintuitively safer: a real leak now surfaces as a visible heap error naming the test, rather than a silent death. (`database:reset` keeps 12288 — it runs alone, before jest.) - Add `--logHeapUsage` to the integration jest runs to expose the per-file heap trend for confirming/pinpointing the growth. - Split integration tests across 16 shards (was 10) to lower the peak working set per shard. - Make perf logging a first-class `LoggerService` tool (per @prastoin's review): add `LoggerService.perf()` and unify the existing `time()`/`timeEnd()` helpers into `perfTime()`/`perfTimeEnd()` (now routed through the driver), all gated by a new `PERF_LOG_ENABLED` config var. It defaults on so real environments keep emitting the install-perf logs, and `.env.test` sets it `false` to mute the per-action flood in integration tests. The `application-manifest` and `validate-build` services were moved from the built-in `Logger` to `LoggerService` to use it. ## Notes - `--max-old-space-size` lives only in the `test:integration` nx target; it is not the prod server heap setting, so prod is unaffected. - This is mitigation. If `--logHeapUsage` shows monotonic growth across files, there's a real accumulation in the long-lived app (retained flat-maps / metadata cache) worth a follow-up heap-snapshot fix. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21588?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-15 15:54:51 +02:00
Weiko	f63f053444	CommandMenuItem overridable entity (#21486 ) ## Context Second PR of the overridable-entities track (after #21436 for views): command menu items become overridable so that edits on non-owned items are stored as overrides instead of mutating the row, and deletion/deactivation becomes reversible. ## What this does - `CommandMenuItemEntity` now extends `OverridableEntity<CommandMenuItemOverrides>` (adds `isActive` + `overrides`). All editable properties are overridable for now (to discuss). - Update: mutations on a command item not owned by the caller (standard items) are written into `overrides`; reads merge them in the DTO. The command palette edit mode (pin, reorder, shortLabel) now preserves standard values, "Reset label to default" gains true post-save semantics. - Delete: protected items are deactivated (`isActive = false`) instead of deleted; custom items still hard-delete. - Object deactivate/enable toggle: now flips `isActive` on the command item (merged into the main migration call) instead of delete/recreate; a create-if-missing fallback covers legacy deactivated objects. - Front: inactive command items are filtered out of the palette selector. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21486?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-13 14:21:27 +02:00
Félix Malfait	1efa3567ef	Rename isUIReadOnly to isUIEditable, add isUICreatable, expose both to app developers (#21504 ) <!-- CURSOR_AGENT_PR_BODY_BEGIN --> # UI capability flags: `isUIEditable` + `isUICreatable` ## Per-verb capability model This PR replaces the negative `isUIReadOnly` metadata flag with positive, per-verb capability flags (à la Salesforce `createable`/`updateable`): - `isUIEditable: boolean`, default `true` — rename of `isUIReadOnly` with inverted polarity, on both `objectMetadata` and `fieldMetadata`. It is one concept ("can the user edit this through the generic UI?") at two altitudes, so it carries one name at both levels. - `isUICreatable: boolean`, default `true` — new, object-level only (fields have no create verb). When `false`, no generic UI affordance to create a record of this object appears anywhere (table "+" buttons, board column add, calendar add, relation-section "Add new", record picker "Add new", command-menu create action and its keyboard shortcut). Both flags are UI-affordance flags only: the server does not block create/edit mutations based on them, so the system, API, and workflows continue to mutate these records freely. They are orthogonal statements about the object's nature with no implication rule in the data model. Because today's inline creation UX creates a blank record the user must then edit, the frontend create predicate currently requires both `isUICreatable` and effective editability. There is no CREATE permission in `ObjectPermissions`; the frontend keeps gating creation on `canUpdateObjectRecords` as a proxy, ANDed with the new flags. ## Unified create predicate All generic creation entry points now flow through one predicate, `canCreateRecordsForObjectMetadataItem` (`isUICreatable` && not `isSystem` && not effectively read-only, where effective read-only covers `isUIEditable`, `isRemote`, and the `canUpdateObjectRecords` proxy via `isObjectMetadataReadOnly`). This deletes the previously hardcoded suppression lists: - `isRecordTableCreateDisabled.ts` and its hardcoded `WorkflowRun`/`WorkflowVersion` list — deleted; those objects (plus `workspaceMember`) now declare `isUICreatable: false` in the standard application instead. - The hardcoded `workspaceMember` guard inside `useAddNewRecordAndOpenSidePanel.ts` — deleted. - The `CREATE_NEW_RECORD` command menu item's availability expression now checks `objectMetadataItem.isUICreatable`, `isUIEditable`, `isSystem`, and `isRemote`; a workspace upgrade command re-syncs the expression in existing workspaces. Component-local conditions (soft-delete filter active, layout customization mode) stay in their components. ## GraphQL compatibility and removal plan The schema delta versus main is purely additive plus deprecations — zero breaking changes: - `isUIReadOnly` remains on both the ObjectMetadata and FieldMetadata GraphQL output types for one release as a deprecated field computed as `!isUIEditable` (`deprecationReason: 'Use isUIEditable'`). The Twenty frontend no longer queries it. - `isUIReadOnly` also remains on the input side for one release (`CreateFieldInput`, `UpdateFieldInput`, `FieldFilter`, `ObjectFilter`), keeping the schema shape identical to main for those members. On create it acts as a legacy alias mapped to `!isUIReadOnly` (`isUIEditable` wins when both are provided); on update it is ignored, exactly as on main (it was never an editable property). Filtering on the deprecated member keeps working until the column is dropped at upgrade time; after that it is a deprecated no-op surface kept only for schema compatibility. Removal plan for next release: drop `isUIReadOnly` from the output DTOs (and resolvers' `@ResolveField`s), from the input/filter types, from the create-input mapping, and the `@WasRemovedInUpgrade`-retained entity columns and decorators. ## ⚠️ Webhook / database-event payload shape change The `database-event-payload` type in `twenty-shared` got a clean rename (no alias): metadata snapshots in webhook and database-event payloads now carry `isUIEditable` (and `isUICreatable` at object level) instead of `isUIReadOnly`, with inverted polarity. Consumers of these payloads that read `isUIReadOnly` must switch to `isUIEditable`. ## New manifest properties (app-developer DX) Application developers can now set these flags in their app manifests (purely additive — existing manifests and older `twenty-sdk` versions are unaffected, defaults apply when omitted): - `objects[].isUICreatable?: boolean` (default `true`) - `objects[].isUIEditable?: boolean` (default `true`) - `fields[].isUIEditable?: boolean` (default `true`) The manifest converters previously hardcoded `isUIReadOnly: false`; they now read the manifest values with `?? true` defaults. The types are re-exported through `twenty-sdk` from `twenty-shared`. ## Migration & backfill - One fast instance command: adds `isUIEditable` (NOT NULL default `true`) on `core."objectMetadata"` and `core."fieldMetadata"`, backfills `isUIEditable = false` exactly where `isUIReadOnly = true`, drops `isUIReadOnly`, and adds `isUICreatable` (default `true`) on `objectMetadata`. The `down` is the exact inverse. Uses `ADD/DROP COLUMN IF (NOT) EXISTS`, matching the 2-12 drop-`isCustom` precedent. Verified up and down in separate transactions against a dev database with exact backfill counts. - Cross-version upgrade safety (multi-version self-hosted jumps): the upgrade sequence interleaves per version (instance → workspace commands), so pre-2.13 workspace commands run before the 2.13 rename when an old instance jumps several versions. Following the `isCustom` precedent: `isUIEditable`/`isUICreatable` are marked `@WasIntroducedInUpgrade` and `isUIReadOnly` stays on both entities as `@WasRemovedInUpgrade`, so the upgrade-aware entity metadata adapter hides the not-yet-existing columns (and keeps the legacy column live) at pre-2.13 cursors. No committed upgrade command outside the 2-13 directory is modified: the old 1-21/2-8/2-9 commands keep their original `isUIReadOnly: true` inputs, which still compile (entity property retained, deprecated create-input alias mapped) and still produce the correct legacy column writes pre-rename. - A 2-13 workspace command (`sync-standard-ui-capability-flags`) re-syncs `isUICreatable` and `isUIEditable` on standard objects and `isUIEditable` on standard fields from the standard-application definitions. This backfills `isUICreatable: false` on `workflowRun`/`workflowVersion`/`workspaceMember` and heals fields created mid-cross-upgrade by pre-2.13 commands (whose hidden `isUIEditable` value cannot reach the insert). Both 2-13 sync commands pass `isSystemBuild: true` — the flat metadata validator otherwise rejects direct updates to system objects (verified against a deliberately drifted dev database; the run is idempotent). - A second 2-13 workspace command re-syncs the create-record command availability expression. ## Testing - Unit tests for `canCreateRecordsForObjectMetadataItem` (flag/permission/system combinations) and for the manifest converters (flags set / omitted → defaults). - Full `upgrade --dry-run` boots the sequence (107 steps) and validates the upgrade-aware decorator references; both 2-13 sync commands verified end to end against real drift and re-run idempotently. - Schema verified by live introspection after the input-alias restore: all four input/filter members match main, output deprecations intact; frontend metadata types and `twenty-client-sdk` schema regenerated from the running server. - Read-only-related and touched jest suites pass on both packages; typecheck and lint pass on `twenty-server` and `twenty-front`. <!-- CURSOR_AGENT_PR_BODY_END --> <div><a href="https://cursor.com/agents/bc-0f3e04cb-b04a-40be-8330-5609c4538e8a"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-web-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-web-light.png"><img alt="Open in Web" width="114" height="28" src="https://cursor.com/assets/images/open-in-web-dark.png"></picture></a> <a href="https://cursor.com/background-agent?bcId=bc-0f3e04cb-b04a-40be-8330-5609c4538e8a"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-cursor-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-cursor-light.png"><img alt="Open in Cursor" width="131" height="28" src="https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a> </div> <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21504?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com>	2026-06-13 07:10:22 +02:00
Weiko	cfb9772179	feat(server): convert view to overridable entity (#21436 ) ## Context Every entity created as a side effect of object creation must support the overridable pattern (`isActive` + `overrides` + override routing) before we can re-own side effects to their true application. Starting with View. viewField, viewFieldGroup, pageLayoutTab and pageLayoutWidget already extend `OverridableEntity`. This PR brings `view` to the same pattern. ## What this does - `ViewEntity` now extends `OverridableEntity<ViewOverrides>` (adds `isActive` boolean + `overrides` jsonb). All editable view properties are overridable; the 3 fieldMetadata foreign keys are converted to/from universal identifiers like viewField's `viewFieldGroupId`. - Update: mutations on a view not owned by the caller (e.g. standard views like "All Companies") are written into `overrides` instead of mutating the row. Reads merge overrides in the DTO. - Delete/destroy: views not owned by the caller are deactivated (`isActive = false`) instead of deleted. ~~- INDEX invariant: `key = INDEX` views can only be created via object-creation side effect. The API now rejects creating, deleting or destroying INDEX views (object-deletion cascade is unaffected). This was not really needed for this migration but was flagged during implementation.~~ - Front: views with `isActive = false` are filtered out of the views selector. - Fast instance command adds the two columns (`2-12-instance-command-fast-...-view-overridable-entity.ts`). ## Notes - Custom (caller-owned) views behave exactly as before: direct updates, soft delete. - View-group side effects (kanban groups) are computed on the override-merged view so overridden `mainGroupByFieldMetadataId` works.	2026-06-11 16:00:52 +00:00
Charles Bochet	6e147a548b	security: clear twenty-apps & seed-dependencies CVE alerts (#21410 ) Clears the Oneleet/dependency CVE alerts from the `twenty-apps` example/internal app lockfiles and the application-package `seed-dependencies` template — all via parent/direct dependency upgrades, no `resolutions` overrides. ## Lock refresh (non-breaking, within existing ranges) - postcss 8.5.8/8.5.9 → 8.5.15 — CVE-2026-41305 — postcard, hello-world, self-hosting - ip-address 10.1.0 → 10.2.0 — CVE-2026-42338 — postcard, hello-world, self-hosting, twenty-for-twenty - yaml 1.10.2 → 1.10.3 — CVE-2026-33532 — call-recording ## seed-dependencies (direct/parent bumps) - uuid `^10.0.0 → ^11.1.1` (direct) — CVE-2026-41907 - body-parser `^1.20.4 → ^1.20.5`, which pulls qs 6.15.2 — CVE-2026-8723 - socks 2.8.3 → 2.8.9 (refresh), which pulls ip-address 10.2.0 — CVE-2026-42338 ## twenty-for-twenty - resend 6.12.0 → 6.12.4 (refresh): 6.12.4 drops the `svix` dep that pulled the vulnerable uuid 10.0.0, leaving only uuid 13.0.2 — CVE-2026-41907 All flagged packages were transitive (except the direct seed-deps `uuid`); no app source changes.	2026-06-10 17:02:51 +02:00
Charles Bochet	a825dcf2cc	security: clear 8 Dependabot alerts via transitive/parent bumps (no resolutions) (#21409 ) Clears 8 Dependabot alerts via in-range transitive/parent bumps and one dead-dependency removal. No `resolutions` overrides were used — every fix is a real version bump within existing semver ranges or a parent upgrade. ### Root `yarn.lock` - react-router 6.30.3 → 6.30.4 (open redirect via protocol-relative URL) — pulled through react-router-dom, ranges unchanged — alert #1382 - yaml 2.8.1 → 2.9.0 (stack overflow on deeply nested collections) — alert #734 - uuid `^13.0.0` → 13.0.2 in twenty-sdk + create-twenty-app (buffer bounds check) — alert #1164 - ip-address `^9.0.5` dropped by bumping socks 2.8.3 → 2.8.9 (now depends on `ip-address ^10.1.1`, which is unaffected) — alert #1171 ### `seed-dependencies` lockfile - uuid `^10.0.0` → `^11.1.1` (direct dep; removed now-redundant `@types/uuid` since uuid v11 ships its own types) — alert #1287 - ip-address `^9.0.5` dropped via the same socks bump — alert #1170 ### `twenty-for-twenty` lockfile - resend bumped to 6.12.4 (`^6.12.0` range kept), which drops its `svix@1.90.0 → uuid@^10` transitive chain — alert #1278 ### `twenty-companion` - Removed the unused simplemde dependency. The note editor loads SimpleMDE from a CDN `<script>` tag and never imports the npm package; `easymde` (its maintained fork) is already a dependency — alert #690 ### Not addressed here The remaining alerts can't be closed without `resolutions` overrides (deliberately avoided in this PR) or a larger migration: - qs (#1305, #1304), lodash (#824 high / #823 / #385), ws (#1238), postcss (#1061) — vulnerable copies are pinned exact / bundled by parents (express, body-parser, @nestjs/, next, styled-components, zapier) with no in-range patch. - webpack-dev-server* (#1237/#692/#691) — pinned by `@electron-forge/plugin-webpack` (still on v4); dev-tooling only. - uuid <11.1.1 (#1289) — spread across `^3`/`^8`/`^9` transitive ranges; reaching v11 is a breaking jump. - apollo-server-core (#735/#736) — requires an Apollo Server 3 → 4 migration.	2026-06-10 17:02:18 +02:00
Félix Malfait	cf70565976	feat(twenty-server): allow shouldHideEmptyGroups in app view manifest (#21370 ) ## Context The view Hide empty groups setting (`shouldHideEmptyGroups`) can be toggled in the UI, is persisted on the `View` entity, exposed in the `CreateView`/`UpdateView` GraphQL inputs, and tracked by the flat-view sync machinery — but it could not be set from an app's view manifest. Root cause: the field postdates the manifest plumbing (added in #16385, Dec 2025). Two spots were never updated to thread it through: - `ViewManifest` didn't declare the field. - `fromViewManifestToUniversalFlatView` hardcoded `shouldHideEmptyGroups: false`. Ref: twentyhq/core-team-issues#414 ## Changes - Add optional `shouldHideEmptyGroups?: boolean` to `ViewManifest`. - Read it in the converter (`?? false`), mirroring the existing `isCompact` handling. - Cover it in the converter unit test (default + explicit value). No migration or schema change — the column already exists, and downstream sync (`FLAT_VIEW_EDITABLE_PROPERTIES` + the universal-flat compare type) already handles it. ## Test - `npx jest from-view-manifest-to-universal-flat-view` → 5 passed - `tsgo -p tsconfig.json` (twenty-server) → no new errors - oxlint + oxfmt clean	2026-06-09 14:33:58 +00:00
Weiko	9c66975520	isCustom deprecation for Objects and Fields (#21228 ) ## Context `isCustom` was a legacy denormalized boolean on `ObjectMetadataEntity` and `FieldMetadataEntity`. Now that every metadata row carries `applicationId` (via `SyncableEntity`), "is this custom" is fully derivable, and the stored boolean was a redundant second source of truth that could drift. The real meaning of `isCustom` is "the owning application is not the twenty-standard application" — i.e. `!belongsToTwentyStandardApp`. Note this is not "belongs to the workspace custom app" as I initially thought: third-party-application objects/fields are custom too. The standard application has a globally stable `universalIdentifier`, so the value derives with no per-workspace lookup. ## Changed ## `isCustom` checks — before → after `isCustom` is no longer a stored column. The table below lists every site that branched on it and how it resolves now. The unifying rule: `isCustom ≡ !isTwentyStandardApplicationUniversalIdentifier(applicationUniversalIdentifier)`. ### Server — behavioural checks \| Location \| Purpose \| Before \| Now \| \|---\|---\|---\|---\| \| `utils/compute-object-target-table.util.ts` \| Physical table name `_` prefix \| `computeTableName(nameSingular, objectMetadata.isCustom)` \| derives from `applicationUniversalIdentifier` (single source for all table-name callers) \| \| `twenty-orm/factories/entity-schema.factory.ts` + `…/entity-schema-metadata.type.ts` \| ORM table name (hot path) \| `object.isCustom` \| `object.applicationId !== standardApplicationId` (computed in `buildEntitySchemaMetadataMaps`) \| \| `twenty-orm/repository/workspace-{delete,soft-delete,update}-query-builder.ts` \| Table name for mutations \| `computeTableName(nameSingular, objectMetadata.isCustom)` \| `computeObjectTargetTable(objectMetadata)` \| \| `index-metadata/utils/generate-deterministic-index-name-v2.ts` \| Index name hash (must stay bit-identical) \| `flatObjectMetadata.isCustom` \| derives from `applicationUniversalIdentifier` \| \| `object-metadata/object-record-count.service.ts` \| Table name for record count \| `computeTableName(nameSingular, isCustom)` \| `computeObjectTargetTable(flatObjectMetadata)` \| \| `workspace-manager/dev-seeder/data/services/dev-seeder-data.service.ts` \| Match seed config by table name \| `computeTableName(item.nameSingular, item.isCustom)` \| `computeObjectTargetTable(item)` \| \| `commands/workspace-export/workspace-export.service.ts` + `…/utils/generate-workspace-schema-ddl.util.ts` \| Export table name (raw entity) \| `objectMetadata.isCustom` \| `!isTwentyStandard…(objectMetadata.application?.universalIdentifier)` \| \| `flat-field-metadata/services/flat-field-metadata-type-validator.service.ts` \| Block users creating reserved field types \| `args.flatEntityToValidate.isCustom` \| `!args.flatEntityToValidate.isSystem` \| \| `api/common/.../common-create-many-query-runner.service.ts` \| Don't let client overwrite system `createdBy` \| `createdByFieldMetadata.isCustom === false` \| `createdByFieldMetadata.isSystem === true` \| \| `field-metadata/utils/resolve-field-metadata-standard-override.util.ts` \| Skip i18n/overrides for custom fields \| `if (fieldMetadata.isCustom) return raw` \| removed — falls through on `isDefined(standardOverrides)` \| \| `object-metadata/utils/resolve-object-metadata-standard-override.util.ts` \| Skip i18n/overrides for custom objects \| `if (objectMetadata.isCustom) return raw` \| removed — same fall-through \| \| `command-menu-item/utils/build-navigation-interpolation-context.util.ts` \| Override context for nav labels \| passed `isCustom` into resolver \| dropped (resolver no longer needs it) \| \| `api/common/.../data-arg-processor.service.ts` \| `isCustom` for record-position table name \| `flatObjectMetadata.isCustom` \| derives from `applicationUniversalIdentifier` \| \| `metadata-modules/minimal-metadata/minimal-metadata.service.ts` \| Minimal DTO + override context \| `flatObjectMetadata.isCustom` \| derives from `applicationUniversalIdentifier` \| \| `commands/upgrade-version-command/1-23/…backfill-record-page-layouts.command.ts` \| Filter to custom objects \| `objectMetadata.isCustom` \| `!isTwentyStandard…(applicationUniversalIdentifier)` \| ### Server — DTO / API population \| Location \| Before \| Now \| \|---\|---\|---\| \| `flat-object-metadata/utils/from-flat-object-metadata-to-object-metadata-dto.util.ts` \| passthrough `isCustom` \| derives from `applicationUniversalIdentifier` \| \| `flat-field-metadata/utils/from-flat-field-metadata-to-field-metadata-dto.util.ts` \| passthrough `isCustom` \| derives from `applicationUniversalIdentifier` \| \| `object-metadata/utils/from-object-metadata-entity-to-object-metadata-dto.util.ts` (REST) \| `entity.isCustom` \| `entity.applicationId !== standardApplicationId` \| \| `field-metadata/utils/from-field-metadata-entity-to-field-metadata-dto.util.ts` (REST) \| `entity.isCustom` \| `entity.applicationId !== standardApplicationId` \| \| `dataloaders/dataloader.service.ts` \| passed `flatFieldMetadata.isCustom` into override resolver \| dropped (resolver no longer needs it) \| > REST controllers (`object-metadata.controller.ts`, `field-metadata.controller.ts`) resolve `standardApplicationId` once per request from the cached `flatApplicationMaps`. ### Frontend \| Location \| Purpose \| Before \| Now \| \|---\|---\|---\|---\| \| `settings/.../SettingsObjectFieldDisabledActionDropdown.tsx` \| Whether an inactive field is deletable \| `isDeletable = isCustomField` \| `isDeletable = isCustomField && !isSystemField` \| ### Unchanged (out of scope) `isCustom` on `IndexMetadata` / `View` / `Skill` / `Agent` and their guards still read the persisted column. Breaking change is on the isCustom filter on field and object APIs, this is never used in the FE and unlikely used by external consumers	2026-06-09 13:57:19 +00:00
Charles Bochet	fcaf2b4d9b	chore(twenty-server): temporary instrumentation for app-install 504 (#21365 ) ## Why App installs on cloud intermittently fail with a 504, surfacing in Sentry as `Migration action 'update' for 'logicFunction' failed` + `Failed to rollback transaction: Query runner already released`. This is temporary instrumentation to pin down where the time goes — to be reverted once the bottleneck is fixed. Everything is greppable via `[install-perf]` and marked `// TODO(install-perf)`. ## What the local repro already told us I instrumented the manifest-sync/migration path and ran a local harness (new skipped spec) installing 1 / 8 / 30 logic functions, for both create and the checksum-bump update (the incident path): \| stage (N=30, update) \| ms \| \|---\|---\| \| flat-maps recompute \| ~1 \| \| build migration \| ~11 \| \| transaction (all actions + commit) \| ~79 \| \| post-commit cache invalidate \| ~6 \| \| full sync \| ~135 \| Nothing approached 1s, let alone 10s; no slow queries logged. So the migration/cache code is not the algorithmic cause. Given the in-transaction `UPDATE ... WHERE id=?` is intrinsically fast, a >10s in prod almost certainly means it was blocked on a lock, and the 10s node-pg `query_timeout` (`core.datasource.ts`) then killed the connection → the observed errors + 504. Local can't reproduce prod lock contention / table sizes, hence this instrumentation. ## What this adds (all `TODO`-marked) - hrtime per-stage timing — flat-maps recompute, build vs run, per-action (`>50ms`), transaction summary, post-commit cache invalidation. Uses `process.hrtime` because the integration harness enables fake timers (so `Date.now()` is useless there). - `maxQueryExecutionTime` slow-query logging on the core datasource (logs the offending SQL). - Scoped `SET LOCAL lock_timeout = '8s'` on the migration transaction (below the 10s `query_timeout`) → a blocked action fails fast with a clear "canceling statement due to lock timeout" instead of the opaque connection kill. - Best-effort `pg_stat_activity` snapshot on failure (on a fresh pooled connection) to identify the blocking session, plus a guarded rollback so a released connection stops masking the real error. - Skipped local perf harness (`logic-function-install-performance.integration-spec.ts`) — run manually with `nx test:integration:with-db-reset -- --testPathPattern "logic-function-install-performance"`. ## How we'll use it Deploy, reproduce the failing install, and read the `[install-perf]` logs: the per-action timing names the action, the `lock_timeout` message + `pg_stat_activity` snapshot name the blocking query/PID. Then revert this PR and fix the actual contention. Typecheck (`nx typecheck twenty-server`) is clean.	2026-06-09 15:57:25 +02:00
martmull	77d1e8ced6	feat(app-dev): sync error hints, flatEntity labels, dev-mode summary UI, and docs (#21252 ) Split out of #21240 — all remaining app-dev improvements. Stacked on #21251 (review/merge that first). - Actionable recovery hints on failed syncs; unified diff renderer; `--dry-run` guard. - Return `flatEntity` on update/delete sync actions and unify the diff label. - Summarize the dev-mode entity list unless `--verbose`. - Docs: syncing & recovery guide + dry-run + open-an-issue prompt. - Live execution mode for synced logic functions; clearer manifest warnings. <img width="1018" height="700" alt="image" src="https://github.com/user-attachments/assets/5e9ce19e-0f1d-4f99-8524-4e118bde932b" />	2026-06-08 15:43:28 +00:00
Charles Bochet	45ceb5d74c	security: bump vulnerable deps in logic-function runtime lockfiles (#21317 ) ## What Two standalone dep-set lockfiles bundled for the logic-function / application-package sandbox carried vulnerable transitive versions. Within-range bumps only (these dep sets are handed to user logic functions, so no breaking majors): `seed-dependencies` - `nodemailer` `^8.0.4 → ^8.0.5` (resolves 8.0.10) — SMTP CRLF command injection (direct dep) - `brace-expansion`, `picomatch`, `lodash` → patched `common-layer-dependencies` - `lodash`, `brace-expansion` → patched ## Left for follow-up (can't be fixed within-range) - `qs` — pinned transitively by `body-parser`, stays at 6.14.2 (needs body-parser bump) - `ip-address` 9.x → 10.x and `uuid` 10.x → 11.x — major bumps; left out since these are exposed to user functions and would be breaking `axios` here is already on the patched `^1.16.1`.	2026-06-08 16:45:05 +02:00
martmull	6c65d26ced	feat(app-dev): add dry-run preview to dev sync (#21251 ) Split out of #21240. Stacked on #21250 (review/merge that first). `yarn twenty dev --once --dry-run` computes the migration plan and prints the diff without applying anything (no migration, no app-record update, no SDK generation). Also renders the diff on a normal `dev --once` sync. <img width="646" height="179" alt="image" src="https://github.com/user-attachments/assets/59f3ddcd-2a5b-4b8a-b21a-c659abe16af0" />	2026-06-05 17:49:02 +00:00
neo773	bfb83e93b2	fix(metadata): resolve junction targets order-independently during mgration (#21193 ) A junction relation points at a target field on the join object that another action may create later (two junctions into the same join reference each other). The builder validator now also looks up the target in the to be created set, and the runner mints every field id up front so the target resolves regardless of action order, the same way relation pairs are already handled. --------- Co-authored-by: Félix Malfait <felix@twenty.com>	2026-06-05 17:32:25 +00:00
martmull	84ba7eb8dc	fix(app-dev): serialize dev sync per workspace with a cache lock (#21250 ) Split out of #21240. Stacked on #21249 (review/merge that first). Concurrent `syncApplication` calls on the same workspace could interleave their metadata migrations and leave metadata partially applied. Wrap the manifest sync in a per-workspace cache lock (`app-sync:<workspaceId>`), mirroring the install path. The rate-limit throttle stays outside the lock. --------- Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-05 17:30:55 +02:00
martmull	f20d04eb6e	feat(app-dev): surface metadata diff in dev sync and name failing migration actions (#21249 ) Split out of #21240. - Render the applied metadata changes (created/updated/deleted + identifiers) in the dev sync output instead of a bare `✓ Synced`. - Include the failing entity's `universalIdentifier` in `WorkspaceMigrationRunnerException` messages so conflicts are diagnosable. <img width="637" height="114" alt="image" src="https://github.com/user-attachments/assets/61422a16-370c-4e9b-a2f6-c29ce17f3b1b" /> <img width="497" height="104" alt="image" src="https://github.com/user-attachments/assets/d493c398-da29-49c9-ac5e-aa0f26cd7389" /> <img width="593" height="127" alt="image" src="https://github.com/user-attachments/assets/15e26edc-c0e4-4427-bd34-909040e970c9" /> --------- Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-05 16:35:50 +02:00
Félix Malfait	c3dd6b25a6	fix: use canonical oxlint rule id in lint-disable directives (#21253 ) ## What Many `oxlint-disable` / `eslint-disable` directives across the repo carry a corrupted rule id — `@typescripttypescript/<rule>` — most likely a find-and-replace accident that mangled the eslint-era `@typescript-eslint/` prefix. oxlint matches disable directives loosely by rule name, so these still suppress in practice (not a silent no-op), but the id is malformed and misleading. ## Change Replace them with the canonical oxlint id `typescript/<rule>` — matching the plugin name and rule keys declared in `.oxlintrc.json` — 127 files, 262 directives: \| rule \| count \| \| --- \| ----- \| \| `typescript/no-explicit-any` \| 250 \| \| `typescript/ban-ts-comment` \| 6 \| \| `typescript/no-misused-promises` \| 4 \| \| `typescript/no-empty-object-type` \| 2 \| - `twenty-server`: 122 files - `twenty-front`: 5 files Comment-only — no code or runtime changes. ## Verification `oxlint --type-aware -c .oxlintrc.json` reports 0 warnings / 0 errors for both `twenty-server` and `twenty-front`. Every changed line is exactly the id correction inside a disable directive (262 insertions / 262 deletions, no collateral edits). > Addresses the cubic review, which flagged that the canonical oxlint id is `typescript/...` (no `@`). Worth noting the original `@typescripttypescript/` was not actually a silent no-op — oxlint matches these directives loosely by rule name — but `typescript/` is the correct, config-aligned id.	2026-06-05 13:52:32 +02:00
martmull	128d2d394d	feat: allow apps to add view fields to existing views (defineViewField) (#21160 ) ## Summary Lets a Twenty application add view fields (columns) to an existing view it does not own — including standard views like the People index view — without redeclaring/owning that view. This mirrors the existing, working pattern by which an app adds a custom field to a standard object via `defineField` + `objectUniversalIdentifier`. The asymmetry being removed was purely in the manifest schema: `ViewFieldManifest` only existed nested inside `ViewManifest.fields[]`, so adding a view field forced declaring a `ViewManifest` — which the sync treats as a view the app creates and owns, and rejects when the UID is a standard view's. Validation, persistence, the FK aggregator machinery, and uninstall cleanup were already generic and cross-app-safe, so no engine changes were needed. ### Changes - twenty-shared: new top-level `StandaloneViewFieldManifest` (`ViewFieldManifest & { viewUniversalIdentifier }`), `Manifest.viewFields`, and a `SyncableEntity.ViewField` member. - twenty-sdk: `defineViewField` (validates `universalIdentifier` + `viewUniversalIdentifier` + `fieldMetadataUniversalIdentifier`), CLI manifest assembly of a top-level `viewFields` list, and `dev:add viewField` scaffolding. - twenty-server: one top-level loop over `manifest.viewFields` that reuses the existing `fromViewFieldManifestToUniversalFlatViewField` converter (already parameterized by `viewUniversalIdentifier`). No validator/persistence/aggregator changes. ### Notes for maintainers - Confirm the `Manifest.viewFields` optionality convention — implemented as a required array to mirror `fields`/`views`. - Two different apps adding a column for the same field to the same view conflicts on the existing unique `(fieldMetadataId, viewId)` partial index; the existing `flat-view-field-validator` duplicate check surfaces this as a structured validation error. - `dev:add viewField` scaffolding is included (was optional in the plan). ## Test Plan - [x] `twenty-shared` typecheck - [x] `twenty-sdk` 364 unit tests + `buildManifest` assembly test (rich-app fixture) + typecheck + prettier - [x] `twenty-server` typecheck + `lint:diff-with-main` - [x] Server integration suite `successful-manifest-update-view-field.integration-spec.ts` (4/4): - standalone view field attaches to the standard `allPeople` view without recreating it (sync succeeds, no `INVALID_VIEW_DATA`/`ENTITY_ALREADY_EXISTS`) - uninstall removes the contributed column while the standard view + its columns remain intact - duplicate `(view, field)` rejected with `METADATA_VALIDATION_FAILED` - unknown target view rejected - [x] Sibling `successful-manifest-update-field.integration-spec.ts` still green (no harness regression) 🤖 Generated with [Claude Code](https://claude.com/claude-code)	2026-06-05 08:06:30 +00:00
Paul Rastoin	0877ba2ffd	Fix `getApplicationSubAllFlatEntityMaps` to prune unrelated appIds universal identifier aggregators (#21234 ) # Introduction Atm when computing the `fromAllFlatEntityMaps` we're retrieving all the applicationIds related metadata entities to build a flat entity maps scoped to them ( atm always the applicationId + twenty-standard application id ) only inter app dependency we manage for the moment A flat entity contains universal identifier aggregator to its related entities The issue was that the `getApplicationSubAllFlatEntityMaps` wasn't pruning the aggregator by app Now added a new process phase after the initial one that will check that all the aggregators contains universal identifiers that has been retrieve from the appId + appId standard intersection ## TDD test Created a very human readable ( that's a joke ) test	2026-06-04 16:53:25 +00:00
martmull	c2ca90c255	feat(sdk): add runAgent() to run app agents from logic functions (#21157 ) <img width="948" height="593" alt="image" src="https://github.com/user-attachments/assets/d990fa98-3cfd-469d-ab7f-0b2d4ccf3afc" /> <img width="1361" height="802" alt="image" src="https://github.com/user-attachments/assets/1091f598-49f3-4c16-92ea-1e1c200181e2" /> ## Add `runAgent()` to the Logic Function SDK Lets an app's logic function run one of its own AI agents server-side and get the result back synchronously — reusing the existing agent executor instead of a new bespoke transport. ### Backend - New `runAgent` GraphQL mutation (metadata schema) in `ai-agent-execution`, wrapping the existing `AgentAsyncExecutorService.executeAgent`. Scopes the agent lookup to the calling application and runs it under an application auth context. - New `@AuthApplication()` param decorator (mirrors `@AuthWorkspace()`) — first GraphQL resolver authenticated by an application access token. - Guarded by `WorkspaceAuthGuard` + `SettingsPermissionGuard(PermissionFlagType.AI)`: the app's role must grant the `AI` permission flag. ### SDK - `runAgent({ agentUniversalIdentifier, prompt })` posts the mutation to `/metadata` with the app token via a new runtime GraphQL transport. Returns `{ result, hasNoMoreAvailableCredits }`. - Refactored the connections helpers onto a shared `postAppEndpoint` util (removes duplicated transport logic). ### Frontend - App install permission modal now shows an explicit consent line — _"Run AI agents and bill AI credits to your workspace"_ — when the app's role requests the `AI` flag. ### Docs - Documented `runAgent` and its `AI` permission-flag requirement in _Skills & Agents_. - Fixed outdated role-permission examples in _Roles & Permissions_ (`permissionFlags` → `permissionFlagUniversalIdentifiers`, `PermissionFlag` → `SystemPermissionFlag`). ### Test plan - [x] SDK unit tests (`run-agent.spec.ts`) — request shape, GraphQL/HTTP error handling, missing env vars - [x] `twenty-server`, `twenty-front`, `twenty-shared` typecheck + lint - [ ] Manual: install an app granting the `AI` flag, call `runAgent()` from a logic function, confirm the agent runs and credits are billed --------- Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>	2026-06-04 16:18:27 +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
Abdullah.	50c9b68e81	Update axios in package.json of seed-dependencies (#21190 ) Fixes the following Dependabot alerts: https://github.com/twentyhq/twenty/security/dependabot?q=is%3Aopen+package%3Aaxios+manifest%3Apackages%2Ftwenty-server%2Fsrc%2Fengine%2Fcore-modules%2Fapplication%2Fapplication-package%2Fconstants%2Fseed-dependencies%2Fyarn.lock+has%3Apatch Follow up to the alerts not addressed in [this](https://github.com/twentyhq/twenty/pull/21187) PR.	2026-06-03 17:49:02 +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
Félix Malfait	b338a7a1d2	feat(settings): discovery hero rollout + ephemeral playground token (#21072 ) ## Summary Two intertwined streams of work: ### UI — discovery hero pattern, settings shell, AI/API redesign - Generalize `SettingsDiscoveryHeroCard` and use it on Layout, Data Model, Apps, AI, API/Webhooks, Members. Drops 4 per-page wrapper files (`SettingsObjectCoverImage`, `SettingsLayoutCoverImage`, `SettingsLayoutCustomizeVideoModal`, `SettingsDataModelVisualizeVideoModal`). Each page now supplies cover src, modal id, and tab list. - Modal: swap `<video>` placeholder for the Vimeo iframe pattern from `twenty-docs`, per-tab `vimeoId`. Drop the parallel border-bottom on the header (TabList draws its own baseline) and the grey background behind the video. Note: Vimeo's embed allowlist applies — the iframes load with the correct URL on `localhost` but the player itself requires the video owner to allow the dev/staging domains in Vimeo settings. - AI page rebuilt into a Cockpit pattern (Overview / Models / Skills / Tools / Usage). New `SettingsAiOverviewTab` with default Smart/Fast pickers, at-a-glance stats, and an MCP signpost that deep-links to `/settings/api-webhooks#mcp`. System Prompt link moved under Models. Advanced tab removed. - API & Webhooks now has 4 tabs (Playground / MCP / API Keys / Webhooks). Hero card above tabs. Playground tab inverted to "Core API" / "Metadata API" sections, each containing REST + GraphQL cards — schema is the meaningful axis, protocol is secondary. Hash deep-link sync delegated to the shared `TabListFromUrlOptionalEffect`. - Settings shell: unified drawer outer padding (kill `isSettings` branch), extract `CollapsibleNavigationDrawerSection`, add `iconColor` on settings nav items, fix Exit Settings button alignment, 880px content cap. ### Backend — strategy C: ephemeral playground token The legacy paste-your-API-key flow is replaced by an on-demand short-lived token scoped to the calling user's permissions. No shared "Playground" API key to manage or revoke. - New `JwtTokenTypeEnum.PLAYGROUND`. `PlaygroundTokenJwtPayload = Omit<AccessTokenJwtPayload, 'type' \| impersonation fields>` so any future ACCESS claim flows through automatically. - `AccessTokenService.generatePlaygroundToken` signs an access-shaped JWT with `type: PLAYGROUND` and a configurable short TTL. A shared private `resolveTokenSubject` helper parallelizes the user / workspace / userWorkspace lookups for both generators. - `JwtAuthStrategy.validateAccessToken` widened to accept `AccessTokenJwtPayload \| PlaygroundTokenJwtPayload`; impersonation gated on `payload.type === ACCESS` so the union narrows without `as unknown as` casts. The two branches in `validate()` collapse into one. - New `PLAYGROUND_TOKEN_EXPIRES_IN` config var (default `2h`). - New `generatePlaygroundToken` mutation (`WorkspaceAuthGuard`, no args, returns `AuthToken`). - Frontend `useOpenPlayground` hook centralizes mint → atom write → navigate, with Apollo `onError` snackbar and a "use cached PLAYGROUND token if still fresh" short-circuit (decodes via `jwt-decode`, checks both `type` AND `exp`). Old API_KEY tokens left in localStorage from the prior paste-form flow are rejected on `type` alone and force a re-mint — this is what was causing the "This API Key is revoked" symptom on stale browsers. ### Drive-by cleanups - `PlaygroundToken` DTO removed (identical shape to `AuthToken` already in use). - 5 `customize-sidebar.webm` imports and the dead placeholder pipeline removed. ## Test plan ### Discovery hero - [ ] `/settings/layout`, `/settings/data-model`, `/settings/applications`, `/settings/ai`, `/settings/api-webhooks`, `/settings/members` each render the discovery hero card with its illustration + play button + tabbed modal - [ ] Modal tabs show the correct Vimeo embed URL per tab; aspect ratio stays at 1440/900; no parallel border-bottom jog at the tab baseline - [ ] AI Overview tab shows Smart/Fast model pickers + stats grid + MCP signpost card; the MCP card lands on `/settings/api-webhooks#mcp` with the MCP tab active ### API playground (ephemeral token) - [ ] With an empty `playgroundApiKeyState` in localStorage, clicking REST or GraphQL playground card opens the playground and the cached token has `type: "PLAYGROUND"` with ~2h exp - [ ] Clicking the card again within the freshness window does not re-mint (`iat` / fingerprint stable across visits) - [ ] Planting a fake API_KEY-shaped JWT in localStorage and clicking the card forces a fresh mint (old token rejected on `type`) - [ ] `GET /rest/companies?limit=1` with the cached token returns 200 + real data - [ ] `POST /graphql { __typename }` returns 200 ### Settings shell - [ ] Settings nav matches main app drawer padding; sections collapse; Exit Settings button aligns with the workspace links above - [ ] Active nav items have a right-gap (cleaner active state) - [ ] Content area capped at 880px ### Verify - [ ] `npx nx typecheck twenty-front` passes - [ ] `npx nx typecheck twenty-server` passes - [ ] `npx nx lint:diff-with-main twenty-front` passes - [ ] `npx nx lint:diff-with-main twenty-server` passes	2026-06-01 14:16:02 +02:00
martmull	c2df39405c	Fix admin pannel server variable config tab (#21017 ) ## Before <img width="1046" height="490" alt="image" src="https://github.com/user-attachments/assets/450557de-fcf5-4b51-afdb-36c0c36e43d8" /> ## After <img width="1040" height="414" alt="image" src="https://github.com/user-attachments/assets/4a5fe2ab-85d6-4431-9397-6f81ae24055d" />	2026-05-29 09:55:11 +00:00
Félix Malfait	f4ead89956	refactor(twenty-orm): migrate 23 grandfathered entities to WorkspaceScopedRepository (#20987 ) ## Summary Follow-up to #20953. Migrates 23 of the 30 entities that were left in `WORKSPACE_SCOPED_EXEMPTIONS` last time, so the lint rule's workspaceId-enforcement default now covers most of the core/metadata schema. ### Migrated (23 entities, 88 files, 22 commits) \| Family \| Entities \| \|---\|---\| \| Trivial caches \| `NavigationMenuItem`, `Skill`, `DataSource`, `Webhook`, `CommandMenuItem`, `IndexMetadata` \| \| Views \| `View`, `ViewField`, `ViewFieldGroup`, `ViewFilter`, `ViewFilterGroup`, `ViewGroup`, `ViewSort` \| \| Layouts \| `PageLayout`, `PageLayoutTab`, `PageLayoutWidget` \| \| Roles & permissions \| `Role`, `RoleTarget`, `PermissionFlag`, `ObjectPermission`, `FieldPermission`, `RowLevelPermissionPredicate`, `RowLevelPermissionPredicateGroup` \| For each entity: swap `@InjectRepository(X)` → `@InjectWorkspaceScopedRepository(X)` (and the field type → `WorkspaceScopedRepository<X>`); rewrite every call site to pass `workspaceId` as the first arg (stripped from `where`/criteria — the wrapper throws if you include it now); register `provideWorkspaceScopedRepository(X)` in every owning NestJS module; update affected spec providers to `getWorkspaceScopedRepositoryToken(X)`. ### Rule update - `ApplicationRegistrationVariableEntity` was misclassified — moved to `STRUCTURAL_EXEMPTIONS` (no `workspaceId` column; it's keyed on `applicationRegistrationId` at the instance level). - 22 of the 23 migrated entities removed from `WORKSPACE_SCOPED_EXEMPTIONS` entirely (zero remaining raw `@InjectRepository` sites). - `RoleTargetEntity` also removed; one call site in `user-workspace.service.ts` keeps a raw injection with an `eslint-disable` + reason because `softRemove(...)` is not on the wrapper API yet (the migration would require threading `workspaceId` through `deleteUserWorkspace`'s three callers). ### Still exempted (7 entities, follow-up PRs) \| Entity \| Why deferred \| \|---\|---\| \| `ApplicationEntity` \| ~50 sites with several cross-workspace lookups by id (auth, OAuth, file-storage, cleanup) \| \| `CalendarChannelEntity` / `MessageChannelEntity` \| Use `.increment(...)` (not on wrapper) and `repository.manager.transaction(...)` — wrapper needs to grow `.increment` + the transaction sites need `withManager` or dual-inject \| \| `FieldMetadataEntity` / `ObjectMetadataEntity` \| The metadata services `extends TypeOrmQueryService<X>` and `super(rawRepo)` — requires dual-inject or reworking the inheritance \| \| `KeyValuePairEntity` \| Allows `workspaceId: IsNull()` for instance-level config; wrapper rejects null \| \| `UpgradeMigrationEntity` \| Same — instance-level + cross-workspace ledger \| ## Test plan - [x] `npx nx typecheck twenty-server` — clean - [x] `npx nx lint twenty-server` — clean (0/0) - [x] All 10 affected unit specs pass (115 tests) — api-key, agent-role, permissions, workspace-roles-permissions-cache, view-filter-group, workflow-version-step-operations, two-factor-authentication (service + resolver), user-workspace, file - [ ] Server integration tests in CI	2026-05-28 20:46:21 +02:00
Paul Rastoin	ebfaca5b3d	`EncryptedString` `PlaintextString` branded string types (#21001 ) ## Summary closes https://github.com/twentyhq/core-team-issues/issues/2464 Introduces compile-time branded types to distinguish encrypted ciphertext from plaintext strings, preventing mix-ups like the one fixed in #20819 — but at the type level rather in addition to the one existing at runtime. ### Branded string primitives - Created `EncryptedString` and `PlaintextString` as hard nominal brands using `z.string().brand(...)`, making them non-assignable to each other or to raw `string` - Created `isEncryptedString` type predicate to narrow `string` to `EncryptedString` based on the `enc:v2:` envelope prefix - Retyped `SecretEncryptionService`: `encryptVersioned` accepts `PlaintextString`, `decryptVersioned` returns `PlaintextString` ### Entity typing - Typed encrypted columns across entities: `SigningKeyEntity.privateKey`, `TwoFactorAuthenticationMethodEntity.secret`, `ApplicationRegistrationVariableEntity.encryptedValue`, `ApplicationVariableEntity.value` - Parameterized JSONB types for connected account connection parameters (`ImapSmtpCaldavParams<Pwd>`) with reusable aliases `EncryptedImapSmtpCaldavParams` / `DecryptedImapSmtpCaldavParams` - Typed DTOs (`CreateApplicationRegistrationVariableInput`, `UpdateApplicationRegistrationVariablePayload`, `UpdateApplicationVariableEntityInput`) with `PlaintextString` ### ApplicationVariable always-encrypt uniformization - Retyped `ApplicationVariableEntity.value` to `EncryptedString \| ''` — all values are now encrypted regardless of `isSecret` - Updated `ApplicationVariableEntityService` to always encrypt on write and always decrypt on read - Simplified `UpdateApplicationVariableActionHandlerService` by removing conditional encrypt/decrypt-on-isSecret-toggle logic - Added slow instance command (`2.9.0`) to backfill-encrypt existing `isSecret=false` plaintext rows and tighten the `CHECK` constraint ### ConfigStorageService refactor - Split `convertAndSecureValue` (which used `any`) into two well-typed methods: `convertAndDecrypt` and `convertAndEncrypt` - Introduced `isSensitiveStringValue` type predicate to narrow values before encryption/decryption ### What's next - Typeorm entity derivation to strictly type sitemap configuration as code + handler logic for encryption rotation - https://github.com/twentyhq/core-team-issues/issues/2465	2026-05-28 17:41:16 +02:00
Félix Malfait	4797d2f270	feat(twenty-orm): introduce WorkspaceScopedRepository for core/metadata workspace-scoped entities (#20953 ) ## Summary Adds a third tenancy enforcement layer for entities that live in shared schemas (`core`, `metadata`) and carry a `workspaceId` column — previously the only safeguard at this layer was developer discipline (remembering to put `workspaceId` in every WHERE clause). ### The three layers, after this PR \| Layer \| Scope \| How it's enforced \| \|---\|---\|---\| \| 1. Workspace data \| per-workspace schema (companies, people, custom objects) \| `twentyORMManager.getRepository(workspace, E)` — physical isolation (own data source) \| \| 2. Metadata \| shared `metadata` schema (objectMetadata, fieldMetadata, views, roles…) \| Flat-entity-maps cache — workspace-scoped in-memory map, lookups by id within it \| \| 3. Core (new) \| shared `core` schema (agent threads/turns/messages, app tokens, etc.) \| `WorkspaceScopedRepository<T>` — `workspaceId` is a required positional argument on every read/write \| ## What's in the PR ### The wrapper (`packages/twenty-server/src/engine/twenty-orm/workspace-scoped-repository/`) - `WorkspaceScopedRepository<T extends WorkspaceScopedEntity>` — wraps a TypeORM `Repository<T>`, requires `workspaceId` on every `find`/`findOne`/`findOneOrFail`/`update`/`delete`/`softDelete`/`insert`/`save`/`count` call, merging it into the WHERE or stamping it on the entity. `createQueryBuilder` is an explicit escape hatch (caller scopes manually). - Provided via Nest DI with `@InjectWorkspaceScopedRepository(EntityClass)` and the `provideWorkspaceScopedRepository(EntityClass)` provider factory. - 19 unit tests cover the merge behavior, override-on-conflict, and the array-where (OR) case. ### Lint enforcement (`packages/twenty-oxlint-rules/rules/prefer-workspace-scoped-repository.ts`) - New `twenty/prefer-workspace-scoped-repository` rule (level: error). - Blacklist of entity names: raw `@InjectRepository(E)` is rejected if `E` is on the list. - Initial list: `AgentTurnEntity`, `AgentMessageEntity`, `AgentMessagePartEntity`, `AgentChatThreadEntity`, `AgentTurnEvaluationEntity`, `AgentEntity`. - Designed to grow over time as more consumers are migrated. - 5 rule tests. ### Migration in this PR All consumers of the six blacklisted entities, including: - AI agent / chat / monitor resolvers, services, and jobs - `AgentService`, `AiAgentRoleService`, `AiAgentWorkflowAction`, `ApplicationService`, `WorkspaceFlatAgentMapCacheService` - Admin-panel chat (migrated where the lookup is workspace-known; one documented `eslint-disable` on the threadId-discovery lookup that necessarily precedes the `allowImpersonation` permission check) - `AiAgentRoleService` unit spec updated to mock the scoped wrapper ## Future work (deliberately not in this PR) A standalone audit identified ~14 additional `core`/`metadata` entities with `workspaceId` that currently use raw `@InjectRepository` and could be added to the blacklist. Notable candidates: `UserWorkspaceEntity` (42 sites), `AppTokenEntity` (10), `FileEntity` (7), `BillingCustomerEntity`/`BillingSubscriptionEntity` (~22 combined). Each should be its own PR — the migration is mechanical but the surface is wide. ## Test plan - [x] `npx nx typecheck twenty-server` — clean - [x] `npx nx lint twenty-server` — 0 warnings, 0 errors - [x] `npx jest workspace-scoped-repository` — 19/19 pass - [x] `npx nx test twenty-oxlint-rules` — 215/215 pass - [x] `npx jest src/engine/metadata-modules/ai` — 44/44 pass - [ ] Manual smoke: end-to-end AI agent chat send/receive (reviewer) - [ ] Manual smoke: AI agent monitor — list turns, run evaluation (reviewer) - [ ] Manual smoke: admin-panel chat thread inspection (reviewer)	2026-05-27 18:52:53 +02:00

1 2 3 4 5 ...

283 Commits