12518 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
ishan-karmakar	12bd695c59	Change host port in docker-compose.yml	2026-06-07 17:38:49 +00:00
ishan-karmakar	17347736be	Update docker-compose for our purposes	2026-06-07 17:34:40 +00:00
claude[bot]	dfe0b5bfd4	chore(server): rename TypeORM migrations dir to legacy-typeorm-migrations-do-not-add (#21295) ... ## What Renames the historical TypeORM migrations directory so it's obvious at a glance the path is frozen. - `packages/twenty-server/src/database/typeorm/core/migrations/common/` → `…/typeorm/core/legacy-typeorm-migrations-do-not-add/common/` - `packages/twenty-server/src/database/typeorm/core/migrations/billing/` → `…/typeorm/core/legacy-typeorm-migrations-do-not-add/billing/` - `packages/twenty-server/src/database/typeorm/core/migrations/utils/` — **left in place** (those SQL helpers are still imported by current instance/workspace commands, see e.g. `1-21-workspace-command-1775500002000-add-global-key-value-pair-unique-index.command.ts`) - Updates `core.datasource.ts` globs to the new path and adds an inline comment explaining the dir is frozen - Adds a `README.md` at the new dir pointing readers at `UPGRADE_COMMANDS.md` and the active `upgrade-version-command/` tree ## Why The TypeORM migration system was replaced by fast/slow instance commands + workspace commands (PR #19356), but `typeorm/core/migrations/common/` still looked structurally identical to an active migrations folder, with new files merging in as recently as last week. New contributors — and AI agents — kept inferring it was the active path and adding TypeORM `MigrationInterface` files. See #21286 for the most recent instance. This is recommendation **1b** from #21286 (`https://github.com/twentyhq/twenty/pull/21286#discussion_r3369356792`). A renamed folder is the single strongest signal — no one instinctively adds to a `do-not-add` directory. ## Notes - Imports from `src/database/typeorm/core/migrations/utils/…` keep working because `utils/` did not move. - No behavior change at runtime: TypeORM loads the same files via `_typeorm_migrations`, just from the new path. ## Test plan - [ ] CI green - [ ] `nx build twenty-server` succeeds - [ ] Fresh `nx database:reset twenty-server` from a clean DB still replays the legacy TypeORM migrations (i.e. `_typeorm_migrations` rows get inserted at boot/init) - [ ] Spot-check that an instance command that imports from `migrations/utils/` still resolves at build time (e.g. `1-21-workspace-command-1775500002000-add-global-key-value-pair-unique-index.command.ts`) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com> Co-authored-by: Félix Malfait <FelixMalfait@users.noreply.github.com>	2026-06-07 14:54:36 +02:00
neo773	186d5b8faa	revert #21177 (#21284)	2026-06-06 14:49:55 +02:00
Valeriy Proklov	011afa6011	Allow kanban cross-column drag when sorting is enabled (#21025) ... ## Summary This PR allows kanban cards to be dragged across columns while sorting is enabled. Previously, any board drag while a sort was active opened the “Remove sorting?” modal. That makes sense for same-column reordering, because manual reorder conflicts with the active sort. But for cross-column moves, the user is changing the grouped field, not trying to manually reorder the destination column. With this change: - Same-column drag with sorting enabled still opens the existing remove-sorting modal. - Cross-column drag with sorting enabled updates only the group field. - The destination column keeps using the active sort to determine where the card appears. - Unsorted board drag behavior continues to update `position` as before. ## Why On sorted kanban boards, moving a card to another column is a valid workflow even though manual reordering is not. The previous guard blocked both cases because it only checked whether sorting was active, not whether the card stayed inside the same column. ## Implementation The drop behavior now distinguishes between: - sorted same-column drops, which remain blocked - sorted cross-column drops, which are allowed without a position update - unsorted drops, which keep the existing position-update behavior A small helper captures that decision and has focused unit coverage. ## Validation - Manually verified sorted cross-column drag persists after refresh. - Manually verified sorted same-column drag still opens the remove-sorting modal. - Manually verified unsorted same-column drag still reorders cards. - Manually verified unsorted cross-column drag still moves cards. - Ran focused Jest coverage for the sorted board drop decision. - Ran formatting and oxlint checks on touched frontend files. - Ran `twenty-front` typecheck. - Ran `twenty-front` production build. Co-authored-by: Félix Malfait <felix.malfait@gmail.com> Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-06 14:22:57 +02:00
Félix Malfait	a2fa941ce3	chore(twenty-front): remove dead SettingsAiMCP component and covers (#21281) ... ## What `SettingsAiMCP` is dead code — nothing imports or renders it. The redesign moved MCP setup to the **APIs & Webhooks** page (`SettingsMcpSetup`, on the MCP tab), and the AI settings page now **deep-links** there (`ApiWebhooks#mcp`) instead of rendering this component. Removes the orphaned component and its two cover SVGs: - `src/pages/settings/ai/components/SettingsAiMCP.tsx` - `public/images/ai/ai-mcp-cover-{light,dark}.svg` ## Notes - Verified nothing references the component or the SVGs in source (only stale `.po` source-reference comments remain, which `lingui` extraction reconciles separately — not hand-edited here). - The hero on the APIs & Webhooks page (incl. its MCP tab) is unaffected; that's the `playground/cover` image.	2026-06-06 12:23:42 +02:00
Félix Malfait	898713bd49	fix(server): finalize dangling tool calls when persisting agent chat messages (#21276) ... ## Problem Interrupting an AI chat turn mid tool-call batch permanently bricks the thread. Every subsequent message fails with: > Tool results are missing for tool calls toolu_…, toolu_… ## Root cause When the model fires a parallel batch of tool calls, it streams all the calls first, then results come back one by one. If the stream is aborted (user hits stop, credit cutoff, etc.) after only some have resolved, the AI SDK's `onFinish` still fires with the partial assistant message — including tool parts left in `input-available` state (a tool call with no result). `addMessage` persists that message verbatim. On the next turn the history is rebuilt and `streamText` validates it: every `tool-call` must be cleared by a `tool-result` before the next user message, or it throws `MissingToolResultsError` (`ai/dist`, the `MissingToolResultsError` check). The orphaned calls are now in the DB, so the thread fails on every turn from then on. ## Fix Enforce the invariant at the single write chokepoint. Every chat message is persisted through `AgentChatService.addMessage`, so `finalizeDanglingToolParts` runs there once: any tool part still in `input-available` is rewritten to `output-error` ("Tool execution was interrupted.") before mapping to DB rows. `output-error` converts to a real `tool-result`, so the persisted turn is always self-consistent and the next request is valid. Interrupted calls are kept (not dropped) and surfaced as errored rather than perpetually "running" — honest, since a partially-executed call may have committed side effects the model should be able to reconcile. One guard at one point covers every abort source — no read-side patching, no migration, no schema change. ## Caching impact None on the happy path. A completed turn has no `input-available` parts, so the helper is a no-op and the persisted bytes (and therefore the cached prefix) are identical to before. For an interrupted turn, the finalized content is deterministic and written once, so it caches cleanly on the following request and stays stable across later turns — there is no scenario where this invalidates an existing cache entry. Net effect: turns a hard failure into a normally-cached continuation. ## Testing - New unit test covering finalize / no-op cases (7 cases, passing) - `oxlint --type-aware` + `oxfmt` clean on changed files	2026-06-06 11:22:45 +02:00
Félix Malfait	4658d44d8b	fix(settings): ship borderless hero cover images (#21277) ... ## What The settings discovery hero images (AI, Applications, Page Layouts, Members, Data Model, APIs & Webhooks) baked the rounded border into the pixels — transparent rounded corners plus a 1px edge stroke. Rendered inside `Card rounded` — which already draws a 1px border + border-radius and clips children with `overflow: hidden` — this produced a doubled, slightly misaligned border. This replaces all 12 files (light + dark per section) with clean full-bleed exports (opaque square corners), so the border and rounding come entirely from CSS. ## Notes - Pure asset swap, no component changes. - The MCP section's `.svg` cover is untouched (no new export provided). Billing's unused cover is left as-is. ## Verification - Each new image confirmed 1388×300, opaque square corners (no baked border), correct light/dark variant. - `Card` (twenty-ui) provides `border` + `border-radius` + `overflow: hidden`, so the square images are clipped to the rounded card.	2026-06-06 11:21:06 +02:00
Summy Kumari	a596e7d904	fix: add missing space in README heading (#21271) ... The h2 heading in README.md was missing a space between the `>` closing angle bracket and "The", causing minor formatting inconsistency. Changed: `<h2 align="center" >The #1 Open-Source CRM</h2>` To: `<h2 align="center"> The #1 Open-Source CRM</h2>` --------- Co-authored-by: Félix Malfait <felix@twenty.com>	2026-06-06 10:41:16 +02:00
Félix Malfait	91f2f08995	feat(server): unify workspace-event ingestion behind one EventSink pipeline (#21197) ... ## Why The five event-log streams (`workspaceEvent`, `pageview`, `objectEvent`, `usageEvent`, `applicationLog`) each wrote to ClickHouse through their own fire-and-forget writer (`AuditService`, `UsageEventWriterService`, and the `application-logs` driver), with the per-type knowledge (table names, normalization, access rules) spread across several modules. Three of them reimplemented the same ClickHouse insert, and the read side, the live stream, and the producers lived in different modules under two different names. This consolidates them into one `core-modules/event-logs/` subsystem (emit, write, live, read), with the per-type config in a single registry so adding an event type is roughly one file. The base Logs settings tab and free application logs shipped separately in #21180 (merged). This PR adds the unified backend, the registry, and the viewer's live mode and entitlement gating. ## Pipeline ```mermaid flowchart TB subgraph PROD["Producers"] A["auth, billing, impersonation,<br/>webhook, custom-domain"] U["usage listener"] F["logic-function executor (app logs)"] R["record CRUD (entity events)"] end EM["EventLogEmitterService<br/>createContext().insert* / dispatch()"] EQ(["entityEventsToDbQueue<br/>(existing, shared with timeline)"]) CIE["CreateEventLogFromInternalEvent"] SINK["WorkspaceEventSinkService.ingest()"] C1["ClickHouseEventSink"] C2["ConsoleEventSink"] LIVE["EventLogLiveService.publishWatched()<br/>(presence-gated)"] CH[("ClickHouse, 5 tables, async_insert")] CHAN(["WORKSPACE_EVENTS_CHANNEL"]) RS["EventLogsService (registry-driven read)"] LR["EventLogsLiveResolver"] UI["Settings > Logs"] A --> EM U --> EM F --> EM EM -->|direct| SINK R --> EQ --> CIE -->|ingest| SINK SINK --> C1 --> CH SINK --> C2 SINK --> LIVE -.->|if a viewer is watching| CHAN --> LR --> UI CH --> RS --> UI ``` ## What it does - Producers call `EventLogEmitterService.createContext().insert*()`, which builds a typed `WorkspaceEventEnvelope` and writes it through `WorkspaceEventSinkService` to the configured sinks (ClickHouse, Console) plus a presence-gated live fan-out. Record/CRUD events reach the same sink through the existing `entityEventsToDbQueue`. There is no dedicated queue; ClickHouse `async_insert` batches server-side. Writes are best-effort, as on main today. - `EVENT_LOG_TYPES[table]` is the per-type source of truth: the ClickHouse table, the required entitlement, the free-text filter column, and the row-to-GraphQL mapping. Read row shapes derive from the write rows. - Four modules along their dependency boundaries: `EventLogEmitterModule` (producer API), `EventLogIngestionModule` (sink layer), `EventLogLiveModule` (fan-out), and `EventLogsViewerModule` (the entitlement-gated GraphQL read, which is where billing/enterprise/permissions stay so producers stay light). - Logs viewer: per-table columns, filters (text, date, record), live mode, and an upgrade card that points to Billing on Cloud or the Admin Panel on self-hosted. Application logs are free on every plan; the other four require the `AUDIT_LOGS` entitlement (with a `NO_ENTITLEMENT` fallback to the upgrade card). - Renames `AuditService` to `EventLogEmitterService`, and the generic `Monitoring` event to a typed `Impersonation` event (`level` + `action`). - Removes `UsageEventWriterService`, the `application-logs` driver/module, and `AuditService`'s direct inserts. ## Durability Writes are best-effort, the same as main today (the old writers were fire-and-forget). A dedicated queue was tried mid-PR and removed: `async_insert` already batches server-side, so the queue only added durability, which isn't a requirement right now. The `EventSink` seam keeps a durable transport (e.g. a Redis-Streams buffer) easy to add later without touching producers. ## Out of scope S3 peer sink (seam only), Postgres or any second read path, `ReplicatedMergeTree`, ClickHouse table-schema changes, and the record-data `EVENT_STREAM_CHANNEL` (unchanged, separate concern). ## Testing Unit tests cover the registry definitions and row normalization, the entitlement gating, the envelope builders, and the producers. Integration tests cover the write paths (record create produces an `objectEvent`; the track mutation produces a `workspaceEvent`) and the read/query path across all five tables. Verified with typecheck, lint, a server boot, and GraphQL/SDK codegen.	2026-06-06 10:32:56 +02:00
martmull	6c65d26ced	feat(app-dev): add dry-run preview to dev sync (#21251) ... Split out of #21240. Stacked on #21250 (review/merge that first). `yarn twenty dev --once --dry-run` computes the migration plan and prints the diff **without applying anything** (no migration, no app-record update, no SDK generation). Also renders the diff on a normal `dev --once` sync. <img width="646" height="179" alt="image" src="https://github.com/user-attachments/assets/59f3ddcd-2a5b-4b8a-b21a-c659abe16af0" />	2026-06-05 17:49:02 +00:00
neo773	bfb83e93b2	fix(metadata): resolve junction targets order-independently during mgration (#21193) ... A junction relation points at a target field on the join object that another action may create later (two junctions into the same join reference each other). The builder validator now also looks up the target in the to be created set, and the runner mints every field id up front so the target resolves regardless of action order, the same way relation pairs are already handled. --------- Co-authored-by: Félix Malfait <felix@twenty.com>	2026-06-05 17:32:25 +00:00
Charles Bochet	20d9244639	fix(server): gate viewFilter.relationTargetFieldMetadataId behind its 2.6 upgrade command (#21267) ... ## Problem Self-hosted upgrades crossing 2.6 (e.g. `2.4 → 2.6/2.9`) can abort with: ``` column ViewFilterEntity.relationTargetFieldMetadataId does not exist at WorkspaceFlatViewFilterMapCacheService.computeForCache at WorkspaceCacheService.recomputeDataFromProvider [UpgradeSequenceRunnerService] Workspace steps ended with 1 failure(s). Aborting ``` This is **Failure #1** from #20841 — the counterpart to the role-permission cache crash fixed in #21257 (Failure #2). Same shape: a workspace **cache recompute runs mid-upgrade and reads schema that the target version's migration hasn't applied yet**. ## Root cause `ViewFilterEntity.relationTargetFieldMetadataId` is added to `core.viewFilter` only at the **2.6.0** cursor (`AddRelationTargetFieldMetadataIdToViewFilterFastInstanceCommand`, ts `1798000005000`). But the workspace cache recompute SELECTs every column of the entity, and it runs during *earlier* (2.5) workspace steps. Unlike `RolePermissionFlagEntity.permissionFlag`, this column has **no `@WasIntroducedInUpgrade` gate**, so the proxy can't hide it — and the SELECT fails when the column isn't there yet. There are three `IF NOT EXISTS` backport commands (2.3/2.4/2.5) meant to add the column sooner, but they use **low timestamps** that sort to the front of their version bundles. An instance whose cursor has already advanced past those positions (e.g. it reached 2.4, or a prior failed attempt advanced it through 2.5 instance commands) treats them as already-applied and **skips them** — so the column is never created, yet the entity keeps selecting it. ## Fix Gate the column with `@WasIntroducedInUpgrade` pointing at the **2.6.0** command that adds it: ```ts @WasIntroducedInUpgrade({ upgradeCommandName: '2.6.0_AddRelationTargetFieldMetadataIdToViewFilterFastInstanceCommand_1798000005000', }) @Column({ nullable: true, type: 'uuid', default: null }) relationTargetFieldMetadataId: string | null; ``` `UpgradeAwareRepositoryProxy` then hides the column from reads while the cursor is < 2.6, so the cache recompute simply omits it — no crash — and it becomes visible once the 2.6.0 command has run (where it's guaranteed to exist). Gating to **2.6.0** specifically (not the earlier backports) is what fixes the cursor-skip case: 2.6.0 is the first point where the column is reliably present regardless of whether the backports ran. Validator-safe: the referenced command resolves to a real step (`computeCommandName` = `${version}_${className}_${timestamp}`), so `validate-upgrade-aware-entity-decorators` accepts it. The existing backport commands are left untouched (committed instance commands). ## Recovery for already-stuck instances This prevents *new* failures. An instance already aborted mid-upgrade needs the column added manually before retrying: ```sql ALTER TABLE core."viewFilter" ADD COLUMN IF NOT EXISTS "relationTargetFieldMetadataId" uuid; DELETE FROM core."upgradeMigration" WHERE status='failed'; ``` then re-run the upgrade on a build that includes this fix. Refs #20841 Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-05 18:56:02 +02:00
Thomas Trompette	51e3eddb29	Add job queue latency histogram metric (#21260) ... ## Summary - Records the time each job spends waiting in the queue (enqueue → processing start) as an OpenTelemetry histogram - Metric is broken down by `queue` and `job_name` attributes, enabling per-queue p50/p95/p99 latency analysis - Uses BullMQ's native `job.timestamp` for accurate measurement ## Test plan - [x] Deploy to staging and verify `job/latency-ms` metric appears in ClickHouse `otel_metrics_histogram` table - [x] Confirm Grafana dashboard can query the histogram data	2026-06-05 16:04:54 +00:00
Etienne	27db8bbae4	fixes - remove billing cancellation at trial end + disable ai chat if suspended (#21261) ... - Remove billing cancelation if trial is ended (subscription activated) - Disable AI Chat use if workspace suspended	2026-06-05 15:34:12 +00:00
martmull	84ba7eb8dc	fix(app-dev): serialize dev sync per workspace with a cache lock (#21250) ... Split out of #21240. Stacked on #21249 (review/merge that first). Concurrent `syncApplication` calls on the same workspace could interleave their metadata migrations and leave metadata partially applied. Wrap the manifest sync in a per-workspace cache lock (`app-sync:<workspaceId>`), mirroring the install path. The rate-limit throttle stays outside the lock. --------- Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-05 17:30:55 +02:00
Charles Bochet	a3d73740a1	fix(server): guard role-permission cache against stripped permissionFlag relation during upgrade (#21257) ... ## Problem Self-hosted upgrades that jump versions (e.g. `2.4 → 2.7/2.9`) abort with: ``` TypeError: Cannot read properties of undefined (reading 'universalIdentifier') at WorkspaceRolesPermissionsCacheService.hasSettingsGatedObjectPermissions at WorkspaceRolesPermissionsCacheService.computeForCache at WorkspaceCacheService.recomputeDataFromProvider ``` Reported in #20841 (Failure #2). The sequence aborts mid-upgrade and leaves the DB in a half-migrated state. ## Root cause The per-workspace **cache recompute runs at a `2.5.0` workspace step — before the `2.6` schema migrations apply**. At that cursor: - `RolePermissionFlagEntity.permissionFlag` is `@WasIntroducedInUpgrade('2.6.0_LinkRolePermissionFlagToPermissionFlag…')`, so `UpgradeAwareRepositoryProxy` **strips the relation** (`[upgrade-proxy] strip relation RolePermissionFlagEntity.permissionFlag` in the logs) → `permissionFlag` is `undefined`. - `hasSettingsGatedObjectPermissions()` then does an **unguarded** `rolePermissionFlag.permissionFlag.universalIdentifier` → throws. The crash only manifests when a workspace has **≥1 `rolePermissionFlag` row** (custom roles with gated settings perms / SDK `defineRole`). A vanilla seed has an empty table, so `.find()` over `[]` never dereferences anything — which is why it didn't reproduce on a clean instance. A null-safe fallback to the legacy `flag` column used to exist here; it was dropped in #20730. ## Fix Resolve the flag's universal identifier through a small helper that falls back to the legacy `flag` column (only removed in `2.7.0`) when the relation is unavailable: ```ts private getRolePermissionFlagUniversalIdentifier( rolePermissionFlag: RolePermissionFlagEntity, ): string { // The `permissionFlag` relation is stripped during upgrades until the 2.6.0 // cursor (@WasIntroducedInUpgrade), so fall back to the legacy `flag` column. return ( rolePermissionFlag.permissionFlag?.universalIdentifier ?? SystemPermissionFlag[rolePermissionFlag.flag] ); } ``` `SystemPermissionFlag[flag]` yields the same UUID the relation would, so the comparison stays in a single space and the computed permission is exact (not an over-grant). Correct at every transitional cursor: pre-`2.6` (relation stripped → use `flag`), `2.6` (both present → relation wins), post-`2.7` (`flag` removed → relation wins). ## Reproduction & validation Locally jumped a real `2.4.0` DB → `v2.9.0` build via `yarn command:prod upgrade`: | Scenario | Result | | --- | --- | | Empty `permissionFlag` (vanilla seed) | passes (no crash) | | **+1 flag row**, current code | `TypeError … universalIdentifier` → **3 succeeded, 1 failed** | | Same fixture, **this fix** | **16 succeeded, 0 failed**, DB fully migrated to 2.9.0 | `nx typecheck twenty-server` clean; existing cache-service unit tests pass; app boots on the upgraded DB. ## Scope / follow-up This fixes **Failure #2**. **Failure #1** in the same issue (`viewFilter.relationTargetFieldMetadataId` selected before its column exists) is a separate instance of the same theme — cache recompute reading "future" schema before migrations run — and is worth a follow-up. A more durable systemic fix would defer the workspace cache recompute until after all schema-adding migrations; this PR is the low-risk, backport-friendly fix for the immediate breakage. > Note: an earlier bot branch (`sonarly-39738-fixupgrade-guard-role-permission-flag-relation`) proposed the same fallback inline. This PR supersedes it with a named helper + a focused comment. Fixes #20841 Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-05 14:45:17 +00:00
Thomas Trompette	0d3c7a47af	fix: guard against undefined logicFunctionId when destroying workflow CODE steps (#21256) ... ## Summary - Adds `isDefined` guard in `handleLogicFunctionSubEntities` to skip CODE steps with undefined `logicFunctionId` instead of crashing - Adds same guard in `runWorkflowVersionStepDeletionSideEffects` for consistency - Rejects CODE steps in `create_complete_workflow` AI tool at runtime to prevent creating workflows with missing logic functions in the first place Fixes `"Logic function with id undefined not found"` INTERNAL_SERVER_ERROR when destroying workflows whose CODE steps were created via `create_complete_workflow` without a proper logic function. ## Test plan - [x] Destroy a workflow that has a CODE step with undefined logicFunctionId → should succeed silently - [x] Try creating a workflow with a CODE step via `create_complete_workflow` tool → should return error message - [x] Normal workflow destroy with valid CODE steps still deletes the logic function	2026-06-05 14:30:19 +00:00
twenty-pr[bot]	2dbdd72e65	chore: bump version to 2.11.0 (#21259) ... ## Summary - Moves current version to previous versions array - Sets TWENTY_CURRENT_VERSION to the new version - Updates TWENTY_NEXT_VERSIONS with the next minor version - Bumps twenty-client-sdk, twenty-sdk, and create-twenty-app to the same version ## Checklist - [ ] Verify version constants are correct - [ ] Verify npm package versions match Co-authored-by: Github Action Deploy <github-action-deploy@twenty.com>	2026-06-05 16:47:40 +02:00
martmull	f20d04eb6e	feat(app-dev): surface metadata diff in dev sync and name failing migration actions (#21249) ... Split out of #21240. - Render the applied metadata changes (created/updated/deleted + identifiers) in the dev sync output instead of a bare `✓ Synced`. - Include the failing entity's `universalIdentifier` in `WorkspaceMigrationRunnerException` messages so conflicts are diagnosable. <img width="637" height="114" alt="image" src="https://github.com/user-attachments/assets/61422a16-370c-4e9b-a2f6-c29ce17f3b1b" /> <img width="497" height="104" alt="image" src="https://github.com/user-attachments/assets/d493c398-da29-49c9-ac5e-aa0f26cd7389" /> <img width="593" height="127" alt="image" src="https://github.com/user-attachments/assets/15e26edc-c0e4-4427-bd34-909040e970c9" /> --------- Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-05 16:35:50 +02:00
nitin	f72898063a	upgrade command patch - warn instead of throw when no calendarEvent object found in the workspace (#21258) sdk/v2.10.0 twenty/v2.10.0	2026-06-05 16:32:16 +02:00
nitin	e485b679ea	[Call Recording] Add standard object (#21158) ... Adds **Call Recording** as a first-class standard object (Twenty's flat-metadata standard-object system), with a hidden junction to calendar events and a backfill command for existing workspaces. Everything is gated behind the `IS_CALL_RECORDING_ENABLED` feature flag. ### What's included - **`CallRecording`**: audio/video files, transcript, status, recording policy, timing, external bot/recording ids. Label identifier is `meetingOccurrenceKey`. - **`CallRecordingCalendarEventAssociation`**: hidden junction linking a recording to a calendar event (dedupes one bot to many subscribers of the same meeting). - Full metadata graph via the flat-metadata builders: fields, indexes, views, view fields/groups, record page layout, and navigation items. - **Metadata-only reverse relation** on `CalendarEvent`: present in standard metadata, omitted from the TS entity class to avoid expanding recursive nested-insert types. - **Upgrade command (2.9.0)** backfilling active/suspended workspaces: - Creates the full graph; idempotent (skips when it already exists). - Moves a colliding custom `callRecording` object aside to `callRecordingOld` (numeric suffix if that name is also taken). - Navigation items (commands) are flag-gated by `universalIdentifier`, so a custom object reusing the name is never gated. ### QA Run locally against existing workspaces (with and without a name collision) and a freshly created workspace: - [x] Backfill, collision: custom `callRecording` renamed to `callRecordingOld`; standard graph created. - [x] Backfill, no collision: standard graph created; unrelated custom object untouched. - [x] Idempotent: re-run is a no-op, with no duplicate metadata and counts unchanged. - [x] New workspace via `init()` produces an identical graph to the backfill (`universalIdentifier` set-diff = 0). - [x] Label identifier (`meetingOccurrenceKey`) holds position 0 in non-widget views. - [x] Nav items gated behind the feature flag; collision-renamed object's nav expression re-pointed to its new name. - [x] Unit tests cover collision name resolution and nav-gating logic.	2026-06-05 13:02:50 +00:00
Paul Rastoin	a78b319877	sdk/v* twenty/v* namespaces (#21247) ... # Introduction Removed never used release dispatch workflow Now assuming that anyone releasing will create both twenty and npm family tags Will create a workflow to ease this later We will now start to have several github releases, one per namespace	2026-06-05 12:40:50 +00:00
Félix Malfait	c3dd6b25a6	fix: use canonical oxlint rule id in lint-disable directives (#21253) ... ## What Many `oxlint-disable` / `eslint-disable` directives across the repo carry a corrupted rule id — `@typescripttypescript/<rule>` — most likely a find-and-replace accident that mangled the eslint-era `@typescript-eslint/` prefix. oxlint matches disable directives **loosely by rule name**, so these still suppress in practice (not a silent no-op), but the id is malformed and misleading. ## Change Replace them with the **canonical oxlint id** `typescript/<rule>` — matching the plugin name and rule keys declared in `.oxlintrc.json` — **127 files, 262 directives**: | rule | count | | --- | ----- | | `typescript/no-explicit-any` | 250 | | `typescript/ban-ts-comment` | 6 | | `typescript/no-misused-promises` | 4 | | `typescript/no-empty-object-type` | 2 | - `twenty-server`: 122 files - `twenty-front`: 5 files Comment-only — no code or runtime changes. ## Verification `oxlint --type-aware -c .oxlintrc.json` reports **0 warnings / 0 errors** for both `twenty-server` and `twenty-front`. Every changed line is exactly the id correction inside a disable directive (262 insertions / 262 deletions, no collateral edits). > Addresses the cubic review, which flagged that the canonical oxlint id is `typescript/...` (no `@`). Worth noting the original `@typescripttypescript/` was not actually a silent no-op — oxlint matches these directives loosely by rule name — but `typescript/` is the correct, config-aligned id.	2026-06-05 13:52:32 +02:00
Raphaël Bosi	6f9b59b224	Scaffold twenty-new-ui (#21236) ... Scaffolds `twenty-new-ui`, the next-gen replacement for `twenty-ui`, on **SCSS** Modules + **Base UI** (no Linaria). - **Tooling**: Vite lib build, subpaths mirror twenty-ui, typed SCSS Modules, Storybook + axe a11y, size-limit, Nx targets. - **Theme**: single token source → nx generateTheme emits the CSS vars + accessor; parity test asserts token-for-token match with twenty-ui. Migrated a first `Toggle` component with its stories to allow @charlesBochet to wire the new pixel-diff system. --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-05 10:42:57 +00:00
Abdullah.	b60a91a075	fix(website): render releases from local notes, drop GitHub gate (#21238) ... The releases page gated visible notes on fetchLatestGithubReleaseTag(); when that unauthenticated GitHub call was rate-limited at build (common on shared Cloudflare build IPs, no GITHUB_TOKEN), it returned null and getVisibleReleaseNotes returned [], rendering 'No releases are visible yet for the current published version' — the exact prod symptom. force-static made each deploy a coin flip. Committed MDX (+images) is the single source of truth, so gate visibility on nothing: render all local notes deterministically with no network call. Removes the dev/prod divergence and deletes the now-dead fetch-latest-release-tag.ts and get-visible-releases.ts.	2026-06-05 08:59:40 +00:00
Charles Bochet	cd540098f1	fix: pass reference_commit to Argos to resolve orphan PR builds (#21245) ... ## Summary - Fixes Argos CI builds showing as "Orphan" (no reference branch) for PR builds - Computes the merge-base SHA between the PR head and `main` using the GitHub API (`compareCommitsWithBasehead`) in the dispatch workflow - Passes `reference_commit` in the `ci-privileged` dispatch payload so it can be forwarded to the Argos upload API ## Context PR builds on Argos were showing as "Orphan" because `ci-privileged` (where the actual Argos upload happens) has no git history of the `twenty` repo — it cannot compute the merge-base locally. Without a `referenceCommit`, Argos can't determine which `main` build to compare against. The local `visual-diff.sh` script already passes `ARGOS_REFERENCE_COMMIT` via `git merge-base HEAD main`, but the CI pipeline was missing this. This PR adds equivalent logic using the GitHub API (no checkout needed). ## Note for ci-privileged The `upload-to-argos.ts` script in `ci-privileged` needs a corresponding update to read `reference_commit` from the dispatch payload and pass it as `referenceCommit` in the Argos API call: ```typescript referenceCommit: process.env.REFERENCE_COMMIT || undefined, ``` ## Test plan - [ ] Verify the workflow runs successfully on a PR (merge-base step computes a SHA) - [ ] Confirm Argos PR builds are no longer marked as "Orphan" after the ci-privileged counterpart is updated	2026-06-05 10:51:16 +02:00
Félix Malfait	1b30983307	fix(settings): gate the AI settings page on AI_SETTINGS, not the chat flag (#21239) ... ## Summary Closes #21229. The two AI role permissions behaved **opposite to their labels**. The trap is that the flag's code name is the inverse of its UI label: | `PermissionFlagType` | UI label | Section | Means | |---|---|---|---| | `AI` | **"Ask AI"** | Actions | End-user: chat with AI | | `AI_SETTINGS` | **"AI"** | Member / settings | Admin: configure AI agents | Before this PR (on `main`): - `AI` ("Ask AI", chat) gated **both** the AI chat **and** the AI settings page. - `AI_SETTINGS` ("AI", configure agents) gated **nothing** the user could see. So a chat-only user could reach the whole AI **configuration** page, and toggling the "AI" settings permission did nothing — exactly the misalignment reported in #21229. ## Root cause `PermissionFlagType.AI` *reads* like "the AI permission", so it looks like the natural gate for the AI settings page — but it's actually the **chat** flag. The settings page (nav item + route) had been pointed at `AI` in #21072 to match the Overview stats query (`findWorkspaceAiStats`), which was itself mis-gated on `AI`. Both the stats query and the rest of the settings surface are admin/config features, so they belong on `AI_SETTINGS`. ## Changes All three move the **AI settings surface** from the chat flag (`AI`) to the settings flag (`AI_SETTINGS`); chat keeps following `AI`: - `useSettingsNavigationItems.tsx` — AI nav item → `AI_SETTINGS` - `SettingsRoutes.tsx` — AI settings route group → `AI_SETTINGS` - `ai-workspace-stats.resolver.ts` — `findWorkspaceAiStats` (settings-only, drives the Overview tab) → `AI_SETTINGS` After this: the "AI" permission controls the AI settings page + its Overview; the "Ask AI" permission controls the chat. Both toggles now match their labels. ## Test plan - [ ] Role with **only "Ask AI"** (`AI`): AI chat tabs/pane visible; **Settings → AI is hidden** and the route is not reachable. - [ ] Role with **only "AI"** (`AI_SETTINGS`): Settings → AI is visible, Overview stats load; chat nav is hidden. - [ ] Admin (both flags): everything works as before. ## Known follow-ups (out of scope — pre-existing, shared endpoints) These remain on `AI` because they're shared with non-settings surfaces and need either OR-gating or a resolver split, so a role with `AI_SETTINGS` but **not** `AI` still can't use them yet: - `getAiSystemPromptPreview` (Models/Prompts tabs) lives in the chat resolver, class-gated `AI`; NestJS guards are additive so it can't be cleanly method-overridden — it should be pulled into a settings resolver. - Agent reads `findManyAgents` / `findOneAgent` (agent create/edit forms) are class-gated `AI` and shared with the **Workflow** editor and **Roles** pages; these want a guard that accepts `AI ∨ AI_SETTINGS ∨ WORKFLOWS`.	2026-06-05 08:18:20 +00:00
martmull	128d2d394d	feat: allow apps to add view fields to existing views (defineViewField) (#21160) ... ## Summary Lets a Twenty application add **view fields (columns) to an existing view it does not own** — including standard views like the People index view — without redeclaring/owning that view. This mirrors the existing, working pattern by which an app adds a custom field to a standard object via `defineField` + `objectUniversalIdentifier`. The asymmetry being removed was purely in the manifest schema: `ViewFieldManifest` only existed *nested* inside `ViewManifest.fields[]`, so adding a view field forced declaring a `ViewManifest` — which the sync treats as a view the app creates and owns, and rejects when the UID is a standard view's. Validation, persistence, the FK aggregator machinery, and uninstall cleanup were already generic and cross-app-safe, so no engine changes were needed. ### Changes - **twenty-shared:** new top-level `StandaloneViewFieldManifest` (`ViewFieldManifest & { viewUniversalIdentifier }`), `Manifest.viewFields`, and a `SyncableEntity.ViewField` member. - **twenty-sdk:** `defineViewField` (validates `universalIdentifier` + `viewUniversalIdentifier` + `fieldMetadataUniversalIdentifier`), CLI manifest assembly of a top-level `viewFields` list, and `dev:add viewField` scaffolding. - **twenty-server:** one top-level loop over `manifest.viewFields` that reuses the existing `fromViewFieldManifestToUniversalFlatViewField` converter (already parameterized by `viewUniversalIdentifier`). No validator/persistence/aggregator changes. ### Notes for maintainers - Confirm the `Manifest.viewFields` optionality convention — implemented as a **required** array to mirror `fields`/`views`. - Two different apps adding a column for the same field to the same view conflicts on the existing unique `(fieldMetadataId, viewId)` partial index; the existing `flat-view-field-validator` duplicate check surfaces this as a structured validation error. - `dev:add viewField` scaffolding is included (was optional in the plan). ## Test Plan - [x] `twenty-shared` typecheck - [x] `twenty-sdk` 364 unit tests + `buildManifest` assembly test (rich-app fixture) + typecheck + prettier - [x] `twenty-server` typecheck + `lint:diff-with-main` - [x] **Server integration suite** `successful-manifest-update-view-field.integration-spec.ts` (4/4): - standalone view field attaches to the standard `allPeople` view without recreating it (sync succeeds, no `INVALID_VIEW_DATA`/`ENTITY_ALREADY_EXISTS`) - uninstall removes the contributed column while the standard view + its columns remain intact - duplicate `(view, field)` rejected with `METADATA_VALIDATION_FAILED` - unknown target view rejected - [x] Sibling `successful-manifest-update-field.integration-spec.ts` still green (no harness regression) 🤖 Generated with [Claude Code](https://claude.com/claude-code)	2026-06-05 08:06:30 +00:00
github-actions[bot]	ff9b5a5cad	chore: sync AI model catalog from models.dev (#21242) ... Automated daily sync of `ai-providers.json` from [models.dev](https://models.dev). This PR updates pricing, context windows, and model availability based on the latest data. New models meeting inclusion criteria (tool calling, pricing data, context limits) are added automatically. Deprecated models are detected based on cost-efficiency within the same model family. **Please review before merging** — verify no critical models were incorrectly deprecated. Co-authored-by: FelixMalfait <6399865+FelixMalfait@users.noreply.github.com>	2026-06-05 09:22:38 +02:00
Ratish jain	979047d004	fix: allow email change verification on self-hosted instances (#20123) ... fixes #20117 ## Technical Details Flow after fix: 1. User submits email change request 2. user.service.ts:517-524 calls sendVerificationEmail() with verificationTrigger: EMAIL_UPDATE 3. Guard checks: verificationTrigger === SIGN_UP → false → guard skipped 4. Verification token generated, email rendered and sent via emailService.send() 5. User receives confirmation email at new address 6. User clicks confirmation link → email update completes --- Impact - Minimal change: Only 3 lines modified in a single file - No breaking changes: Sign-up verification behavior unchanged - Security preserved: Email changes always require verification (correct security behavior) - Self-hosted friendly: Instance admins can disable sign-up verification while keeping email change verification active --------- Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-04 18:56:15 +00:00
Etienne	8bd4cbc3fd	fix(ai) - optim (#21233) ... 1. tool-registry.service.ts, Pass precomputed catalog to resolveSchemas() resolveSchemas() now accepts an optional precomputedCatalog parameter. Both getToolsByName() and getToolInfo() pass the catalog they already fetched, eliminating a redundant getCatalog() rebuild inside resolveSchemas(). 2. database-tool.provider.ts, Skip field lookup when schemas=false When building the catalog index (includeSchemas=false), getFlatFieldsFromFlatObjectMetadata() is no longer called for each of the 25 objects. The hasGroupByToolInputSchema() check is also skipped, group_by tools are always included in the index, with the real eligibility check deferred to learn_tools time. --> 100/150ms gain on learn/execute_tool execution	2026-06-04 17:27:25 +00:00
github-actions[bot]	f899660a40	i18n - docs translations (#21237) ... Created by Github action Co-authored-by: github-actions <github-actions@twenty.com>	2026-06-04 19:24:06 +02:00
Paul Rastoin	0877ba2ffd	Fix getApplicationSubAllFlatEntityMaps to prune unrelated appIds universal identifier aggregators (#21234) ... # Introduction Atm when computing the `fromAllFlatEntityMaps` we're retrieving all the applicationIds related metadata entities to build a flat entity maps scoped to them ( atm always the applicationId + twenty-standard application id ) only inter app dependency we manage for the moment A flat entity contains universal identifier aggregator to its related entities The issue was that the `getApplicationSubAllFlatEntityMaps` wasn't pruning the aggregator by app Now added a new process phase after the initial one that will check that all the aggregators contains universal identifiers that has been retrieve from the appId + appId standard intersection ## TDD test Created a very human readable ( that's a joke ) test	2026-06-04 16:53:25 +00:00
Thomas Trompette	4e1cc2d831	fix: prevent workflow from disappearing after activation (#21231) ... ## Summary - Fixes a regression from #21176 where activating a workflow caused it to disappear until page refresh - Root cause: when a draft is activated (status DRAFT→ACTIVE), `useEffectiveDraftVersionId` incorrectly treated it as a discard because the cached version was no longer DRAFT, filtering it from the versions list - Fix: only set `lastDiscardedDraftId` when `deletedAt` is actually set on the cached version, not when the status simply changes ## Test plan - [x] Open a workflow with a DRAFT version - [x] Activate the workflow → verify it does NOT disappear - [x] Discard a draft → verify header does NOT flicker between DRAFT/ACTIVE	2026-06-04 16:42:05 +00:00
martmull	c2ca90c255	feat(sdk): add runAgent() to run app agents from logic functions (#21157) ... <img width="948" height="593" alt="image" src="https://github.com/user-attachments/assets/d990fa98-3cfd-469d-ab7f-0b2d4ccf3afc" /> <img width="1361" height="802" alt="image" src="https://github.com/user-attachments/assets/1091f598-49f3-4c16-92ea-1e1c200181e2" /> ## Add `runAgent()` to the Logic Function SDK Lets an app's logic function run one of its own AI agents server-side and get the result back synchronously — reusing the existing agent executor instead of a new bespoke transport. ### Backend - New **`runAgent` GraphQL mutation** (metadata schema) in `ai-agent-execution`, wrapping the existing `AgentAsyncExecutorService.executeAgent`. Scopes the agent lookup to the calling application and runs it under an application auth context. - New `@AuthApplication()` param decorator (mirrors `@AuthWorkspace()`) — first GraphQL resolver authenticated by an **application access token**. - Guarded by `WorkspaceAuthGuard` + `SettingsPermissionGuard(PermissionFlagType.AI)`: the app's role must grant the `AI` permission flag. ### SDK - `runAgent({ agentUniversalIdentifier, prompt })` posts the mutation to `/metadata` with the app token via a new runtime GraphQL transport. Returns `{ result, hasNoMoreAvailableCredits }`. - Refactored the connections helpers onto a shared `postAppEndpoint` util (removes duplicated transport logic). ### Frontend - App install permission modal now shows an explicit consent line — _"Run AI agents and bill AI credits to your workspace"_ — when the app's role requests the `AI` flag. ### Docs - Documented `runAgent` and its `AI` permission-flag requirement in _Skills & Agents_. - Fixed outdated role-permission examples in _Roles & Permissions_ (`permissionFlags` → `permissionFlagUniversalIdentifiers`, `PermissionFlag` → `SystemPermissionFlag`). ### Test plan - [x] SDK unit tests (`run-agent.spec.ts`) — request shape, GraphQL/HTTP error handling, missing env vars - [x] `twenty-server`, `twenty-front`, `twenty-shared` typecheck + lint - [ ] Manual: install an app granting the `AI` flag, call `runAgent()` from a logic function, confirm the agent runs and credits are billed --------- Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>	2026-06-04 16:18:27 +00:00
Raphaël Bosi	36b654bab3	Scaffold people data labs enrichment app (#21175) ... # Scaffold People Data Labs enrichment app Defines the data model for enriching **Person** and **Company** with People Data Labs data. **Scaffold only** — the enrichment logic (the "mapper") follows separately; see the package README. ## Included - **Fields** on Person & Company (PDL base data set). - **Enums as SELECT / MULTI_SELECT** validated against PDL canonical files (v34.1). - **Standard-field mapping**: no `pdl*` shadow where a standard field exists. - **Location → ADDRESS**; **relation** `pdlCurrentCompany` ↔ `pdlCurrentEmployees`. - **Metadata**: `pdlId`, `pdlLikelihood`, `pdlEnrichmentStatus`, `pdlLastEnrichedAt`, `pdlRawPayload`. - Shared option constants + helper, indexes, and a view per object.	2026-06-04 15:54:38 +00:00
Raphaël Bosi	41d5d80a65	Migrate Company and Person standard fields in preparation for the enrichment app (#21171) ... # Migrate Company and Person standard fields in preparation for the enrichment app ## Why Our standard `Person`/`Company` objects accumulated fields that aren't generic to every business, while missing a more universal revenue field that essentially every CRM ships. This PR makes the **Standard application** hold a tighter, more universal set of fields, and sets the stage for a follow-up PR that introduces a **People Data Labs enrichment app** to populate them. ## What changes ### Standard fields **Demoted (Standard → Workspace Custom application)** — not generic enough to ship as standard: | Object | Field | Type | | ------- | ------------------------------ | -------- | | Company | annualRecurringRevenue (ARR) | CURRENCY | | Company | employees | NUMBER | | Company | idealCustomerProfile (ICP) | BOOLEAN | | Company | xLink (X/Twitter) | LINKS | | Person | xLink (X/Twitter) | LINKS | | Person | city | TEXT | **Added (new generic Standard field)** — present in Salesforce/HubSpot/Zoho, PDL-populatable: | Object | Field | Type | | ------- | ------------- | -------------------------------------------------------- | | Company | annualRevenue | CURRENCY (generic total revenue; replaces the niche ARR) | ### Behavior by workspace * **New workspaces:** demoted fields are gone; `annualRevenue` is **active**. * **Existing workspaces:** demoted fields are **preserved as active custom fields, data intact**; `annualRevenue` is created **inactive (opt-in)** with its column ready, so a later activation is a metadata-only toggle. ### Upgrade commands (v2.9) Three idempotent, per-workspace commands, run in timestamp order: 1. **`upgrade:2-9:move-demoted-standard-fields-to-custom-application`** (1799000040000) — re-owns the 6 demoted fields to the workspace custom application (`isCustom = true`, new `applicationId` + fresh `universalIdentifier`), keeping their data and active state. 2. **`upgrade:2-9:rename-conflicting-custom-fields`** (1799000045000) — if a workspace already has a *custom* field named `annualRevenue`, renames it to `annualRevenueCustom` (data preserved via column rename) so the standard field can be added. Skips non-custom matches. 3. **`upgrade:2-9:add-inactive-generic-standard-fields`** (1799000050000) — creates `Company.annualRevenue` on existing workspaces as inactive, guarded to skip workspaces missing the target object or where the name is still taken. **Failure model:** the workspace iterator isolates failures per workspace (one workspace failing never affects others); within a workspace the runner records per-command status and resumes on the next run, and every command is idempotent, so partial runs self-heal. ### Supporting changes * **Field-option color palette:** widened the `TagColor` union (`twenty-shared` `FieldMetadataOptions` + the field-metadata `options.input` DTO) from 10 colors to the full theme palette, benefiting any future SELECT/MULTI_SELECT field. * **Dev seeder:** * The default "Annual Recurring Revenue" dashboard widget now points at the generic `annualRevenue` field (renamed to "Annual Revenue"). * Removed the "Companies by Size (Stacked by City)" widget (relied on the demoted `employees`). * `employees` is dropped from company data seeds and re-added as a **custom** field seed, so dev workspaces still get an `employees` column matching the demoted behavior. ### Cleanup Front-end record types (`Company.ts`/`Person.ts`), the `getDisplayNameFromParticipant` test mock, metadata integration specs, the Zapier `crud_record` test, and the regenerated `get-standard-object-metadata-related-entity-ids` snapshot. ## ⚠️ Breaking change (intentional) Removes standard fields `Company.annualRecurringRevenue`, `Company.employees`, `Company.idealCustomerProfile`, `Company.xLink`, `Person.xLink`, and `Person.city` from the core GraphQL schema (replaced by `Company.annualRevenue`). This is why the breaking-changes check reports a large number of removals — `graphql-inspector` flags any removed object field plus its derived aggregate/order-by/filter/update types. **Mitigation:** the `upgrade:2-9:move-demoted-standard-fields-to-custom-application` command re-owns these fields as custom fields per workspace, preserving their name and data, so existing tenants keep working. New workspaces won't have them.	2026-06-04 15:54:04 +00:00
martmull	e0d42323af	Add more control on http trigger (#21216) ... add "new Response" utils to define response code or content type of http route triggered logic function responses follow up of https://github.com/twentyhq/twenty/pull/21214 --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-04 15:34:10 +00:00
Abdullah.	d3a1781a59	Use serialize-javascript for JSON-LD serialization on twenty-website (#21223) ... Our scanner flags the `dangerouslySetInnerHTML` in `JsonLd.tsx` as a potential XSS sink. Since JSON-LD must be emitted as raw `<script type="application/ld+json">` text (rendering it as a React child HTML-entity-escapes it and corrupts the JSON, and the site is statically generated so it must be in the SSG HTML for crawlers), `dangerouslySetInnerHTML` is the correct, Next.js-documented approach (the real fix is sanitizing the payload). This PR swaps our hand-rolled `JSON.stringify().replace(/</g, ...)` for [`serialize-javascript`](https://www.npmjs.com/package/serialize-javascript) in `isJSON` mode, the maintained library [Next.js explicitly recommends](https://nextjs.org/docs/app/guides/json-ld) for this, so the script-unsafe characters are escaped by a vetted serializer rather than custom code.	2026-06-04 14:38:18 +00:00
Thomas des Francs	70066cdcf4	Update Google Workspace and integration logo assets (#21185) ... ## Summary - Replace the Gmail and Google Calendar assets with their May 2026 icon refreshes. - Update the shared Google, Google Meet, Microsoft Outlook, Microsoft Calendar-provider, Docusign, Stripe, Tally, and Zapier logo assets. - Regenerate matching website/front raster assets at their existing dimensions. ## Preview GitHub's file diff can render some tiny transparent SVG/WebP logo diffs as nearly empty. This grid uses the final raster assets from the PR branch; Stripe and Zapier use their official favicon marks. | Logo | Preview | | --- | --- | | Gmail | <img src="https://raw.githubusercontent.com/twentyhq/twenty/bonapara/update-gmail-icon/packages/twenty-website/public/images/shared/companies/logos/gmail.webp" width="48" height="48" alt="Gmail logo" /> | | Google Calendar | <img src="https://raw.githubusercontent.com/twentyhq/twenty/bonapara/update-gmail-icon/packages/twenty-website/public/images/shared/companies/logos/calendar.webp" width="48" height="48" alt="Google Calendar logo" /> | | Google | <img src="https://raw.githubusercontent.com/twentyhq/twenty/bonapara/update-gmail-icon/packages/twenty-website/public/images/shared/companies/logos/google.webp" width="48" height="48" alt="Google logo" /> | | Google Meet | <img src="https://raw.githubusercontent.com/twentyhq/twenty/bonapara/update-gmail-icon/packages/twenty-website/public/images/shared/companies/logos/meet.webp" width="48" height="48" alt="Google Meet logo" /> | | Microsoft Outlook / Calendar | <img src="https://raw.githubusercontent.com/twentyhq/twenty/bonapara/update-gmail-icon/packages/twenty-website/public/images/shared/companies/logos/outlook.webp" width="48" height="48" alt="Microsoft Outlook / Calendar logo" /> | | Docusign | <img src="https://raw.githubusercontent.com/twentyhq/twenty/bonapara/update-gmail-icon/packages/twenty-website/public/images/shared/companies/logos/docusign.webp" width="48" height="48" alt="Docusign logo" /> | | Stripe | <img src="https://raw.githubusercontent.com/twentyhq/twenty/bonapara/update-gmail-icon/packages/twenty-website/public/images/shared/companies/logos/stripe.webp" width="48" height="48" alt="Stripe logo" /> | | Tally | <img src="https://raw.githubusercontent.com/twentyhq/twenty/bonapara/update-gmail-icon/packages/twenty-website/public/images/shared/companies/logos/tally.webp" width="48" height="48" alt="Tally logo" /> | | Zapier | <img src="https://raw.githubusercontent.com/twentyhq/twenty/bonapara/update-gmail-icon/packages/twenty-website/public/images/shared/companies/logos/zapier.webp" width="48" height="48" alt="Zapier logo" /> | ## Notes - Microsoft Calendar now uses the current Outlook/M365 icon, matching the provider users connect for Microsoft calendar sync. - Docusign keeps the compact Nexus mark for the small square logo slot, regenerated from the current official Docusign lockup. - Stripe now uses the official favicon mark from stripe.com. - Zapier now uses the official square favicon mark from zapier.com. ## Sources - Gmail 2026: https://upload.wikimedia.org/wikipedia/commons/8/8f/Gmail_icon_%282026%29.svg - Google Calendar 2026: https://upload.wikimedia.org/wikipedia/commons/f/fa/Google_Calendar_icon_%282026%29.svg - Google gradient G: https://blog.google/company-news/inside-google/company-announcements/gradient-g-logo-design/ - Google Meet 2026: https://commons.wikimedia.org/wiki/File:Google_Meet_icon_(2026).svg - Microsoft 365 icon refresh: https://techcommunity.microsoft.com/blog/microsoft365insiderblog/new-microsoft-365-icons-for-the-ai-era/4458674 - Docusign logo guidelines: https://brand.docusign.com/logo - Stripe favicon: https://images.stripeassets.com/fzn2n1nzq965/1hgcBNd12BfT9VLgbId7By/01d91920114b124fb4cf6d448f9f06eb/favicon.svg - Tally press kit: https://tally.so/help/press-kit - Zapier favicon: https://zapier.com/favicon.ico ## Validation - Confirmed touched UI SVGs transform through SVGR successfully. - Confirmed regenerated raster dimensions and alpha metadata with Sharp. - Reviewed a generated contact sheet at 72px, 40px, and 16px. - Ran `git diff --check`. - Ran `packages/twenty-ui` Vite build with ARM Node v24.5.0: `/Users/thomascolasdesfrancs/.nvm/versions/node/v24.5.0/bin/node ../../node_modules/vite/bin/vite.js build`. Local note: `npx vite build` fails in `packages/twenty-ui` on this machine because that directory resolves `/usr/local/bin/node` as x64 v23.5.0 while the Yarn install links Rollup's ARM optional package. The direct ARM Node build above passed.	2026-06-04 14:19:49 +00:00
Charles Bochet	a7fed47932	fix(twenty-ui): prevent local visual diffs from polluting CI baselines (#21225) ... ## Summary - **Username-prefix branches**: Local visual-diff builds now use `charles/main` instead of `main` as the branch name, preventing local runs from creating auto-approved reference builds that could overwrite CI baselines. - **Local merge-base computation**: Computes `ARGOS_REFERENCE_COMMIT` via `git merge-base HEAD main` locally, so the Argos SDK skips `git fetch origin <branch>` — fixing the "fatal: couldn't find remote ref" error when running from non-pushed branches. - **Pass `referenceCommit` to vitest plugin**: Ensures the locally computed merge-base is forwarded to the Argos upload. ## Test plan - [x] Verified local visual-diff works from `main` branch (branch becomes `charles/main`, not auto-approved) - [x] Verified local visual-diff works from a non-pushed branch (`test/local-only-visual-diff` → build uploaded successfully)	2026-06-04 15:42:32 +02:00
Charles Bochet	f4da7767f8	chore: remove Chromatic dependencies and configuration (#21221) ... ## Summary - Remove `chromatic` and `@chromatic-com/storybook` devDependencies from twenty-front - Remove global `chromatic` Nx target from nx.json and twenty-front project.json override - Remove commented Chromatic Storybook addon from twenty-front - Remove `CHROMATIC_PROJECT_TOKEN` from .env.example - Update README to remove Chromatic sponsor reference (image was already missing) - Update stale Chromatic comment in toSpliced.ts ## Context Visual regression testing has moved from Chromatic SaaS to self-hosted Argos at `argos.twenty-internal.com`. These are dead references that are no longer used by any CI workflow. **Note:** Story `parameters.chromatic: { disableSnapshot: true }` entries are intentionally kept — the Argos plugin reads them as a fallback. ## Test plan - Verify `yarn install` succeeds after dependency removal - Verify no workflow references `chromatic` or `nx chromatic`	2026-06-04 13:15:23 +00:00
Charles Bochet	badeaddd37	fix(ci): ensure ui-sb-test runs on push to main (#21222) ... ## Summary - Add explicit `if: always() && needs.ui-sb-build.result == 'success'` to `ui-sb-test` job ## Context After merging #21217, the main-branch Argos baseline pipeline doesn't work: `ui-sb-test` is silently skipped on push to main, so no `argos-screenshots-twenty-ui` artifact is produced. **Root cause:** `changed-files-check` is skipped on push events (PR-only). `ui-sb-build` handles this with `if: always() && ...`, but `ui-sb-test` has no explicit `if` — GitHub Actions propagates the skip through the transitive dependency chain (`changed-files-check` → `ui-sb-build` → `ui-sb-test`). ## Test plan - Merge this PR and verify the next push to main produces the `argos-screenshots-twenty-ui` artifact - Verify `dispatch-main` successfully triggers ci-privileged with the artifact	2026-06-04 15:11:38 +02:00
Charles Bochet	9042e8a542	feat(ci): Argos main baselines + local visual diff support (#21217) ... ## Summary **CI: Main-branch Argos baselines** - Run storybook build + screenshot capture on `push` to `main` in CI UI workflow - Add `dispatch-main` job in visual regression dispatch to forward main-branch screenshots to ci-privileged - Simplify `dispatch-pr` by inlining the artifact name and removing unused `project` output **Local visual diff support** - Add `scripts/visual-diff.sh` for running Argos uploads locally via tunnel - Add `storybook:visual-diff` Nx target wrapping the script (depends on `storybook:build`) - Honor `STORYBOOK_URL` env in `vitest.config.ts` to reuse pre-served static builds (mirrors twenty-front pattern) - Support `ARGOS_BUILD_NAME`, `ARGOS_REFERENCE_BRANCH` env overrides in vitest plugin config ## Context Argos builds on PRs are all "Orphan" because there's no reference build on `main` to compare against. The CI changes add the missing piece: every merge to main now produces screenshots and uploads them to Argos as reference builds. The local visual diff script enables developers to run visual regression checks from their machine against the self-hosted Argos instance via `kubectl port-forward` (set up by the twenty-infra `argos-tunnel` command). ## Related - twentyhq/twenty-argos#1 (backend config for self-hosted HTTPS redirect) - twentyhq/twenty-infra#709 (argos-tunnel super CLI command + self-hosted mode) ## Test plan - [ ] Verify CI UI runs on next push to main and produces the `argos-screenshots-twenty-ui` artifact - [ ] Verify `dispatch-main` triggers and uploads screenshots to Argos - [ ] Verify subsequent PR builds show diffs against the main baseline instead of "Orphan" - [ ] Run `ARGOS_TOKEN=<token> npx nx storybook:visual-diff twenty-ui` locally with tunnel active	2026-06-04 14:55:08 +02:00
github-actions[bot]	100b08e827	i18n - website translations (#21220) ... Created by Github action --------- Co-authored-by: github-actions <github-actions@twenty.com>	2026-06-04 14:47:01 +02:00
neo773	437eed0862	fix(messaging): fix reply-quotation stripping that emptied email bodies (#21118) ... some synced messages were stored with empty bodies, others with the entire reply thread re-quoted, planer was stripping entirely quoted forwards down to nothing and not trimming inline reply history at all switched plaintext quote stripping to `email-reply-parser`, falling back to the full text when it strips everything so forwards don't end up blank. kept planer for the html path, and normalized body whitespac --------- Co-authored-by: prastoin <paul@twenty.com>	2026-06-04 12:31:53 +00:00
Rashad Karanouh	5a55021e26	feat(website): add /partners/apply standalone page (#21219) ... ## Summary - Adds a standalone `/partners/apply` page — a shareable URL that opens the partner application wizard full-page (no modal, no nav, no footer), on a plain black background - Adds a `slots` prop to `PartnerApplicationWizard` so it can render outside a `Dialog.Root` context (Base UI), keeping the existing modal on `/partners` completely untouched - Surfaces logic function errors to the user: the API route now checks the webhook response body for `ok: true`, so a silent backend failure no longer shows a false success state ## Test plan - [ ] `yarn jest --no-coverage` — 365/365 passing - [ ] `npx oxlint -c .oxlintrc.json .` — 0 errors (1 pre-existing warning unrelated to this PR) - [ ] `npx oxfmt --check .` — clean - [ ] `npx tsc --noEmit` — clean - [ ] Visit `/partners/apply` — wizard loads full-page on black background, no menu, no footer - [ ] Complete the wizard and submit — redirects to `/partners/list` - [ ] Visit `/partners` — "Become a partner" modal still opens normally	2026-06-04 12:30:26 +00:00
Raphaël Bosi	63435a7937	Twenty new ui README (#21186) ... Generated a twenty new ui implementation plan README after the discussion with @charlesBochet	2026-06-04 12:14:43 +00:00
twenty-pr[bot]	6a2c948e84	chore: bump version to 2.10.0 (#21218) ... ## Summary - Moves current version to previous versions array - Sets TWENTY_CURRENT_VERSION to the new version - Updates TWENTY_NEXT_VERSIONS with the next minor version - Bumps twenty-client-sdk, twenty-sdk, and create-twenty-app to the same version ## Checklist - [ ] Verify version constants are correct - [ ] Verify npm package versions match Co-authored-by: Github Action Deploy <github-action-deploy@twenty.com>	2026-06-04 14:14:18 +02:00