980 Commits

Author	SHA1	Message	Date
Raphaël Bosi	41d5d80a65	Migrate Company and Person standard fields in preparation for the enrichment app (#21171) ... # Migrate Company and Person standard fields in preparation for the enrichment app ## Why Our standard `Person`/`Company` objects accumulated fields that aren't generic to every business, while missing a more universal revenue field that essentially every CRM ships. This PR makes the **Standard application** hold a tighter, more universal set of fields, and sets the stage for a follow-up PR that introduces a **People Data Labs enrichment app** to populate them. ## What changes ### Standard fields **Demoted (Standard → Workspace Custom application)** — not generic enough to ship as standard: | Object | Field | Type | | ------- | ------------------------------ | -------- | | Company | annualRecurringRevenue (ARR) | CURRENCY | | Company | employees | NUMBER | | Company | idealCustomerProfile (ICP) | BOOLEAN | | Company | xLink (X/Twitter) | LINKS | | Person | xLink (X/Twitter) | LINKS | | Person | city | TEXT | **Added (new generic Standard field)** — present in Salesforce/HubSpot/Zoho, PDL-populatable: | Object | Field | Type | | ------- | ------------- | -------------------------------------------------------- | | Company | annualRevenue | CURRENCY (generic total revenue; replaces the niche ARR) | ### Behavior by workspace * **New workspaces:** demoted fields are gone; `annualRevenue` is **active**. * **Existing workspaces:** demoted fields are **preserved as active custom fields, data intact**; `annualRevenue` is created **inactive (opt-in)** with its column ready, so a later activation is a metadata-only toggle. ### Upgrade commands (v2.9) Three idempotent, per-workspace commands, run in timestamp order: 1. **`upgrade:2-9:move-demoted-standard-fields-to-custom-application`** (1799000040000) — re-owns the 6 demoted fields to the workspace custom application (`isCustom = true`, new `applicationId` + fresh `universalIdentifier`), keeping their data and active state. 2. **`upgrade:2-9:rename-conflicting-custom-fields`** (1799000045000) — if a workspace already has a *custom* field named `annualRevenue`, renames it to `annualRevenueCustom` (data preserved via column rename) so the standard field can be added. Skips non-custom matches. 3. **`upgrade:2-9:add-inactive-generic-standard-fields`** (1799000050000) — creates `Company.annualRevenue` on existing workspaces as inactive, guarded to skip workspaces missing the target object or where the name is still taken. **Failure model:** the workspace iterator isolates failures per workspace (one workspace failing never affects others); within a workspace the runner records per-command status and resumes on the next run, and every command is idempotent, so partial runs self-heal. ### Supporting changes * **Field-option color palette:** widened the `TagColor` union (`twenty-shared` `FieldMetadataOptions` + the field-metadata `options.input` DTO) from 10 colors to the full theme palette, benefiting any future SELECT/MULTI_SELECT field. * **Dev seeder:** * The default "Annual Recurring Revenue" dashboard widget now points at the generic `annualRevenue` field (renamed to "Annual Revenue"). * Removed the "Companies by Size (Stacked by City)" widget (relied on the demoted `employees`). * `employees` is dropped from company data seeds and re-added as a **custom** field seed, so dev workspaces still get an `employees` column matching the demoted behavior. ### Cleanup Front-end record types (`Company.ts`/`Person.ts`), the `getDisplayNameFromParticipant` test mock, metadata integration specs, the Zapier `crud_record` test, and the regenerated `get-standard-object-metadata-related-entity-ids` snapshot. ## ⚠️ Breaking change (intentional) Removes standard fields `Company.annualRecurringRevenue`, `Company.employees`, `Company.idealCustomerProfile`, `Company.xLink`, `Person.xLink`, and `Person.city` from the core GraphQL schema (replaced by `Company.annualRevenue`). This is why the breaking-changes check reports a large number of removals — `graphql-inspector` flags any removed object field plus its derived aggregate/order-by/filter/update types. **Mitigation:** the `upgrade:2-9:move-demoted-standard-fields-to-custom-application` command re-owns these fields as custom fields per workspace, preserving their name and data, so existing tenants keep working. New workspaces won't have them.	2026-06-04 15:54:04 +00:00
Paul Rastoin	3d49642d12	[AUDIT] Run knip over twenty-server (#21159) ... # Introduction Run [knip](https://knip.dev/) over twenty-server Used config: ```json { "$schema": "https://unpkg.com/knip@5/schema.json", "workspaces": { "packages/twenty-server": { "entry": [ "src/main.ts", "src/command/command.ts", "src/queue-worker/queue-worker.ts", "src/database/scripts/setup-db.ts", "src/database/scripts/truncate-db.ts", "src/database/clickHouse/migrations/run-migrations.ts", "src/database/clickHouse/seeds/run-seeds.ts", "src/instrument.ts", "lingui.config.ts", "test/integration/graphql/codegen/index.ts", "test/integration/utils/setup-test.ts", "test/integration/utils/teardown-test.ts", "scripts/**/*.ts", "**/*.spec.ts", "**/*.integration-spec.ts" ], "project": ["src/**/*.ts", "test/**/*.ts", "scripts/**/*.ts"], "ignore": [ "src/database/typeorm/**/migrations/**", "src/database/typeorm/**/*.entity.ts", "**/*.workspace-entity.ts", "**/logic-function-resource/constants/seed-project/**" ], "ignoreDependencies": ["@types/psl", "@types/aws-lambda"], "ignoreBinaries": ["nest", "lingui", "typeorm"] } } } ```	2026-06-04 10:05:22 +00:00
Etienne	15eaabdbc1	fix(ai) - optimize crud tools (#21133) ... - **Add delete many**, `delete_many_{object}` added alongside the existing `delete_one_{object}`. - **Uniformize naming**, crud module, type names, and MCP helper constants renamed for consistency. - **Optimize tool schema (learn phase)** - `find_many(_companies)`: **7 158 → 2 700 tokens** - `find_one(_company)`: **280 → 126 tokens** - .... - Main mechanism: `reused: 'ref'` (line 7 of `to-tool-json-schema.util.ts`). Zod walks the schema tree, tracks which Zod schema instances appear more than once, and emits each reused instance exactly once in `$defs`, replacing all subsequent occurrences with a `$ref`. Works because filter and value schemas are now extracted as shared objects. - **Optimize system prompt (tool catalog)**, DATABASE_CRUD section restructured to list operation patterns (`find_many_{object}`, …) once + objects once, instead of the full N×M cross-product of tool names. - **Optimize execute_tool**, shared record-properties schema (same `$defs` deduplication applies at call time); introduced `upsert_many`; added `selectedFields` to `find_*` so the agent only fetches the fields it needs.	2026-06-03 17:57:40 +00:00
Marie	4b15b949f3	Provide additional logsobservability to workflow runs (per node) (#21142) ... Surfaces per-step "Logs" tabs in the workflow run side panel so users can see what each step actually did (model + tokens + tool calls for AI, console output for serverless functions, request/response for HTTP, recipients/body for Email). <img width="546" height="501" alt="ai_agent_without_websearch" src="https://github.com/user-attachments/assets/c6ca3518-9489-4484-a570-3d0569ff3b03" /> ## Storage - New `stepLogs` JSONB column on the `workflowRun` workspace entity, typed as `Record<string, WorkflowRunStepLog>` (keyed by step id). - Schema lives in `twenty-shared`: `workflowRunStepLogSchema` with a discriminated `details.type` union for `AI_AGENT | CODE | HTTP_REQUEST | EMAIL` — frontends and backends consume the same Zod-inferred type. - Field is added to existing workspaces via a workspace upgrade command (`2-9 add-workflow-run-step-logs-field`); the standard-object metadata declares it for new workspaces. - Writes happen atomically per step in `WorkflowRunStepLogWorkspaceService.setStepLog` using `jsonb_set`. That lets concurrent steps in the same run write their own keys without contending with the existing lock around `workflowRun.state`. - Per-step payload is hard-capped at 256 KB; anything larger is dropped with a `logger.warn`, so a pathological tool call can never bloat a row. See below for more information. ## How logs are produced **Aalmost everything was already being collected; this PR mostly persists and renders it.** - **AI agent** — `AgentAsyncExecutorService` already tracked token usage, model id, native web-search count, and the AI SDK's `steps[]`. We map those into the log via `mapAiStepsToToolCallLogs` (`searchVector` stripped from record outputs, per-call input/output capped at 32/64 KB, max 200 tool calls per step). The only new measurement is a wall-clock `durationMs` taken around `executeAgent`, and we now fold native web-search cost into the displayed `totalCostInDollars` (it was already billed, just not shown). - **Code / serverless function** — reuses the `console.log` output the function runner already returns (`logsByLevel`); `build-code-step-log.util` only repackages it. - **HTTP request** — built from the action's existing input/output via `build-http-request-step-log.util`. No new signals collected. - **Email (send / draft)** — added `sanitizedHtmlBody` + `plainTextBody` to the existing tool outputs (a small additive change), then `build-email-step-log.util` consumes them. No additional AI inference or external calls are made for logging — the cost is a small CPU overhead per step plus the JSONB write. ## Security The log surface intentionally shows whatever the workflow touched, which made redaction and sanitization the main design concern. - **HTTP — secrets in headers**: existing `SENSITIVE_HEADER_NAMES` set (Authorization, Cookie, …) replaced with `[redacted]` in both request and response. - **HTTP — secrets in URLs**: `SENSITIVE_URL_PARAM_NAMES` (e.g. `api_key`, `token`, `access_token`) replaced in the query string via `URL`-based parsing. - **HTTP — secrets in bodies**: `SENSITIVE_BODY_KEY_REGEX` deep-walks JSON request/response bodies (object input or stringified JSON) and redacts matching keys. Applied to the `error` field too, since transport-layer errors sometimes embed structured payloads. - **Email — XSS risk in body preview**: tool outputs now expose a server-side `sanitizedHtmlBody`; the log builder prefers it over the raw user-authored `input.body`, with `plainTextBody` as a second fallback. The original raw body is only used if sanitization didn't happen (e.g. tool failed before composing). - **AI — internal/noisy data**: `searchVector` (Postgres tsvector strings) is stripped from record outputs returned by Twenty tools to avoid leaking internal full-text-search payloads. - **DB bloat / runaway agents**: 256 KB per-step cap + 32 KB / 64 KB per-tool-call input/output cap + 200 tool calls per step. <img width="547" height="307" alt="logic_function" src="https://github.com/user-attachments/assets/dd4a3d16-67f2-434b-95b3-bdcaf9ed053d" /> ## More details on Log size & truncation Logs are stored in `workflowRun.stepLogs` (JSONB), keyed by `stepId`. ### Per-step cap Each step's log is hard-capped at **256 KB** (`MAX_STEP_LOG_BYTES` in `WorkflowRunStepLogWorkspaceService.setStepLog`). For ~99% of workflows this is roomy — typical real-world sizes: - Code / serverless function: 1–20 KB - HTTP request: 5–70 KB - Email: 5–30 KB - AI agent (a handful of tool calls): 5–50 KB ### Two layers of bounding 1. **Per-field truncation** in each builder (before writing): - **Code**: ≤ 500 entries, ≤ 4 KB per message, ≤ 8 KB stack trace - **HTTP**: ≤ 32 KB per body (request + response), UTF-8 byte-aware - **Email**: ≤ 8 KB body preview, UTF-8 byte-aware - **AI agent**: ≤ 32 KB tool input, ≤ 64 KB tool output, ≤ 200 tool calls/step 2. **Global per-step safety net** at write time: if the assembled `stepLog` still exceeds 256 KB, the write is **dropped entirely** with a `logger.warn`. The workflow itself keeps running unaffected. ### What this means in practice - **Safe**: workflow execution, step results, downstream steps — never blocked by log size. - **Safe**: iterators (each iteration overwrites the previous log for that `stepId`, so they can't accumulate). - **Safe**: step retries (same `stepId` is overwritten, not appended). - **Possible**: an AI agent step with many large tool outputs (e.g., 50+ heavy `web_search` calls) can exceed 256 KB → the **entire** step's log is dropped, side panel shows "No logs were recorded for this step". The user has no explicit signal that the log was dropped due to size (only server-side warn). - **Possible** (theoretical): a workflow with hundreds of distinct steps could push the row toward Postgres's internal ~256 MB jsonb limit. Beyond that, individual `jsonb_set` writes would error and be swallowed by the action's try/catch — workflow still completes. ### Possible future hardening (not in this PR) - Replace "drop entire log" with a stub that preserves the summary card (cost, duration, status) and marks `truncated.reason = 'size_cap'`. - Surface size-drops in the UI (similar to the existing `<StyledTruncatedNotice>`). - Emit a metric so dropped logs are observable in dashboards.	2026-06-03 16:53:47 +00:00
Charles Bochet	cb744b2eeb	refactor(twenty-server): collapse workspace migration build orchestrator (#21144) ... ## Why `WorkspaceMigrationBuildOrchestratorService.buildWorkspaceMigration` was 1117 lines of 30 near-identical copy-pasted blocks (one per metadata entity) plus a 165-line ordered `actions: [...]` literal. Adding a new entity meant copying ~30 lines and hoping the boilerplate stayed in sync; the actual per-entity execution order was buried in the noise. ## Gain - Orchestrator: **1117 → 388 lines** - Net diff: **-558 lines** - Adding a new entity is now a single line in the registry - Execution order is visible at a glance	2026-06-02 14:16:10 +00:00
Félix Malfait	431f6ae98f	feat(settings): move settings chrome into a single rounded card (#21131) ... ## What Replaces `SubMenuTopBarContainer` with a settings-specific `SettingsPageLayout` that puts the whole page chrome — breadcrumb, centered title, actions, an optional secondary bar (tabs or wizard step), and the 760px body — inside **one rounded card**, with `SidePanelForDesktop` as a sibling. Title, tabs and body content share one centered vertical axis at every card width. Supersedes #21122. One PR, no feature flag. ## New components (`@/settings/components/layout/`) - **SettingsPageLayout** — owns the rounded card + side-panel sibling, `useCommandMenuHotKeys`, mobile command menu - **SettingsPageHeader** — breadcrumb · centered title · actions in a symmetric `1fr auto 1fr` grid (symmetric padding throughout) - **SettingsSecondaryBar** — the secondary row, bracketed by top + bottom borders - **SettingsTabBar** — centered tabs reusing `activeTabIdComponentState` + `TabListFromUrlOptionalEffect` for URL-hash sync (does not touch the shared `TabList`) - **SettingsWizardStepBar** — back arrow · "N. Label" · optional trailing slot ## Migrations - Bulk rename across ~80 call sites (`SubMenuTopBarContainer` → `SettingsPageLayout`); old component deleted. - 5 tab pages (AI, APIs & Webhooks, Applications, Members, Role) + the Data Model object-detail page render their tabs in `secondaryBar` (object-detail keeps "See records" / "New Field" in the header actions). - The 2 role object-level steps render the wizard step bar with working back navigation. - Accounts consolidated into **General / Emails / Calendars** tabs; standalone `SettingsAccountsEmails` / `SettingsAccountsCalendars` pages + routes + stories removed. `SettingsPath.AccountsEmails` / `AccountsCalendars` now resolve to `accounts#emails` / `accounts#calendars`, so existing `getSettingsPath()` links deep-link to the right tab via the existing hash sync — no call-site changes. ## Verification - `nx typecheck twenty-front` and `nx lint twenty-front` both clean. - Browser (logged-in workspace): title / tab / body / card centers align on a single axis at multiple widths — width-invariant, so alignment holds when the AI side panel (a sibling) shrinks the card. Rounded card with even gaps on all four sides; tab row bracketed by two 1px lines; no-tab pages render header → body with no lines; wizard back navigation works; `…/accounts#emails` opens the Emails tab. The shared `PageHeader` and `TabList` are untouched. The settings side panel itself isn't wired to open yet — that's a follow-up PR.	2026-06-02 14:22:57 +02: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	75df1f3997	chore(settings): address review comments from PR 21072 (#21121) ... ## Summary Round through bosiraphael's 31 review threads on the merged PR #21072 (discovery hero + ephemeral playground token). The user asked to apply each suggestion only where it adds value, so this PR is split into three buckets. ### Comments (~17 threads) - Tightened security-rationale / CSS-gotcha / API-doc comments to one or two factual lines - Kept (shortened) the comments above `RequireAccessTokenGuard` call sites — without them a future reader could remove the guard and silently reopen the escalation hole - Kept (shortened) the in-memory-only rationale on `playgroundApiKeyState` for the same reason - Kept `flex: 1 + min-height: 0` CSS gotcha on `SubMenuTopBarContainer` — non-obvious and easy to break ### Structure / extraction - Move `WEBHOOK_TABLE_ROW_GRID_TEMPLATE_COLUMNS` to its own constants file (one-export-per-file) - Split `SettingsAgentToolsTab` and `SettingsAgentToolsTable` across queries/, hooks/, types/, utils/: - `graphql/queries/findManyApplicationsForToolTable.ts` - `graphql/queries/findManyMarketplaceAppsForToolTable.ts` - `hooks/useSettingsAgentToolsTable.ts` (data loading + index merging) - `types/SettingsAgentToolItem|Application|MarketplaceApp` - `utils/getToolApplicationId|getToolLink` - Extract `SettingsAiModelsTab` optimistic mutations into `hooks/useSettingsAiModelsActions` (handleModelFieldChange, handleUseRecommendedToggle, handleModelToggle, handleToggleAllVisibleModels) - Extract `SettingsAI.handleCreateTool` into `hooks/useCreateTool` - Drop unnecessary `useMemo` wrappers on `heroTabs` arrays (SettingsObjects, SettingsLayout) - Simplify `MenuItemToggle` handler in SettingsAgentSkillsTab: `onToggleChange={setShowDeactivated}` (no longer wrapping with arrow + read of stale `!showDeactivated`) ### Hero assets - Replace placeholder `customize-illustration` with per-page exports - Rename `layout/customize-illustration-{light,dark}.png` → `layout/cover-{light,dark}.png` - Add `cover-{light,dark}.png` for **applications** and **members** (they were both pointing at the layout placeholder as a TODO) - Overwrite `data-model/cover-*.png`, `playground/cover-*.png`, `ai/ai-tools-cover-*.png` with the new exports ## Test plan - [ ] `npx nx typecheck twenty-front` ✅ - [ ] `npx nx typecheck twenty-server` ✅ - [ ] `npx nx lint twenty-front` ✅ (oxlint + oxfmt, 0 warnings/errors) - [ ] `/settings/layout`, `/settings/data-model`, `/settings/applications`, `/settings/ai`, `/settings/api-webhooks`, `/settings/members` each render the new hero illustration (light + dark) - [ ] AI tab: tool list still loads, search + Custom/Managed/Standard filters still work, "New Tool" still navigates to detail - [ ] AI tab: Models tab — smart/fast model select, "Use best models only" toggle, per-model checkboxes, toggle-all all still optimistic+revert on error - [ ] Skills tab: "Deactivated" toggle still flips show/hide - [ ] Webhooks table still uses the 1fr 28px grid	2026-06-02 07:23:14 +02:00
Paul Rastoin	989b45db15	Strictly type encryption rotation key site maps constants through entity type derivation (#21085) ... # Introduction Followup https://github.com/twentyhq/twenty/pull/21001 Now that the typeorm entities provide grains over their `encryptedString` value, we can strictly type the sitemaps of the encrypted string to rotate in case of encryption key rotation and also the integration tests tests cases	2026-06-01 15:25:58 +00:00
nitin	13f09d8946	[Dashboards] Remove gauge chart types and code (#20410) ... Follow-up cleanup to #20172.	2026-05-29 11:08:50 +02: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
martmull	6ea637d6c5	Export STANDARD_PAGE_LAYOUT_UNIVERSAL_IDENTIFIERS (#21010) ... fix https://discord.com/channels/1130383047699738754/1509086323464474705	2026-05-28 12:51:01 +00:00
neo773	c5606212f2	Ses outbound followup (#20610) ... This pull request unifies outbound with inbound under the new feature and the new email groups feature. These are workspace level shared inboxes that are shared between all workspace members. outbound sending with SES works, we only listen for tenant status events, rest is managed by AWS PR refactors old code and webhook to be split for outbound and inbound for proper separation | Area | Change | |---|---| | AWS SES driver | Split into `AwsSesRegisterDomainService` (tenant + identity + DKIM + MAIL FROM + configuration-set + EventBridge dest + contact list) and `AwsSesSendEmailService` (SendEmail). | | Reputation webhook | New `/webhooks/messaging/ses/outbound` route. SES → EventBridge (`Sending Status Enabled/Disabled` on default bus) → SNS → router → `SesOutboundSendingStateHandlerService` updates `emailing_domain.tenantStatus`. | | Inbound webhook | Refactored into `SesInboundWebhookRouterService` + `SesInboundMailHandlerService`. Shared `SnsSignatureVerifierService` + `SnsSubscriptionConfirmerService` across both routes. | | Global uniqueness | New migration + instance command: `emailing_domain.domain` is now globally unique (one tenant per domain across workspaces). | | Tenant status | New `emailing_domain.tenantStatus` column (`ACTIVE` / `PAUSED`) + `EmailingDomainTenantStatusService`. | | Send-email mutation | New `sendEmailViaDomain` GraphQL mutation + DTOs. | | Cleanup | `EmailingDomainWorkspaceCleanupJob` wired into `WorkspaceService.deleteWorkspace` — tears down SES tenant association + identity on workspace delete. | | Settings UI | Rewritten around reusable `SettingsTableListSection`. "Email Group" → "Email Handle" rename. New cells for status/source/forwarding. Outbound domains surfaced on workspace settings page. | ### Env vars (new) All in `config-variables.ts`, group `AWS_SES_SETTINGS`, all optional: - `AWS_SES_REGION` — `@IsAWSRegion`, consumed by `AwsSesClientProvider` + driver factory - `AWS_SES_ACCOUNT_ID` — used for ARN construction in driver factory - `SES_SNS_TOPIC_ARN_ALLOWLIST` — **shared** by inbound + outbound webhook routers, comma-separated list of accepted SNS topic ARNs (verified via `sns-payload-validator`) ### Migrations - `1778862608620-add-emailing-domain-tenant-status` (fast) — adds `tenantStatus` column. - `1778865501791-unique-emailing-domain-globally` (slow, idempotent) — enforces global uniqueness on `domain`. - Instance commands bumped to `2.5`. ### Infra dependency Two coupled twenty-infra PRs: - `ses-inbound-email` — receipt-rule + inbound SNS topic + S3 bucket policy + KMS grant + `email_group_*` outputs. - `ses-outbound-tf` — EventBridge rule + outbound SNS topic + SES IAM policy + outbound `webhook_url` subscription. **Based on `ses-inbound-email`.** Merge order: inbound first, then outbound. Outbound PR's chart edit owns the comma-joined `SES_SNS_TOPIC_ARN_ALLOWLIST` value (both ARNs). Features lives under `/settings/general` <img width="1496" height="845" alt="SCR-20260519-ofhi-2" src="https://github.com/user-attachments/assets/a025485a-09f7-4131-91cd-0067690ff18d" /> --------- Co-authored-by: Félix Malfait <felix.malfait@gmail.com> Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com> Co-authored-by: Félix Malfait <FelixMalfait@users.noreply.github.com>	2026-05-27 19:38:44 +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
nitin	863f3f29a2	Fix page layout widget tab moves (#20915) ... Fixes widget moves between page layout tabs by making pageLayoutTabId part of the flat-entity diff, so the save mutation no longer silently drops the new tab assignment. https://discord.com/channels/1130383047699738754/1508737039128985680	2026-05-27 15:29:12 +00:00
Weiko	2f358a1775	Add a Table display mode to relation field widgets (#20929) ... ## Context Adds a new Table layout to the FIELD widget for to-many relation fields. On a record page, a relation can now be displayed as a full record table (the same component used for record indexes and dashboard table widgets) scoped to the records related to the current record. https://github.com/user-attachments/assets/320b24dc-f019-4d0e-bc71-3e64d032d75a https://github.com/user-attachments/assets/2f6d4f8e-de26-4fc1-ae12-c9b9c19654dc https://github.com/user-attachments/assets/3fb6d512-f83c-4818-823e-46ad2644fbc2	2026-05-27 12:13:58 +00:00
Paul Rastoin	b8de469f37	Refactor and centralize file mimeType integrity check and sanitization (#20889) ... # Introduction closes https://github.com/twentyhq/private-issues/issues/484 This PR refactors the writeFile API to never expect to be passed a mimetype, its extract is done programmatically low level so any callers will pass through Same for the file sanitization ## IANA override Disclaimer for consistency we existing behavior we wanted to always have `application/typescript` - should we rather consider fallbacking to octect-steam instead ? - Any pulbic assets that has .ts will now also fallback to `application/typescript` instead of the official IANA ## Integration Added coverage	2026-05-26 15:10:52 +00:00
Weiko	90f711361c	Add definePermissionFlag for app-defined permission flags (#20887) ... ## Context Adds the SDK plumbing for apps to declare custom permission flags and the server-side manifest pipeline to persist them. ```typescript import { definePermissionFlag } from 'twenty-sdk/define'; export const MANAGE_INVOICES_PERMISSION_FLAG_UNIVERSAL_IDENTIFIER = '…'; export default definePermissionFlag({ universalIdentifier: MANAGE_INVOICES_PERMISSION_FLAG_UNIVERSAL_IDENTIFIER, key: 'MANAGE_INVOICES', label: 'Manage Invoices', description: 'Create, edit, and delete invoices', icon: 'IconReceipt', }); ``` ```typescript import { defineApplicationRole, SystemPermissionFlag } from 'twenty-sdk/define'; import { MANAGE_INVOICES_PERMISSION_FLAG_UNIVERSAL_IDENTIFIER } from './permission-flags/manage-invoices'; export default defineApplicationRole({ universalIdentifier: DEFAULT_ROLE_UNIVERSAL_IDENTIFIER, label: `${APP_DISPLAY_NAME} default function role`, // ... permissionFlagUniversalIdentifiers: [ SystemPermissionFlag.UPLOAD_FILE, MANAGE_INVOICES_PERMISSION_FLAG_UNIVERSAL_IDENTIFIER, ], }); ``` The flag can then be referenced by UUID in a role's permissionFlagUniversalIdentifiers. On sync, the catalog row lands in core.permissionFlag and the link in core.rolePermissionFlag. ## Not in this PR - Runtime permission checks. PermissionsService.getUserWorkspacePermissions still builds its result from Object.values(PermissionFlagType), so custom flags are stored but not yet enforced, code asking "does this role have MANAGE_INVOICES?" won't get a meaningful answer. Widening PermissionsService and UserWorkspacePermissions.permissionFlags to support arbitrary flag keys is the next PR. - PermissionFlag from apps can only define "tool" permissions and not "settings" as a permissionType, this parameter is not mutable. This is because "settings" are for settings page (until we might decide to separate both type of permissions into 2 different entities) and apps can't declare settings page or interact with them so this parameter would be unnecessary.	2026-05-25 16:53:37 +00:00
Félix Malfait	d602f35cbd	feat(data-model): custom-indexes management UI and mutations (#20846) ... ## Summary Brings indexes management into the per-object Settings tab as a section under Search (no feature flag, advanced mode only). Admins can create / delete non-unique indexes with the UI; apps can declare indexes in code with `defineIndex`. Composite-typed fields are now indexable by picking a specific sub-column (e.g. `Address > City`). A few related polish items also land here (invite-user dropdown lands on the Invite tab; standard warning callout above the new-index form). ## What ships ### UI — custom indexes on per-object Settings - New section directly under Search, wrapped in `AdvancedSettingsWrapper`. - Filter dropdown on the search bar toggles system-index visibility (shown by default since advanced mode). - **+ Add Index** button (disabled with tooltip once the per-object cap is reached) navigates to a dedicated `SettingsObjectNewIndex` page (matches the field-creation pattern, not a modal): - Field picker mirrors the webhook event-form layout (rows of dropdowns, implicit trailing empty row). - Composite fields surface their sub-properties (`Address > City`, `Currency > Amount`, …). - BTREE / GIN type selector. - Standard warning Callout: "Use indexes sparingly — each one speeds reads but slows writes." - Trash icon on `isCustom: true` rows → confirmation modal → `deleteOneIndex`. ### Server — `createOneIndex` / `deleteOneIndex` mutations - Gated by `SettingsPermissionGuard(DATA_MODEL)`. - `IndexMetadataService` wraps the existing migration runner via `WorkspaceMigrationValidateBuildAndRunService` so the metadata row and the SQL index land atomically. - Validation: rejects empty fields, duplicate `(fieldMetadataId, subFieldName)` pairs, fields not on the object, requires `subFieldName` for composite parents, forbids `subFieldName` on scalar/relation, enforces `MAX_CUSTOM_INDEXES_PER_OBJECT = 10`. - Delete refuses on `isCustom: false` rows so system indexes can't be removed via this API. - Dedicated GraphQL exception handler maps each typed error to the right transport error class. ### Composite sub-field indexing - Adds `subFieldName: string | null` column to `IndexFieldMetadataEntity` (fast instance command). - The flat-entity flow (`UniversalFlatIndexFieldMetadata`, `FlatIndexFieldMetadata`, `from-universal-flat-index-to-flat-index`, runner column resolution) all carry `subFieldName` through. - For composite parents, the runner uses `computeCompositeColumnName({...}, property)` for the picked sub-column; for non-composite parents, behavior is unchanged. - The `'::'` separator encodes `(fieldMetadataId, subFieldName)` for dedup on the wire; the frontend uses the same separator inside the Select component's string value. ### Apps can declare indexes in code (`defineIndex`) - New `IndexManifest` + `IndexFieldManifest` types in `twenty-shared/application` wired into the `Manifest` type. - `defineIndex` SDK helper + `IndexConfig`. CLI manifest builder + extractor recognize `defineIndex` / `ManifestEntityKey.Indexes`. - Server: `from-index-manifest-to-universal-flat-index` converter resolves field IDs, validates composite/scalar `subFieldName` rules, and delegates to `generateFlatIndexMetadataWithNameOrThrow` for the deterministic name. - Orchestrator wires the loop after the field-resolution pass; per-object cap enforced inline against the manifest. - Cascade on uninstall is automatic — when an app disappears its indexes drop with it (universal-flat-entity diff handles it). - Rich-app fixture ships a real `defineIndex` on `PostCard.status`, exercising the full manifest → install path in CI. ### Closed for now (open later if needed) - Apps cannot declare `isUnique` indexes — unique constraints stay with the field-creation flow. - Apps cannot use a partial-`indexWhereClause` — the UI surface keeps the framework's hardcoded allowlist. - UI cannot create unique or partial indexes either; same reasons. ### Cleanups along the way - Reused the existing `getCompositeSubFieldLabel` + `COMPOSITE_FIELD_SUB_FIELD_LABELS` (deleted the duplicates I'd created early in the PR). - Moved `MAX_CUSTOM_INDEXES_PER_OBJECT` to `twenty-shared/constants` (single source for FE + BE). - Replaced inline `isDefined(x) && x !== ''` with `isNonEmptyString` (from `@sniptt/guards`). - Hoisted the per-object fields Map + inlined the cap counter into the indexes orchestrator loop (drops the install scan from O(indexes × totalFields) to O(totalFields + indexes)). - Per design-feedback: page-based create flow (not a modal), filter dropdown on the SearchInput (not a separate toggle), webhook-style picker, field icons. ### Unrelated polish that lands here - "Invite user" link in the multi-workspace dropdown now lands on the Invite tab directly (`#invite`) instead of the first tab of the members page. ## Test plan - [ ] `npx nx typecheck twenty-server / twenty-front / twenty-sdk / twenty-shared` — passes - [ ] `npx nx lint:diff-with-main twenty-server / twenty-front` — clean - [ ] `npx jest index-metadata.service.spec` — green - [ ] `npx jest from-index-manifest-to-universal-flat-index` — green (new converter spec, 8 cases) - [ ] `npx vitest run src/sdk/define/indexes/__tests__/define-index.spec.ts` (twenty-sdk) — green (6 cases) - [ ] `npx vitest run --config vitest.integration.config.ts -t "rich-app"` — green (rich-app app-dev integration exercises the new manifest path with the PostCard.status index) - [ ] Advanced mode → Settings → any object → Settings tab → Indexes section is visible under Search - [ ] Create a single-field BTREE index, confirm SQL index exists (verify via `pg_indexes`) - [ ] Create a composite-field index (`Address > City`) and confirm the column is `addressAddressCity` - [ ] Create an index spanning two columns; column order matches the picker order - [ ] Attempt to create an 11th custom index → button is disabled with tooltip - [ ] Delete a custom index → confirmation modal → row disappears, PG index dropped - [ ] System indexes have no trash icon and are hidden by default	2026-05-25 17:47:09 +02:00
Paul Rastoin	b8b115f4e3	FileStorageService Dedicated file and folder code flow + integrity check (#20831) ... # Introduction Next handling mimetype integrity check and checksum integrity check for s3 storage type Always expecting a trailing end slash when deleting a folder etc ## Application Uninstalling an application now deletes all its related files ## File storage service Making a distincton between folder path and file path ## Validation Pipeline Every file operation in `FileStorageService.buildOnStoragePath` runs through `validateResourcePath`, which chains three validators in order: **1. `validateSafeRelativePath`** -- rejects path traversal attacks | Input | Result | Error | |---|---|---| | `../../../etc/passwd` | Rejected | `Resource path must not contain path traversal (..)` | | `/etc/passwd` | Rejected | `Resource path must be relative, not absolute` | | `file\0.txt` | Rejected | `Resource path contains null bytes` | | `..\\..\\etc\\passwd` | Rejected | `Resource path must not contain backslashes` | | _(empty)_ | Rejected | `Resource path must not be empty` | **2. `validateFilenameIntegrity`** -- enforces safe characters, length limits, extension required | Input | Result | Error | |---|---|---| | `my folder/file.mjs` | Rejected | `A path segment contains invalid characters...` | | `Makefile` | Rejected | `Filename must have an extension` | | `aaa...(256 chars).mjs` | Rejected | `A path segment exceeds the maximum length of 255 characters` | | `a/b/.../file.mjs` (1025+ chars) | Rejected | `Resource path exceeds maximum length of 1024 characters` | | `src/handlers/index.mjs` | Accepted | -- | | `my-app/my_file.tsx` | Accepted | -- | | `v1.0/module.config.mjs` | Accepted | -- | Allowed characters per segment: `a-z`, `A-Z`, `0-9`, `.`, `-`, `_` **3. `validateResourceExtension`** -- checks extension against the `FileFolder` allowlist | Input | FileFolder | Result | Error | |---|---|---|---| | `handler.js` | `BuiltLogicFunction` | Rejected | `Invalid file extension. Allowed extensions: .mjs` | | `card.tsx` | `BuiltFrontComponent` | Rejected | `Invalid file extension. Allowed extensions: .mjs` | | `script.js` | `PublicAsset` | Rejected | `Invalid file extension. Allowed extensions: .png, .jpg, ...` | | `index.mjs` | `BuiltLogicFunction` | Accepted | -- | | `app.tsx` | `Source` | Accepted | -- | | `photo.png` | `CorePicture` | Accepted | -- (unconfigured folder, passes through) | ## Consumers - **`FileStorageService`** -- calls `validateResourcePath`, throws `FileStorageException` on failure (last-resort defense) - **Resolver (`uploadApplicationFile`)** -- calls `validateResourcePath`, throws `ApplicationException` on failure (user-facing) - **Flat validators** -- call `validateResourcePath`, push the error to `validationResult.errors` (non-throwing, collects all errors) All error messages are translated via Lingui `t` and returned in a discriminated union `{ isValid: true } | { isValid: false, error: string }`, letting each consumer decide how to handle failures.	2026-05-25 11:52:54 +00:00
Marie	85d649e831	[Fix] Backfill missing command menu items conditional availability expression (#20852) ... ## Description Following [report in discord](https://discord.com/channels/1130383047699738754/1498690477044793386/1506602927412744242) Some command menu items were showing to all users because they had no conditional availability expression, whereas users did not actually have access to the page or feature behind. For instance: "Go to Admin panel", "Go to AI settings", "Send email" etc. <img width="833" height="1245" alt="image" src="https://github.com/user-attachments/assets/8d2a9404-9b81-4d58-9522-558e9924c457" /> ## Fix - Add conditional availability expressions - Backfill expressions for existing workspaces as they are stored in db (commandMenuItems table) --------- Co-authored-by: Charles Bochet <charles@twenty.com>	2026-05-23 13:22:25 +00:00
Etienne	eda41b4eba	feat(ai) - add observability (#20850) ... **AI Chat - Tool Executions (counters, tagged with model)** ai-chat/tool-execution-succeeded: number of tool calls invoked by the AI that completed without error ai-chat/tool-execution-failed: number of tool calls invoked by the AI that threw an error **AI Chat - Token Usage (counters, tagged with model)** ai-chat/input-tokens: total input tokens sent to the model across all turns ai-chat/output-tokens: total output tokens generated by the model ai-chat/cache-read-tokens: input tokens served from the model's prompt cache (cheaper) ai-chat/cache-write-tokens: input tokens written into the prompt cache for future reuse **AI Chat - Latency (histograms in ms, tagged with model)** ai-chat/turn-latency-ms: total duration of a full chat turn (from stream start to stream end) ai-chat/step-latency-ms: duration of a single reasoning/tool-call step within a turn ai-chat/ttft-ms: time-to-first-token, i.e. how long until the model starts streaming output **MCP - Tool Executions (counters)** mcp/tool-execution-succeeded: number of MCP tool calls that completed successfully mcp/tool-execution-failed: number of MCP tool calls that threw an error	2026-05-22 15:32:51 +00:00
Paul Rastoin	76e144e85a	Deprecate messageChannel messageFolder calendarChannel standard objects (#20836) ... # Introduction Removing old standard objects `messageChannel` and `messageFolder` and `calendarChannel` --------- Co-authored-by: Cursor <cursoragent@cursor.com>	2026-05-22 13:40:53 +00:00
Félix Malfait	084fa8eaba	fix(server): auto-index target<X>Id join columns on polymorphic standard objects (#20820) ... Closes #20726 ## The bug `timelineActivity` (and the three other polymorphic standard objects — `attachment`, `noteTarget`, `taskTarget`) store relations as N nullable `target<X>Id` columns, one per related object. Each one is a join key queried as `WHERE target<X>Id IN (...) AND deletedAt IS NULL`. For **built-in** related objects (Person, Company, Opportunity, …), each `target<X>Id` column gets a BTREE index, declared statically in `compute-{timelineActivity,attachment,noteTarget,taskTarget}-standard-flat-index-metadata.util.ts`. For **custom** related objects, the same `target<CustomObject>Id` column was added — **without an index**. On a `timelineActivity` table at issue-reporter scale (~21.9M rows, 7.1 GB), this turned record loads into 20–40s sequential scans and produced `QueryFailedError: Query read timeout` for end users. ## Diagnosis The morph/relation field generator (`generateMorphOrRelationFlatFieldMetadataPair`) already creates a BTREE index for the field that owns the join column and returns it alongside the field metadata pair. The two user-driven entry points (`fromRelationCreateFieldInput…`, `fromMorphRelationCreateFieldInput…`) correctly destructure and propagate that index. But the **custom-object creation path** — `buildDefaultRelationFlatFieldMetadatasForCustomObject`, called when a user creates a new custom object — destructured only `{ flatFieldMetadatas }` and threw away `indexMetadatas`. So every `target<CustomObject>Id` column added to the four polymorphic standard objects has been shipping unindexed since custom morph relations went in. ## The fix Three commits. ### 1. `fix(server): index target<CustomObject>Id columns on standard polymorphic objects` 13 lines across 2 files. - `build-default-relation-flat-field-metadatas-for-custom-object.util.ts` — also destructure `indexMetadatas` from the pair generator and accumulate them into the returned record (new field `standardTargetFlatIndexMetadatas`). - `from-create-object-input-to-flat-object-metadata-and-flat-field-metadatas-to-create.util.ts` — append the accumulated indexes to `flatIndexMetadataToCreate`. The migration pipeline at `object-metadata.service.ts:559–562` already passes `flatIndexMetadataToCreate` to the migration runner, so no further wiring is needed. From now on, creating a custom object also creates the four BTREE indexes — one per polymorphic standard object's new `target<CustomObject>Id` column — atomically with the rest of the migration. ### 2. `feat(server): backfill workspace command for relation join column indexes` For existing workspaces whose custom objects were created before the forward-fix. `upgrade:2-8:backfill-relation-join-column-indexes` is a `@RegisteredWorkspaceCommand('2.8.0', 1798100000000)` matching the pattern from `2-7-workspace-command-…-drop-connected-account-standard-object.command.ts`. Per workspace: 1. Load `flatObjectMetadataMaps`, `flatFieldMetadataMaps`, `flatIndexMaps` from the workspace cache. 2. Resolve the four polymorphic standard object IDs by `nameSingular` against `DEFAULT_RELATIONS_OBJECTS_STANDARD_IDS`. 3. Collect every field ID that's already covered by any existing index. 4. Filter `flatFieldMetadataMaps` to MORPH_RELATION fields on those four objects whose `settings.relationType === MANY_TO_ONE` (i.e. owns a join column) and whose ID isn't in the indexed set. 5. Generate a BTREE `UniversalFlatIndexMetadata` for each via `generateIndexForFlatFieldMetadata` (same helper the forward-fix uses). 6. Create the indexes in the workspace schema with **CONCURRENTLY** (see commit 3). 7. Submit the metadata through `WorkspaceMigrationValidateBuildAndRunService` so it lands in `indexMetadata` and the cache — same pipeline as a normal metadata change. The pipeline's own `CREATE INDEX IF NOT EXISTS` no-ops because the index already exists. Properties: - **Idempotent.** Re-running is a no-op once indexes exist. - **Scoped.** Only the four polymorphic standard objects, only their MANY_TO_ONE morph relation fields, only those with no covering index. - **Same code path as the forward-fix.** The backfill produces exactly the indexes the forward-fix would have created at custom-object creation time. - **`--dry-run` supported** via the base `ActiveOrSuspendedWorkspaceCommandRunner`. ### 3. `feat(server): create index CONCURRENTLY in relation join column backfill` Adds an opt-in `concurrently` flag to `WorkspaceSchemaIndexManagerService.createIndex` (threaded through `createIndexInWorkspaceSchema`). When `true`, emits `CREATE INDEX CONCURRENTLY IF NOT EXISTS …`. Defaults to `false` — every existing caller keeps the current transactional `CREATE INDEX` behavior. The backfill command opts in. It creates a QueryRunner **without** `startTransaction()`, issues the CONCURRENTLY indexes one-by-one (each waits for the previous to finish), then submits the metadata through the normal migration pipeline whose own `CREATE INDEX IF NOT EXISTS` is now a no-op. Why not flip the default for the helper: - `CREATE INDEX CONCURRENTLY` cannot run inside a transaction — Postgres errors out. The migration pipeline calls `createIndex` from inside a transactional schema migration. - CONCURRENTLY doesn't roll back with the transaction. If the surrounding migration fails, the index remains and you end up with metadata/schema drift. - Failed CONCURRENTLY builds leave an INVALID index behind that needs manual `DROP`. - UNIQUE indexes have different failure semantics under CONCURRENTLY (deferred, not immediate). So CONCURRENTLY is opt-in, used only where it's the right tool (post-hoc backfills on populated tables). ## Decisions / tradeoffs - **Single-column BTREE vs partial `WHERE deletedAt IS NULL` vs composite.** Twenty's queries always include `deletedAt IS NULL`. A partial index would be slightly better than a plain BTREE (smaller, no wasted seeks on soft-deleted rows). This PR ships single-column to match the existing built-in target index pattern, which already covers >95% of the available speedup (the 20s→4ms drop the reporter saw comes from having any index — composite/partial is a second-order effect). Switching all relation indexes to partial is a separate, broader change. - **CONCURRENTLY operator caveat.** If a CONCURRENTLY build is interrupted (kill, connection drop, OOM), Postgres leaves the index as INVALID. We deliberately don't probe `pg_index` for invalid leftovers on every create — catalog-table queries can be slow at multi-tenant scale and the failure mode is rare. Recovery is manual: `DROP INDEX <name>` and re-run the backfill. - **Forward-fix is not gated** behind a feature flag. The change is metadata-pipeline-internal; before, custom-object creation silently produced a degraded state. After, it produces the correct state. No new public API, no behavioural change for end users besides the indexes existing. ## Risk - Forward-fix: changes only the metadata produced during custom-object creation. New objects get four extra `FlatIndexMetadata` rows and four extra `CREATE INDEX` statements during their creation migration. Tables are empty at that point so the index builds in microseconds. - Helper change: API-compatible, default behavior unchanged. The new `concurrently` parameter is optional. - Backfill: read-only state probe → CONCURRENTLY index creation (no write blocking) → metadata insert via the normal migration pipeline. Idempotent. Reverting is `DROP INDEX`. ## Test plan - [ ] Verify forward-fix: create a custom object, confirm four new BTREE indexes appear on `timelineActivity`, `attachment`, `noteTarget`, `taskTarget` for the new `target<CustomObject>Id` columns, and that `flatIndexMaps` has matching entries. - [ ] Verify backfill on a workspace that had custom objects created before the fix: run `--dry-run` first, confirm the expected indexes are listed; then run for real, confirm the indexes appear in pg (and as `indisvalid = true` in `pg_index`) and in `flatIndexMaps`. Re-run; confirm no-op. - [ ] Verify backfill on a clean workspace: should log "no missing indexes" and exit. - [ ] Verify CONCURRENTLY behavior under load: run backfill against a workspace with active writes on `timelineActivity`; confirm inserts/updates keep working during index build (no `ShareLock` waits in `pg_stat_activity`). - [ ] On the affected reporter-scale workspace, confirm `EXPLAIN ANALYZE` switches from sequential scan to index scan and timeline activity timeouts go away.	2026-05-22 11:56:33 +02:00
nitin	068d365731	feat(sdk): error on incompatible view filter operand at sync time (#20763) ... view filters with mismatched operand + field type now error at sync -- was silently failing before	2026-05-22 09:01:40 +00:00
neo773	323e66433e	lint: migrate prettier to oxfmt (#20783) ... Most changes are `implements` being unwrapped this is not a oxfmt regression Prettier in 3.7 (we're on 3.1) changed this behaviour prettier blog [post](https://prettier.io/blog/2025/11/27/3.7.0#change-18094) This unifies our linting tooling --------- Co-authored-by: github-actions <github-actions@twenty.com> Co-authored-by: Charles Bochet <charles@twenty.com>	2026-05-22 00:21:33 +02:00
Etienne	0edd8d400c	fix(billing) - fix orphaned stripe subs (#20814) ... Fix sentry issues https://twenty-v7.sentry.io/issues/7203797925/?environment=prod&project=4507072499810304&query=is%3Aunresolved%20assigned%3Ame&referrer=issue-stream An orphaned sub is a not "canceled" stripe sub with no matching workspace - Clean all orphaned sub (script not included in this PR) - Ensure to soft delete > cancel stripe sub > check for not active sub > hard delete in every workspace deletion flow Bonus : - Remove dead code - Update doc on RLS (to improve AI chat knowledge)	2026-05-21 17:02:54 +00:00
Weiko	d13cc7c349	Drop legacy rolePermissionFlag.flag column + fallback logic (#20730) ... ## Summary - **New fast migration** `2-7-instance-command-fast-1779600000000-finalize-role-permission-flag-cutover.ts`: - `DROP CONSTRAINT IDX_ROLE_PERMISSION_FLAG_FLAG_ROLE_ID_UNIQUE` - `ALTER COLUMN permissionFlagId SET NOT NULL` - `DROP COLUMN flag` - `down()` repopulates `flag` from the catalog via `permissionFlagId` and restores the old unique. - **Entity**: `RolePermissionFlagEntity` hides the `flag` column by using the new decorator + drops old `@Unique` decorator; `permissionFlagId` and the `permissionFlag` relation become non-nullable. - **Deletes** the synthesizer `synthesize-flat-permission-flag-from-flag.util.ts` and every fallback branch that used it (`from-role-permission-flag-entity-to-flat-role-permission-flag.util.ts`, `from-flat-role-permission-flag-to-role-permission-flag-dto.util.ts`, `permissions.service.ts`, `workspace-roles-permissions-cache.service.ts`, `fromRoleEntityToRoleDto.util.ts`, `flat-role-permission-flag-validator.service.ts`, `role-permission-flag.service.ts:getEffectiveUniversalIdentifier`). - **Write path**: ~~drops `flag` from `CreateRolePermissionFlagInput`, the create util, and the application-manifest converter.~~ - **Metadata configs**: ~~removes `flag` from `all-entity-properties-configuration-by-metadata-name.constant.ts` (rolePermissionFlag block)~~ and flips `permissionFlag.isNullable` to `false` in `all-many-to-one-metadata-relations.constant.ts`. ### Why the `flag` field stays declared in the entity The decorator (`@WasRemovedInUpgrade`) is the right tool for the lifecycle marker, but it's a **reflect-metadata** runtime decorator — TypeScript can't see it at compile time. So while the adapter ([`UpgradeAwareEntityMetadataAdapter`](packages/twenty-server/src/engine/twenty-orm/upgrade-aware/upgrade-aware-entity-metadata.adapter.ts)) now correctly flips `isSelect`/`isInsert`/`isUpdate` to `false` once the drop migration's cursor is crossed, the *static* TypeScript types derived from `RolePermissionFlagEntity` (`UniversalFlatRolePermissionFlag`, `FlatRolePermissionFlag`, `MetadataEntityPropertyConfiguration<'rolePermissionFlag'>`, etc.) still see `flag` as a required scalar property — because the entity declares it. That means every producer of one of those derived types must include `flag`: - `from-create-role-permission-flag-input-to-flat-role-permission-flag-to-create.util.ts` plumbs it through. - `from-permission-flag-to-universal-flat-role-permission-flag.util.ts` (the application-manifest converter) sets `flag: permissionFlag.flag`. - `all-entity-properties-configuration-by-metadata-name.constant.ts` has a `flag` entry under `rolePermissionFlag`. - `CreateRolePermissionFlagInput` keeps the `flag` field. - `RolePermissionFlagService.upsertPermissionFlags` passes `flag: permissionFlag.key as PermissionFlagType` to the create util. Explored phantom-brand approach (`RemovedInUpgrade<T>` wrapper on the field type, key-filter mapped type applied inside `ScalarFlatEntity` / `UniversalFlatEntityFrom`) but previous commands could have `flag === undefined` (downcast from the brand since we can't compare with UpgradeMigrationName like we do with a decorator). That's a **silent-read** failure mode: compiles fine, comparisons against `flag` silently always-false, no error surfaces. Probably worth too much risk for what's a small amount of plumbing? The eventual full deletion of `flag` (entity field included) is a future cleanup once we drop cross-upgrade support for versions ≤ 2.6 Note: Not sure if this PR (and even the decorator) is really needed in the end, seems we need to keep a lot of code in place to handle legacy. Maybe a simple noop [At]Deprecated is enough @charlesBochet (and a migration to set the column nullable if that was not the case before + remove associated constraints)	2026-05-21 11:56:06 +00:00
Paul Rastoin	9b9c97a049	Deprecate and backfill delete ConnectedAccount twenty standard object (#20752) ... # Introduction Following connected account permissions refactor and encryption Removing the old workspace schema twenty standard application connectedAccount objects and related standard fields and index - a lot of deadcode - instance command backfill cleaning the connected account object from workspaces	2026-05-21 13:42:09 +02:00
Paul Rastoin	a3c92311e3	Application file storage service (#20793) ... # Introduction Fix unsafe resource path join with expected prefix at file storage directly Add early paths transversal detections in metadata validators	2026-05-21 09:21:44 +00:00
nitin	83b10ad698	fix(server): sync command menu item availability expressions on existing workspaces (#20719) ... Two fixes via one workspace command: 1. Gates 5 standard command menu items behind `pageType == "INDEX_PAGE"` -- `importRecords`, `exportView`, `seeDeletedRecords`, `createNewView`, `hideDeletedRecords`. They currently appear (and crash or do nothing) on RECORD_PAGE. 2. Fixes Edit Layout missing from older workspaces -- root cause is `conditionalAvailabilityExpression` drift between source-of-truth constants and the workspace DB (e.g. #20556 removed a feature flag from the expression without syncing existing workspaces). The 2-6 workspace command iterates all `STANDARD_COMMAND_MENU_ITEMS` and reconciles any `conditionalAvailabilityExpression` that differs from the constant. Idempotent -- already-correct rows are skipped. Deferred: `deleteRecords` doesn't refetch the current record after deletion on RECORD_PAGE (mutation fires but UI shows stale state until refresh) -- different fix shape (frontend handler), separate PR.	2026-05-19 14:42:40 +00:00
Marie	9fddaf53d5	Fix BUILDER_INTERNAL_SERVER_ERROR message (#20720) ... The throw site was passing (code, message) to a constructor whose signature is (message, code), so exception.message ended up as the literal string "BUILDER_INTERNAL_SERVER_ERROR" and the real error.message was stored in exception.code where nothing reads it. Swapping the two args puts the real error message back into exception.message, which is the field Yoga's error handler copies into the GraphQL response's top-level message — and that's the field the CLI prints.	2026-05-19 12:09:31 +00:00
nitin	db0547f503	[1/3] Rename permissionFlag to rolePermissionFlag + add permissionFlag catalog/backfill (#20481) ... Split of #20377. ## Summary This PR separates available permission flags from per-role permission flag grants. Previously, `core.permissionFlag` stored the role assignment directly: `roleId + flag`. This PR renames that legacy grant table to `core.rolePermissionFlag`, then recreates `core.permissionFlag` as the catalog of available permission flags. ## What changed - Rename the existing `core.permissionFlag` grant table to `core.rolePermissionFlag`. - Add the new syncable `core.permissionFlag` catalog entity with key, label, description, icon, permission type, relevance flags, and custom/standard metadata. - Add stable `SystemPermissionFlag` universal identifiers for the built-in `PermissionFlagType` values. - Seed the standard permission flags for every workspace under the Twenty standard application. - Backfill existing role grants: - create missing catalog rows for existing grant keys, - add `rolePermissionFlag.permissionFlagId`, - migrate grants from the old string `flag` column to the new catalog FK, - replace the old `(flag, roleId)` uniqueness with `(permissionFlagId, roleId)`. - Rewire role permission flag caches, permission checks, role DTO mapping, and `upsertPermissionFlags` to resolve through the catalog. - Keep the existing public role permission API shape: product/app surfaces still talk about `permissionFlags` and return `{ id, roleId, flag }`. - Update metadata flat-entity machinery, migration builders, validators, action handlers, snapshots, generated schemas, docs, and app fixtures for the new `permissionFlag` / `rolePermissionFlag` split. ## Behavior after this PR - Existing permission flag grants keep working. - Existing GraphQL role permission flows keep the same public naming. - Standard permission flags are represented as catalog rows. - Permission checks now compare grants through catalog universal identifiers instead of the legacy `flag` column. - Workspace deletion cleanup now verifies both `permissionFlag` and `rolePermissionFlag`. ## What is not in this PR - Public GraphQL CRUD for custom permission flags. - App manifest support for declaring new custom permission flags. - Frontend UI for creating or assigning custom permission flags beyond the existing role permission flow. --------- Co-authored-by: Weiko <corentin@twenty.com>	2026-05-18 11:57:47 +00:00
Félix Malfait	c938fbf4d6	feat(twenty-front): relation traversal in filter dropdown (stacked) (#20533) ... **Stacked on #20527** https://github.com/user-attachments/assets/48995655-401a-4c35-8094-e88da8408bdd ## Summary Surfaces the one-hop relation traversal added in #20527 through the existing **composite sub-field dropdown pattern**. Clicking a MANY_TO_ONE relation field in the "+ Filter" picker now opens the same second-level dropdown that composite fields (FULL_NAME, ADDRESS, CURRENCY, etc.) already use — populated with the target object's filterable fields. Picking one (e.g. `Company → Name`) builds a filter that serializes to the nested GraphQL filter the backend now accepts: `{ company: { name: { ilike: "%X%" } } }`. No new components. The whole feature reuses `AdvancedFilterSubFieldSelectMenu` + the existing `subFieldNameUsedInDropdownComponentState` + the existing `MenuItem hasSubMenu` indicator. Only the conditions that gate the sub-menu (and the sub-menu's content for relations) were broadened. ## What landed | File | Change | |---|---| | `ObjectFilterDropdownFilterSelectMenuItem` | Sub-menu chevron now shows on MANY_TO_ONE relations (`isManyToOneRelationField` util). | | `AdvancedFilterFieldSelectMenu` | Relation clicks open the sub-menu alongside composite clicks. | | `AdvancedFilterSubFieldSelectMenu` | New branch: when the sub-menu type is `'RELATION'`, render the target object's filterable fields via `useFilterableFieldMetadataItems(targetObjectMetadataId)`. Composite logic untouched. | | `objectFilterDropdownSubMenuFieldType` state | Widened to accept a `'RELATION'` sentinel. Role-permissions sub-field menu narrows it back out (it doesn't traverse relations). | | `useSelectFieldUsedInAdvancedFilterDropdown` | New optional `targetFieldMetadataItem` arg. When present, the stored RecordFilter's `type` is the target field's type so the operand picker and value input render the target's operands (`'TEXT'` operators when filtering `company.name`, etc.). | | `turnRecordFilterIntoGqlOperationFilter` (shared) | When the filter targets a `RELATION` field with a `subFieldName`, synthesize a field-metadata for the target, recurse to build the inner filter, then wrap it under the relation field's name → `{ relationName: { targetFieldName: { ...operator } } }`. | `RecordFilter.subFieldName` stays narrowly typed as `CompositeFieldSubFieldName` so the wide downstream consumers (`shouldShowFilterTextInput`, composite handlers in the serializer, etc.) don't change. The relation target field's name is stored through a narrowly-scoped cast at the dropdown's storage point — the serializer checks `filter.type === 'RELATION'` before interpreting it as a target field name, so the cast can't be mis-read by composite-only code paths. ## Test plan - [ ] Open a table view on People, click "+ Filter", click "Company" → sub-menu opens with Company's filterable fields - [ ] Pick "Name" → operand picker shows TEXT operators (Contains, Equals, …) - [ ] Type "Airbnb" → filter applies, table shows people whose company name contains "Airbnb" - [ ] Verify network tab: the GraphQL filter variable is `{ company: { name: { ilike: "%Airbnb%" } } }` - [ ] Same flow with a composite target field (e.g. `Company → annualRecurringRevenue → amountMicros`) — should work end-to-end (backend supports composite-within-relation; #20527 has an integration test covering this) - [ ] Composite fields (FULL_NAME, ADDRESS) still open their normal sub-menu and filter correctly — no regression - [ ] Role-permissions field-select sub-field menu is unaffected (it bails out early on the RELATION sentinel) ## Out of scope - ONE_TO_MANY traversal (no backend support yet) - Aggregates (`people.count > 5`) - Persisting relation-traversal filters into a saved view (ViewFilter has no `relationPath` column yet; that's a separate slice) - REST API DSL changes - AI Tools 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-15 16:42:47 +02:00
neo773	42975a4168	fix(server): decouple SDK client generation from workspace activation (#20514) ... `activateWorkspace` enqueues SDK gen job inside `WorkspaceManagerService.init()` introduced by https://github.com/twentyhq/twenty/pull/19271 But if enqueue call fails it crashes cuz it doesn't have try catch so created workspace is in corrupted state <img width="636" height="812" alt="image" src="https://github.com/user-attachments/assets/09acd042-46d0-4225-adc0-c74ea770785d" /> FIx: Move SDK enqueue out of `init()` Call after `activateAndInitializeUpgradeState` succeeds, wrap in try catch. Mirror preInstalledAppsService.installOnWorkspace pattern. Assuming enqueue failure if Redis is unavailable we fallback to `SdkClientArchiveService.downloadArchiveBufferOrGenerate` which generates it on the fly Around 19 workspaces in prod affected with status `ONGOING_CREATION`	2026-05-14 10:25:24 +00:00
Charles Bochet	7fa136f305	feat(twenty-server): migrate remaining at-rest encryption sites to versioned envelope (#20550) ... ## Summary Second PR in the encryption key rotation series. The previous PR (#20528) introduced `ENCRYPTION_KEY` + the versioned `enc:v2:<keyId>:<base64>` envelope inside `SecretEncryptionService` and migrated `ConnectedAccountTokenEncryptionService` as the first consumer. This PR routes every remaining at-rest encryption site through the versioned envelope so that `ENCRYPTION_KEY` (and the future `FALLBACK_ENCRYPTION_KEY`) actually covers them. The legacy unprefixed CTR ciphertext remains readable as a fallback during the rollout window — every migrated read site uses `decryptVersioned`, which transparently delegates to the legacy CTR decrypt when it sees an unprefixed payload. ### Service migrations - **`ApplicationVariableEntityService` (#8)** — workspace-scoped. HKDF info is bound to each row's `workspaceId`. A new `decryptAndMaskVersioned` helper lands on `SecretEncryptionService` for the resolver display path. - **`ApplicationRegistrationVariableService` (#7)** + consumers — **instance-scoped**. Registration variables are server-level config readable by every workspace that installs the application, so HKDF info is `instance`. Updated consumers: - `LogicFunctionExecutorService.buildServerVariableEnvMap` - `ConnectionProviderService.getClientCredentials` - **`LogicFunctionExecutorService.buildEnvVar` (#9)** — workspace-scoped. Each variable's `workspaceId` is threaded into `decryptVersioned`, so per-workspace HKDF contexts are honoured at execution time. - **`UpdateApplicationVariableActionHandlerService`** (workspace-migration runner) — threads `workspaceId` through the secret/non-secret toggle. - **`JwtKeyManagerService` (#3)** — instance-scoped. Signing keys are shared across the JWKS. - **`ConfigStorageService` (#6)** — instance-scoped sensitive STRING config variables. ### Slow instance commands (2.5.0) Each migrated site has a paired backfill that re-encrypts existing rows into the v2 envelope before the column is constrained: | timestamp | command | scope | CHECK constraint | |---|---|---|---| | `1798000005000` | encrypt-application-variable | workspaceId | `"isSecret" = false OR value = '' OR value LIKE 'enc:v2:%'` | | `1798000006000` | encrypt-application-registration-variable | instance | `"encryptedValue" = '' OR value LIKE 'enc:v2:%'` | | `1798000007000` | encrypt-signing-key-private-keys | instance | `"privateKey" IS NULL OR value LIKE 'enc:v2:%'` | | `1798000008000` | encrypt-sensitive-config-storage | instance | _none_ — heterogeneous jsonb column | All backfills are idempotent (the SELECT filter skips rows already in v2 form) and run before their respective `up()` adds the CHECK constraint. Every `down()` deliberately stops at dropping the CHECK constraint — they intentionally do not re-introduce plaintext on rollback. ### Tests - Unit specs for each new slow command cover the v2 upgrade path, the idempotency invariant, and the instance vs workspace HKDF scope. - New `JwtKeyManagerService` spec asserts `decryptVersioned`/`encryptVersioned` are called without `workspaceId` (instance scope). - Updated existing specs for `ApplicationVariableEntityService`, `ConfigStorageService`, and `buildEnvVar` to assert the versioned API and the workspace HKDF context plumbing. - New `SecretEncryptionService.decryptAndMaskVersioned` cases in the service spec. - Updated the `applicationRegistrationVariable` integration spec to assert the column now stores `enc:v2:<keyId>:<base64>` instead of raw legacy CTR. ### Out of scope (future PRs) - `PostgresCredentialsService` — bespoke `jwtWrapperService.generateAppSecret`–derived key + `encryptText`/`decryptText` from `auth.util.ts`; deserves its own migration. - `SimpleSecretEncryptionUtil` (TOTP) — entirely different `aes-256-cbc` `iv:enc` format; deserves its own migration. ## Test plan - [x] `npx nx typecheck twenty-server` - [x] `npx nx lint:diff-with-main twenty-server` (oxlint + prettier) - [x] Local jest run for `secret-encryption | connected-account-token | application-variable | application-registration-variable | build-env-var | jwt-key-manager | config-storage | encrypt-application-variable | encrypt-application-registration-variable | encrypt-signing-key | encrypt-sensitive-config-storage` — 17 suites, 106 tests pass. - [x] Local jest run for `upgrade | instance-command` — 12 suites, 86 tests pass. - [ ] CI green - [ ] Manual review of CHECK constraint shapes by a server reviewer (each one matches `enc:v2:%` rather than `enc:v_:%` since none of the migrated columns can legitimately hold `enc:v1:` ciphertext).	2026-05-14 06:10:52 +00:00
Charles Bochet	04eb913551	chore(page-layout): remove IS_RECORD_PAGE_LAYOUT_* feature flags (#20556) ... ## Summary - Both \`IS_RECORD_PAGE_LAYOUT_EDITING_ENABLED\` and \`IS_RECORD_PAGE_LAYOUT_GLOBAL_EDITION_ENABLED\` are force-enabled on every existing workspace by the 1.23.0 upgrade command \`BackfillRecordPageLayoutsCommand\` and seeded enabled for new workspaces via \`DEFAULT_FEATURE_FLAGS\` + \`seed-feature-flags.util.ts\`. They are no longer load-bearing. - Unwrap all \`if (flag) { … }\` conditionals to their enabled branch on both server and front. - Delete legacy fallback files that only the disabled branch reached: \`PageLayoutRelationWidgetsSyncEffect\`, \`usePageLayoutWithRelationWidgets\`, \`reInjectDynamicRelationWidgetsFromDraft\`, \`injectRelationWidgetsIntoLayout\`, \`isDynamicRelationWidget\` (and their tests). - Strip the two \`enableFeatureFlags\` calls from the 1.23 upgrade command — the page-layout backfill data logic itself is kept intact since old workspaces upgrading from < 1.23 still need it. - No DB cleanup migration: stale \`featureFlag\` rows are left in place, matching the precedent set by #20531 and #20460. Net diff: 37 files, +106 / -1727. ## Test plan - [x] \`npx nx typecheck twenty-shared twenty-server twenty-front\` — all pass - [x] \`npx nx lint:diff-with-main twenty-server twenty-front\` — all pass - [x] \`cd packages/twenty-front && npx jest page-layout\` — 1240 tests, all pass - [x] \`cd packages/twenty-server && npx jest workspace-entity-manager.spec\` — pass - [ ] Manual smoke: open a record page, verify tabs render and \"Edit Layout\" command-menu action is available - [ ] Manual smoke: Settings → Data model → object → Layout tab is visible (and hidden for remote / Dashboard objects) - [ ] Manual smoke: edit a tab title, save, reload — confirm persistence	2026-05-14 08:12:00 +02:00
Etienne	fcd2d586ee	chore(billing) - remove feature flag (#20531) ... - remove feature flag - remove old enforce cap usage logic	2026-05-13 18:52:29 +02:00
martmull	dea1f89904	Inject none secret env variables into front components (#20511) ... ## Summary - Inject non-secret application variables (`isSecret: false`) into front component `process.env` via the existing Web Worker `setWorkerEnv` mechanism - Filter secret variables server-side in the resolver so they never reach the browser - Set application variables before system variables (`TWENTY_API_URL`, `TWENTY_APP_ACCESS_TOKEN`) to prevent override - Wire up environment variable keys in the logic function code editor for TypeScript autocomplete ## Test plan - [x] Unit tests for `buildNonSecretEnvVar` (6 passing) - [x] Typecheck passes for `twenty-front` and `twenty-server` - [x] Install an app with both `isSecret: false` and `isSecret: true` variables, open a front component, verify only non-secret vars appear in `process.env` - [x] Open a logic function editor, verify autocomplete suggests declared variable keys	2026-05-13 16:27:56 +00:00
Weiko	27fd124c2e	Dedicated REST controllers for object & field metadata (#20364) ... ## Summary - Replace the dynamic `RestApiMetadataController` (which parsed `/rest/metadata/*path` and proxied to internal GraphQL) with two dedicated controllers: `ObjectMetadataController` and `FieldMetadataController`. - Drop the GraphQL hop: reads hit Postgres directly via TypeORM repositories; writes call the existing `{create,update,delete}One{Object,Field}` service methods. - Introduce a new clean response shape behind a workspace feature flag (`IS_REST_METADATA_API_NEW_FORMAT_DIRECT`) — see grace period below. - Update the OpenAPI spec so the REST playground reflects the (default) legacy shape during the grace period. ## Why The legacy metadata controller was over-complex: it routed every method through a path parser, a set of GraphQL query-builder factories, an internal GraphQL call, and a `cleanGraphQLResponse` post-processor. Operation names from GraphQL (`createOneObject`, `updateOneField`, …) leaked straight into REST responses. The internal-GraphQL hop also gave us nothing on metadata reads — pagination, filtering, and serialization all happen against the same Postgres tables either way. ## Feature flag & grace period `IS_REST_METADATA_API_NEW_FORMAT_DIRECT` (workspace-scoped): - **Existing workspaces:** flag absent → resolves to `false` → **legacy response shape** (no behavior change). - **Newly created workspaces:** flag seeded to `true` via `DEFAULT_FEATURE_FLAGS` → **new response shape** from day one. - **Toggle:** support-assisted (no frontend); customers contact us to opt into the new shape early. - **Removal:** the flag, the legacy adapter utils (`to-legacy-{object,field}-metadata-response.util.ts`), and the parametrized test wrapper get deleted after the grace window. New shape becomes the only shape; OpenAPI flips to new shape; POST loses the conditional and reverts to a declarative response. ## Response shapes | Operation | Legacy (flag OFF, default for existing) | New (flag ON) | |-----------|-----------------------------------------|---------------| | `GET /rest/metadata/objects` | `{ data: { objects: [...] }, pageInfo, totalCount }` | `{ data: [...], pageInfo, totalCount }` | | `GET /rest/metadata/objects/:id` | `{ data: { object: {...} } }` | `{ ... }` | | `POST /rest/metadata/objects` | `201 { data: { createOneObject: {...} } }` | `201 { ... }` | | `PATCH/PUT /rest/metadata/objects/:id` | `{ data: { updateOneObject: {...} } }` | `{ ... }` | | `DELETE /rest/metadata/objects/:id` | `{ data: { deleteOneObject: { ... } } }` | `{ ... }` | Same matrix for `/rest/metadata/fields`. Cursor params (`starting_after`, `ending_before`, `limit`) and `totalCount` are preserved across both shapes. POST returns `201` in both (old controller already did — the doc on main saying `200` was wrong). ## Implementation notes - Reads go straight to Postgres with TypeORM cursor pagination (`paginateByIdCursor` util, mutually-exclusive `starting_after` / `ending_before`). No cache on this path — caching + filterable pagination didn't combine cleanly. - Object endpoints inline `fields[]` via a single follow-up `WHERE objectMetadataId IN (...)` query. - Controllers read the flag via `FeatureFlagService.isFeatureEnabled` and conditionally pass the result through a legacy-shape adapter util before returning. - Per-domain REST exception filters (`{Object,Field}MetadataRestApiExceptionFilter`); the `exceptionCode → httpStatus` switch is extracted to a util so it can be merged with the existing GraphQL handler later. - New controllers live inside the metadata domain modules (`metadata-modules/{object,field}-metadata/controllers/`) to match existing precedent (view-field, view, page-layout, …). - Removes: `RestApiMetadataController`, `RestApiMetadataService`, `metadata/query-builder/`, `clean-graphql-response.utils.ts`. - Integration tests are parametrized over both flag values via `describe.each` — both shapes are asserted in CI. - OpenAPI fixes inherited from the migration (kept as-is): documents flat `fields: [...]` rather than the obsolete `{edges:{node:[...]}}` wrapping; always emits `totalCount`; POST status `201`. These match what customers actually receive on both shapes. Note: Next goal is to implement something similar for graphql and remove nestjs-query dependency for those 2 entities, then generalise it. Note2: We have the same issue with Core Rest API such as ```json { "data": { "createCompany": { "id": "123e4567-e89b-12d3-a456-426614174000", "createdAt": "2026-05-07T12:14:52.769Z", "updatedAt": "2026-05-07T12:14:52.769Z", "deletedAt": "2026-05-07T12:14:52.769Z", ... ``` with "createCompany" here which is odd compared to REST standards (FYI @etiennejouan @charlesBochet) ## Before (Without feature flag) <img width="1346" height="712" alt="Screenshot 2026-05-12 at 20 50 38" src="https://github.com/user-attachments/assets/316ce225-1045-4aac-97a9-60fd537eb1ec" /> <img width="1378" height="729" alt="Screenshot 2026-05-12 at 20 52 24" src="https://github.com/user-attachments/assets/a621ab6f-e4f8-44d5-817c-1efd25d33c30" /> ## After (With feature flag) <img width="1376" height="728" alt="Screenshot 2026-05-12 at 20 50 46" src="https://github.com/user-attachments/assets/2424d9c5-e4ed-497c-8e5c-6b54d78675e4" /> <img width="1375" height="727" alt="Screenshot 2026-05-12 at 20 51 47" src="https://github.com/user-attachments/assets/101d957f-38ed-45d9-ab7b-f4f4eb983397" /> --------- Co-authored-by: prastoin <paul@twenty.com>	2026-05-13 12:31:16 +00:00
MkDev11	bbc55193f5	Fix phone unique constraints (#20261) ... ## Summary Closes #20195 Fix phone field unique constraints so phone numbers are considered unique by both `primaryPhoneNumber` and `primaryPhoneCallingCode`. - Include `primaryPhoneCallingCode` in the shared phone composite unique constraint metadata - Align the frontend settings composite field config with the backend metadata - Return all included unique composite subfields when building create-many conflict fields - Match composite unique conflict fields as a group during create-many upserts ## Root Cause Phone composite metadata only marked `primaryPhoneNumber` as part of the unique constraint. That made different international phone numbers with the same national number conflict, for example `+1 123456789` and `+32 123456789`. ## Test Plan - `yarn workspace twenty-shared build` - `jest --runTestsByPath <index action handler and create-many utility specs>` - `prettier --check <touched files>` - `oxlint --type-aware <touched files>` - `nx run twenty-shared:typecheck` - `nx run twenty-server:typecheck` - `nx run twenty-front:typecheck` --------- Co-authored-by: mkdev11 <MkDev11@users.noreply.github.com> Co-authored-by: Etienne <45695613+etiennejouan@users.noreply.github.com> Co-authored-by: prastoin <paul@twenty.com>	2026-05-13 11:57:19 +00:00
Paul Rastoin	a159a68e2c	[twenty-server] no floating promises lint rule (#20499) ... ## Introduction That's an audit + RFC ## Fire-and-forget (`void`) -- Intentional, correct These are telemetry, metrics, and audit logging in hot paths or non-critical contexts. `void` is the right choice. | File | What was voided | |---|---| | `sign-in-up.service.ts` | `metricsService.incrementCounter` (sign-up metric) + `auditService.insertWorkspaceEvent` (workspace created) | | `use-graphql-error-handler.hook.ts` | 5x `metricsService.incrementCounter` (GraphQL operation metrics) | | `bullmq.driver.ts` | 2x `metricsService.incrementCounter` (job completed/failed metrics) | | `call-webhook.job.ts` | 2x `auditService.insertWorkspaceEvent` + 1x `metricsService.incrementCounter` | | `custom-domain-manager.service.ts` | `analytics.insertWorkspaceEvent` (domain activation event) | | `logic-function-executor.service.ts` | `auditService.insertWorkspaceEvent` (function execution) | | `workflow-runner.workspace-service.ts` | `metricsService.incrementCounter` (throttle metric) | | `cleaner.workspace-service.ts` | `metricsService.incrementCounter` (deleted workspace metric) | | `stream-agent-chat.job.ts` | Detached IIFE for streaming chunks (intentional concurrent pipeline) | | `workspace-auth-context.middleware.ts` | `withWorkspaceAuthContext(...)` (AsyncLocalStorage, returns void anyway) | ## Top-level script entry points (`void bootstrap()`) These are module-level calls where the promise has no consumer. `void` makes the lint rule happy and documents the intent. | File | What changed | |---|---| | `main.ts` | `void bootstrap()` | | `command.ts` | `void bootstrap()` | | `queue-worker.ts` | `void bootstrap()` | | `truncate-db.ts` | `void dropSchemasSequentially()` | | `codegen/index.ts` | `void generateTests(forceArg)` | ## Now properly awaited -- Real bug fixes These were floating promises that could silently fail, lose data, or cause race conditions. | File | What was fixed | |---|---| | `billing-sync-plans-data.command.ts` | `meters.map(async ...)` wrapped in `Promise.all` -- was returning before upserts finished | | `cache-storage.service.ts` | `setAdd` and `setPop` had `.then()` chains that weren't returned/awaited | | `create-audit-log-from-internal-event.ts` | 4x `auditService.createObjectEvent` now awaited inside a job | | `cleaner.workspace-service.ts` | 2x `emailService.send(...)` now awaited -- emails could silently fail | | `agent-async-executor.service.ts` | `calculateAndBillUsage` + `billNativeWebSearchUsage` in `finally` block now awaited | | `repair-tool-call.util.ts` | `calculateAndBillUsage` now awaited | | `agent-title-generation.service.ts` | `calculateAndBillUsage` now awaited | | `chat-execution.service.ts` | `billNativeWebSearchUsage` now awaited | | `ai-generate-text.controller.ts` | `calculateAndBillUsage` in `finally` block now awaited | | `agent-turn.resolver.ts` | `messageQueueService.add(...)` now awaited | | `command.ts` | `app.close()` now awaited (was exiting before graceful shutdown) | | `i18n.service.ts` | `loadTranslations()` in `onModuleInit` now awaited | | `workspace-query-hook.explorer.ts` | `explore()` in `onModuleInit` now awaited | | `message-queue.explorer.ts` | `handleProcessorGroupCollection` in `onModuleInit` now awaited | | `ai-billing.service.spec.ts` | Test now properly `await`s the async call | | `messaging-messages-import.service.spec.ts` | `expect(...)` now properly `await`ed for async assertion | | `archive.finalize()` (3 files) | Voided -- promise resolution already handled by `pipeline()` / `on('end')` | ## Impersonation & security audit trail -- Upgraded from `void` to `await` These were previously fire-and-forget but are security/compliance-critical events that must be reliably persisted. | File | What was fixed | |---|---| | `impersonation.service.ts` | 4x `auditService.insertWorkspaceEvent` now awaited (impersonation attempt, token generation attempt/success/failure) | | `auth.resolver.ts` | 5x `auditService.insertWorkspaceEvent` now awaited (impersonation token exchange attempt/success/failure at server and workspace levels) | | `auth.service.ts` | 2x `analytics.insertWorkspaceEvent` now awaited (impersonation attempted/issued) | ## Billing audit -- Upgraded from `void` to `await` Payment events should be reliably persisted for financial/compliance reporting. | File | What was fixed | |---|---| | `billing-webhook-invoice.service.ts` | `auditService.insertWorkspaceEvent(PAYMENT_RECEIVED_EVENT)` now awaited inside Stripe webhook handler | ## Fire-and-forget with proper error handling -- Upgraded from bare `void` These remain non-blocking but now catch and log errors instead of risking unhandled rejections. | File | What was fixed | |---|---| | `logic-function-executor.service.ts` | `applicationLogsService.writeLogs` now uses `.catch()` instead of bare `void` -- user-facing logs should surface errors | ## Systemic infrastructure fixes | File | What was fixed | |---|---| | `metrics.service.ts` | `incrementCounter`: Redis cache write (`metricsCacheService.updateCounter`) now uses `.catch()` internally instead of raw `await` -- prevents unhandled rejections across all `void metricsService.incrementCounter(...)` call sites when Redis is unhealthy | | `audit.service.ts` | `preventIfDisabled`: made properly `async` with `await` and consistent `Promise<{ success: boolean }>` return type. Removed broken `catch` that returned an `AuditException` as a value (wrong constructor args, unreachable dead code). Removed unused `AuditException` import | ## Fixed in this session (beyond original PR) | File | What changed | |---|---| | `telemetry.listener.ts` | Removed misleading `Promise.all` + `void` combo; replaced with simple `for...of` + `void` | | `message-queue.explorer.ts` | Changed from `void` to `await` so startup crashes on registration failure |	2026-05-13 10:08:42 +00:00
martmull	7ade9e3aab	Fix application variable issue (#20500) ... Fixes wrong formatting converting secret value to ******** before saving Issued by https://discord.com/channels/1130383047699738754/1423290797079662602/1502674904770936903	2026-05-12 18:52:17 +00:00
Weiko	70bb011daa	fix: map FlatEntityMaps and WorkspaceMigrationRunner exceptions to proper status codes on REST and GraphQL (#20494) ... ## Context Calling `POST /rest/views` (and other metadata mutations) currently returns a generic `500` for user-input failures: Ex: 1. **Invalid `objectMetadataId`** — `resolveEntityRelationUniversalIdentifiers` throws `FlatEntityMapsException(RELATION_UNIVERSAL_IDENTIFIER_NOT_FOUND)`. Should be `404`. 2. **Missing required field** (e.g. `icon`) — Postgres raises a `NOT NULL` violation, wrapped as `WorkspaceMigrationRunnerException(EXECUTION_FAILED)` carrying a `QueryFailedError`. Should be `400`. Neither was caught by `ViewRestApiExceptionFilter`, so both fell through to `UnhandledExceptionFilter` and were emitted as `500`s without reaching Sentry. Same gap existed on most metadata GraphQL resolvers — only `page-layout*` and `role` resolvers covered `WorkspaceMigrationRunnerException` via `WorkspaceMigrationGraphqlApiExceptionInterceptor`. ## Changes ### New filters REST (`HttpExceptionHandlerService` + Sentry-aware): - `FlatEntityMapsRestApiExceptionFilter` — maps `RELATION_UNIVERSAL_IDENTIFIER_NOT_FOUND` / `ENTITY_NOT_FOUND` → `404`, `ENTITY_ALREADY_EXISTS` → `409`, others → `500`. - `WorkspaceMigrationRunnerRestApiExceptionFilter` — for `EXECUTION_FAILED`, unwraps the underlying `metadata` / `workspaceSchema` / `actionTranspilation` error; if it's a `QueryFailedError` it gets remapped to `400` via `HttpExceptionHandlerService`. `APPLICATION_NOT_FOUND` → `404`, `DDL_LOCKED` → `503`, otherwise `500`. GraphQL (graphql-errors + existing formatter): - `FlatEntityMapsGraphqlApiExceptionFilter` — kept as the GraphQL-shaped counterpart (`NotFoundError` / `InternalServerError`). - `WorkspaceMigrationRunnerGraphqlApiExceptionFilter` — reuses `workspaceMigrationRunnerExceptionFormatter` for parity with the existing interceptor. ### Wiring Filters are now declared **per controller / resolver** via `@UseFilters` (no global `APP_FILTER` registration) so they participate in the normal NestJS filter chain instead of being preempted by `UnhandledExceptionFilter`. REST: - `view.controller.ts` — adds `FlatEntityMapsRestApiExceptionFilter` and `WorkspaceMigrationRunnerRestApiExceptionFilter`. GraphQL (14 resolvers, all that mutate flat entities): - `FlatEntityMapsGraphqlApiExceptionFilter` added to: `view`, `view-field`, `view-field-group`, `view-sort`, `view-group`, `view-filter`, `view-filter-group`, `page-layout`, `page-layout-tab`, `page-layout-widget`, `role`, `object-metadata`, `field-metadata`, `index-metadata`. - `WorkspaceMigrationRunnerGraphqlApiExceptionFilter` added to the same list **except** the four already covered by `WorkspaceMigrationGraphqlApiExceptionInterceptor` (`page-layout`, `page-layout-tab`, `page-layout-widget`, `role`) — to avoid double-handling. ## Why per-resolver / per-controller instead of global Earlier attempt to register the filters globally via `APP_FILTER` regressed: NestJS reverses the global filter list and `selectExceptionFilterMetadata` is first-match-wins, so `UnhandledExceptionFilter` (registered last via `app.useGlobalFilters` in `main.ts`) ended up first in the iteration order and preempted every domain-specific filter. The per-resolver / per-controller approach is explicit and predictable. ## Before <img width="953" height="450" alt="Screenshot 2026-05-12 at 15 31 40" src="https://github.com/user-attachments/assets/3c3bc6a8-f6bc-4032-97d0-7243540cfb90" /> ## After <img width="1050" height="598" alt="Screenshot 2026-05-12 at 15 31 17" src="https://github.com/user-attachments/assets/c66c9ce5-d1ea-4f1d-b2fe-07979e2261f7" /> <img width="1068" height="503" alt="Screenshot 2026-05-12 at 15 31 09" src="https://github.com/user-attachments/assets/ddd9eed8-812b-47d6-96cb-b019b807991b" />	2026-05-12 16:01:50 +00:00
Etienne	79b612ee12	Billing - Add default ff (#20480)	2026-05-12 10:16:38 +00:00
Félix Malfait	4da8878697	feat: add email forwarding message channel (#19535) ... ## Summary - Add email forwarding as a new message channel type, allowing users to forward emails from addresses like `support@mycompany.com` into Twenty - Inbound emails arrive via S3 (SES → S3 bucket), are polled by a cron job, parsed, routed to the correct workspace/channel, and persisted as messages - Dedicated settings page at `/settings/accounts/new-email-forwarding` where users provide their source email handle and receive a unique forwarding address - Forwarding channels bypass the IMAP/mailbox sync state machine — they skip cron-driven sync, relaunch, and message-list-fetch lifecycle stages - Forwarding address section shown at the top of the Emails settings page so users can find/copy their addresses after initial setup - Tab names for forwarding channels display the user-provided handle (e.g. `support@mycompany.com`) instead of the internal routing address - Shared utilities extracted from IMAP driver: `extractThreadId`, `extractParticipants`, `extractAddresses` to avoid code duplication - Uses the existing S3 bucket (STORAGE_S3_*) with `inbound-email/` prefix — no separate bucket needed - Feature gated behind `isEmailForwardingEnabled` client config (requires `INBOUND_EMAIL_DOMAIN` + S3 storage) ## New backend modules - `InboundEmailS3ClientProvider` — lazy-initialized S3 client using existing storage config - `InboundEmailStorageService` — S3 operations (get, move to processed/unmatched/failed) - `InboundEmailParserService` — RFC 822 parsing via `postal-mime`, builds `MessageWithParticipants` - `InboundEmailImportService` — orchestrates download → parse → route → persist → archive - `MessagingInboundEmailPollCronJob` — polls S3 `incoming/` prefix, enqueues import jobs - `CreateEmailForwardingChannelInput` DTO — accepts user-provided `handle` ## New frontend components - `SettingsAccountsNewEmailForwardingChannel` — dedicated page with handle input form + forwarding address result - `SettingsAccountsEmailForwardingSection` — forwarding address list on the Emails settings page - `useConnectedAccountHandleMap` — shared hook for account ID → handle lookup - `useCreateEmailForwardingChannel` — mutation hook accepting handle parameter ## Test plan - [x] 17 unit tests for inbound email import service (all outcomes: imported, unmatched, loop_dropped, unconfigured, parse_failed, persist_failed) - [x] 16 tests for `computeSyncStatus` including EMAIL_FORWARDING cases - [x] 11 tests for `extractEnvelopeRecipient` utility - [x] TypeScript typechecks pass for both twenty-server and twenty-front - [x] Lint passes for both packages - [ ] Manual: create forwarding channel, verify forwarding address generated - [ ] Manual: send email to forwarding address, verify it appears in Twenty https://claude.ai/code/session_01KpyF6p4cUEnuaT4h8DP5Pm --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Copilot Autofix powered by AI <223894421+github-code-quality[bot]@users.noreply.github.com> Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com> Co-authored-by: neo773 <62795688+neo773@users.noreply.github.com> Co-authored-by: neo773 <neo773@protonmail.com>	2026-05-09 11:00:57 +02:00
Etienne	86eab9ac24	Billing - remove default feature flag (#20365)	2026-05-07 16:48:44 +00:00
Etienne	9fc5be1c4c	Billing - Migrate from Stripe metering (#20298) ... **Overall strategy** **1. Introduce “Billing V2” behind a workspace flag** Gate the new model with FeatureFlagKey.IS_BILLING_V2_ENABLED so existing workspaces stay on the old behavior until they’re migrated or explicitly on V2. **2. Replace workflow metered SKUs with a resource-credit product** Conceptually, billable “workflow execution” usage is not the primary subscription line item anymore. Add a RESOURCE_CREDIT product (and keep WORKFLOW_NODE_EXECUTION as deprecated for the transition). Usage and limits are expressed through credit buckets (e.g. price metadata like credit_amount), so one product can represent pooled credits instead of a narrow workflow-only meter. **3. Migrate subscriptions in two layers** Schema/catalog: persist extra price metadata (instance upgrade) so the server knows credit amounts and can match Stripe prices to the new model. Per workspace: the registered workspace command upgrade:2-2:migrate-to-billing-v2 finds subscriptions that still have WORKFLOW_NODE_EXECUTION, swaps those items to the right RESOURCE_CREDIT prices (using existing Stripe schedule + BillingSubscriptionUpdateService stack), then treats the workspace as V2 (flag). Workspaces without that legacy item or without a subscription are skipped. **4. Unify subscription lifecycle + usage on the server** **5. Refresh the product surface in Settings** Test : - [x] Subscribe v1 + Update subscribe + Migrate - [x] Subscribe v2 + Update subscribe	2026-05-07 15:42:11 +00:00
Charles Bochet	10876138d2	refactor: stop reading joinColumnName from relation field settings (#20304) ... ## Summary `joinColumnName` on relation field settings is always derivable from the field name (and the target object name for morph relations). This PR stops reading it from settings anywhere in production code; the stored value is no longer used. The settings field is **not** removed from data yet — a follow-up can drop it once we are confident nothing depends on the stored value. ## Helpers The helpers are split by layer because frontend and backend hold morph relations differently: the frontend has a base name plus a `morphRelations[]` array, the backend has one row per target with the name already morph-resolved. | Helper | Layer | When to use | |---|---|---| | `computeRelationGqlFieldJoinColumnName` | Shared / frontend (`gqlField`) | Non-morph relation on the frontend. | | `computeMorphRelationGqlFieldName` | Shared / frontend (`gqlField`) | Need the per-target morph gqlField name (e.g. `targetCompany`). | | `computeMorphRelationGqlFieldJoinColumnName` | Shared / frontend (`gqlField`) | Per-target morph join column on the frontend. Prefer over the non-morph helper for any morph field — it forces the per-target inputs. | | `computeMorphOrRelationFieldJoinColumnName` | Backend (`FlatFieldMetadata.name`) | Any backend read or write — the flat name is already morph-resolved, so one helper covers both cases. | | `computeMorphRelationFlatFieldName` | Backend (`FlatFieldMetadata.name`) | **Mutation paths only** (create / update / object rename). Reads consume the stored `field.name` and never call this. | ## Test plan - [x] Typecheck and lint (front, server, shared) - [x] Existing unit tests pass - [ ] CI green	2026-05-07 09:53:00 +02:00