351 Commits

Author	SHA1	Message	Date
Félix Malfait	41c10b9ee7	feat(server): resolve app-owned metadata translations at runtime (#22235) ... ## Summary First of a **4-PR stack** that lets apps built with `twenty-sdk` translate their metadata, resolved at runtime. The standard Twenty app is modelled as "an app like any other" — `NULL applicationRegistrationId` ⟺ the standard app, no special-casing. This PR adds the server foundation and wires runtime resolution for **object** and **field** metadata: - New `applicationTranslation` core table + entity (nullable `applicationRegistrationId`, `locale`, `messages` jsonb), one row per (app, locale) to avoid multi-MB rows. - `ApplicationTranslationCacheService` (process-local, 30s TTL) + `ApplicationTranslationSyncService` (upsert + soft-delete from a manifest). - Shared `translateStandardLabel` util: application catalog → i18n bundle → source value. - Object/field resolvers + dataloaders prefetch and apply the per-app catalog. The new `applicationCatalog` param is **optional**, so standard behaviour is byte-unchanged. - Fast instance command to create the table. ## Stack **PR 1/4**, targets `main`. Followed by: (2) twenty-sdk extract/compile → `manifest.translations`, (3) resolution across the remaining metadata resolvers, (4) the per-locale standard-override editor. ## Tests Unit: `translateStandardLabel`, `resolveObjectMetadataStandardOverride` (including the application-catalog path). ## Verification note The remote dev environment for this branch could not complete `yarn install` (no package-registry egress), so typecheck/lint/tests were not run locally — **CI is the source of truth** for this stack. Changes follow existing patterns. https://claude.ai/code/session_01NiE7o3cd3zCLZarVkJa6UA --- _Generated by [Claude Code](https://claude.ai/code/session_01NiE7o3cd3zCLZarVkJa6UA)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22235?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-28 07:36:21 +02:00
Weiko	56e20a81ea	Revert 21949 (#22081) ... #21949 introduced deterministic uuid utils with usage in the same PR. Usage was not uniform and expected a backfill command as well. Since we want to release I'm reverting all the changes from that PR that concerns twenty-server and only keeping the unused utils in twenty-shared and I'll introduce usages within the same PR as backfill command	2026-06-24 15:37:16 +02:00
Weiko	b7850a6c64	feat(metadata): deterministic universalIdentifiers for server-generated side-effects (#21949) ... ## Context Server-generated "side-effect" entities created for every object (system fields, INDEX view, record-page fields view + view fields, search-vector index, navigation command, record page layout/tabs/widgets) were minted with random v4() ids. Because they were non-deterministic, nothing could reference them by id (e.g. point a view field at an object's createdAt field). This PR introduces a single shared rule for deriving these ids deterministically via uuid v5, so the same (owner app, parent, kind) always yields the same id, making side-effects referable and reproducible. This is the **forward-only foundation** (PR1). Follow-ups: - PR2: SDK with optional universalIdentifier + expose helpers to app authors. - PR3: regenerate the standard-app constants to the same scheme + workspace backfill. ## The rule ```ts universalIdentifier = computeOwnerScopedUniversalIdentifier({ ownerAppUID, namespace, value }) = v5(value, v5(ownerAppUID, ENTITY_TYPE_NAMESPACE)) value = `${parentUID}:${discriminator}` // entity scoped under a parent = `${discriminator}` // top-level, app-parented entity ``` - ownerAppUID: The application that owns the entity (already threaded through every generator as applicationUniversalIdentifier); folded into the namespace so it both owns and scopes the id — two apps adding the same-named entity to a shared parent never collide. - namespace: Per entity type (ENTITY_TYPE_NAMESPACE_BY_TYPE), so different types with the same parent+discriminator never collide. - parentUID: The immediate parent's actual universalIdentifier (omitted for top-level entities, since the owner app already scopes them). - discriminator: A stable semantic key (field name, tab/widget title, generated index name, select-option value, …). Scope boundary: deterministic v5 applies to system side-effects (unique by construction) and, later, app-authored manifest entities (uniqueness enforced at SDK build time). Entities created through the UI by the workspace "Custom" app (custom objects/views/fields) keep v4, their natural keys aren't unique and aren't enforced. A UI-created custom object keeps its v4 id; its side-effects are deterministic relative to that v4 parent. Changes twenty-shared: new application/deterministic-identifier/ module: - computeDeterministicUuid(value, namespace) primitive + a thin computeOwnerScopedUniversalIdentifier wrapper (boilerplate only), and frozen ENTITY_TYPE_NAMESPACE_BY_TYPE. - One self-contained util per usecase (no central registry, no generic engine): each util bakes in its own discriminator + namespace, so a key lives next to the code that uses it and is individually testable. ~28 utils covering side-effect and (future) app-authored entities, e.g. getFieldUniversalIdentifier, getIndexViewUniversalIdentifier, getFieldsWidgetViewUniversalIdentifier, getViewFieldUniversalIdentifier, getIndexUniversalIdentifier, getRecordPageLayoutUniversalIdentifier, getPageLayoutTab/WidgetUniversalIdentifier, getNavigationCommandUniversalIdentifier, plus the general getViewUniversalIdentifier / getPageLayoutUniversalIdentifier and app-authored getObject/Role/PermissionFlag/Agent/Skill/…UniversalIdentifier. - Golden snapshot test locking every util's output for fixed inputs, plus a cross-type no-collision test. twenty-server: side-effect generators now derive universalIdentifier via the helpers (local id PKs stay v4()): system fields + name, INDEX view, record-page fields (fields-widget) view, default view fields, search-vector index, nav command, page layout/tabs/widgets. Index ids key off the generated Postgres index name; extracted computeFlatIndexNameOrThrow so the name (and therefore the id) is computed once with no placeholder. ## Timeline ### What actually changes - New objects (custom objects created via Settings/metadata API) and fresh standard installs now get deterministic v5 universalIdentifiers for all side-effect entities (system fields, views, view fields, search index, nav command, page layout/tabs/widgets) instead of random v4(). - The nav-command id formula changed (new owner-scoped) for new objects, fresh standard installs, and the runtime lookup. ### What does NOT change - Existing objects' side-effect ids — untouched (no migration; forward-only). - Standard object UIDs — untouched - UI-created custom entities' own ids stay v4 (see scope boundary above). - Fresh installs are behaviorally a no-op — ids are internal; re-sync produces no diff (verified). Nothing user-visible. ### The one real-world impact / risk (existing workspaces) The nav-command runtime lookup (findNavigationCommandMenuItemForObject) now computes the new formula, but existing workspaces' nav commands were stored with the old formula. So on an upgraded existing workspace, until the PR3 backfill: - Object activate/deactivate toggle for existing objects won't find the nav command → re-activating can create a duplicate nav command; deactivating may no-op. - Object deletion won't find/clean up the old nav command → orphaned nav-command row. ### What app developers get right now Nothing usable yet. The helpers exist in twenty-shared but aren't re-exported from twenty-sdk (PR2), and app-authored objects still get SDK-derived ids in the old format until PR2 re-mints them. So "reference a server entity by deterministic id" doesn't work end-to-end until PR2	2026-06-24 11:47:44 +02:00
Paul Rastoin	e9d5d71cd3	Wire up search field metadata (#21964) ... ## Part 1 - Exact scope of the current PR (#21964) close https://github.com/twentyhq/core-team-issues/issues/2586 This PR introduces `searchFieldMetadata` as a first-class flat metadata entity and migrates the existing search surface onto it, with **no change to which records are searchable** (ISO with `main`). In scope (what the PR does): - New flat entity `searchFieldMetadata` (universalIdentifier, applicationId, **`position`**, maps, conversions), registered in the central flat-entity constants and the migration build orchestrator. - `searchVector.asExpression` is **derived server-side** from `searchFieldMetadata` rows (validated by `isSafeTsVectorExpression`); never trusted from client input. - **Derivation order is deterministic, driven by each row's `position`** ([compute-search-vector-as-expression-from-search-field-metadatas.util.ts](packages/twenty-server/src/engine/metadata-modules/flat-search-field-metadata/utils/compute-search-vector-as-expression-from-search-field-metadatas.util.ts)), replacing the previous non-deterministic `(createdAt, id)` sort. That sort collapsed to random UUIDs for standard fields (same `createdAt`), so any rename/relabel rewrote the `STORED` generated column to a logically-identical-but-textually-different expression and produced a permanent per-workspace diff vs the standard definition. Ordering now equals provisioning order; ties break on `universalIdentifier`. - Provisioning at object creation mirrors the existing surface exactly **and seeds `position`**: - custom objects -> the `name` field only, at `position: 0` ([build-default-search-field-metadatas-for-custom-object.util.ts](packages/twenty-server/src/engine/metadata-modules/object-metadata/utils/build-default-search-field-metadatas-for-custom-object.util.ts)) - standard objects -> their curated `SEARCH_FIELDS_FOR_*` sets, `position` = the curated index - Backfill (instance + workspace commands in `2-16`) provisions rows for existing workspaces with the same surface **and the same positions** (standard from the curated standard maps, custom `name` = `0`), scoped to the workspace's own custom application ([build-search-field-metadata-backfill-operations.util.ts](packages/twenty-server/src/database/commands/upgrade-version-command/2-16/utils/build-search-field-metadata-backfill-operations.util.ts)). The `position` column is added in the same `2-16` fast instance command as `universalIdentifier`/`applicationId`. - Field rename of an already-indexed field recomputes `asExpression` (positions preserved, so order is stable) ([recompute-search-vector-on-field-rename.util.ts](packages/twenty-server/src/engine/metadata-modules/flat-field-metadata/utils/recompute-search-vector-on-field-rename.util.ts)). - Field delete drops the matching row(s) and recomputes; remaining rows keep their relative order (no renumber) ([from-delete-field-input-to-flat-field-metadatas-to-delete.util.ts](packages/twenty-server/src/engine/metadata-modules/flat-field-metadata/utils/from-delete-field-input-to-flat-field-metadatas-to-delete.util.ts)). - Object relabel is **additive** and ISO/regression-fix only: it indexes the new label identifier **appended last (`position = max(existing) + 1`)** without dropping `name` ([recompute-search-vector-on-label-identifier-update.util.ts](packages/twenty-server/src/engine/metadata-modules/flat-object-metadata/utils/recompute-search-vector-on-label-identifier-update.util.ts)). This is a deliberate, temporary bridge. Explicitly OUT of scope (deferred): - No API to edit `searchFieldMetadata` (no user-facing search-field configuration, including `position` — it is internal and only written by provisioning/backfill/recompute). - No auto-indexing of arbitrary searchable fields. Creating a custom TEXT/EMAILS/etc. field does NOT add it to search (the `computeSearchFieldMetadataCreationForFields` behavior was removed in `e6820ad`). - No field-type-transition handling (field type is immutable - not in `FLAT_FIELD_METADATA_EDITABLE_PROPERTIES`, so that path was dead code). - No `position` validation (uniqueness/range) and no multi-vector / per-field `weight` config — deferred to the configurable-search follow-up (#1428). Net: `searchFieldMetadata` becomes the source of truth for the *same* surface as `main`. The only intentional divergences from `main` are "relabel preserves `name`" (additive) and the deterministic `position`-ordered `asExpression` (a correctness/perf fix that is byte-identical to provisioning order, so it does not change the searchable surface). --------- Co-authored-by: Félix Malfait <felix@twenty.com>	2026-06-23 16:27:13 +02:00
Félix Malfait	23f5ba9ebf	feat: add resizable kanban column width (#21828) ... ## What & why Lets users resize the columns of a Kanban (record board) view. Requested by a user; the design avoids the "ragged board" problem by making the width a **single shared value**. ## Behaviour - A drag handle appears on the right edge of every column header. - Because all columns read **one** width value, dragging any handle resizes **every** column together — they can never end up mismatched. - Width is clamped between **150px** and **400px** (default **200px**). - The width is **persisted per view** and restored on reload. ## Approach **Backend** — a new nullable `View.kanbanColumnWidth` field, threaded through the existing view-level setting pattern (the same one `kanbanAggregateOperation` / `shouldHideEmptyGroups` use), so it gets create/update/manifest/override support for free: - entity column + `ViewOverrides` + `@WasIntroducedInUpgrade` - `CreateViewInput` / `UpdateViewInput` (`Int`, `@Min(150)`/`@Max(400)`) + `ViewDTO` - flat-view editable properties, entity-properties config, compare-type, standard-view + manifest converters - a fast instance command adding the `core.view` column **Frontend** — the value hydrates into a view-scoped atom and drives a single CSS variable set on the board container, which both column headers and bodies read. Live dragging only writes that CSS variable (no per-move React re-render); the final width is committed to the atom and persisted via `updateView` on pointer-up. ## Nullability / defaults `kanbanColumnWidth` is nullable — `null` means "never resized" and the UI falls back to the 200px default, so existing rows need no backfill. ## Validation - `nx typecheck twenty-server` ✅ and `nx typecheck twenty-front` ✅ - `nx lint:diff-with-main twenty-server` ✅; frontend lint fixes applied (split constants to one-per-file, removed `useRef`-for-state in favour of `useState`). - Draft pending a final green CI run (the dev container reclaimed `node_modules` mid-session; re-running locally). ## Test plan - [ ] Drag a kanban column edge → all columns resize together, clamped 150–400px - [ ] Reload → width persists for that view; other views unaffected - [ ] A view that was never resized still renders at 200px https://claude.ai/code/session_016Qe6oDBkhVbrq2QkXBJ5nE --- _Generated by [Claude Code](https://claude.ai/code/session_016Qe6oDBkhVbrq2QkXBJ5nE)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21828?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Claude <noreply@anthropic.com>	2026-06-19 15:58:13 +02:00
Weiko	9f30915f6f	fix(metadata): remove deprecated isCustom from Objects and Fields (#21799) ... ## Context Follow-up to #21228, which deprecated `isCustom` on object/field metadata but kept it exposed because the frontend still relied on it. This removes it from the GraphQL API and the frontend entirely. ## Implementation ### Server - Remove `isCustom` `@Field` from the `Object`, `Field`, and `MinimalObjectMetadata` GraphQL types - Remove the `isCustom` `@ResolveField` resolvers and the `isCustomLoader` dataloader (+ payload/interface) - Remove `isCustom` as an internal `@HideField()` on the Object/Field DTOs used by the i18n standard-override gate > Use an explicit isStandard instead (which is the correct gating) ### Frontend - Add `getIsMetadataItemCustom` helper + `useGetIsMetadataItemCustom` hook: an item is custom when `applicationId === currentWorkspace.workspaceCustomApplication.id` - Migrate all consumers off `objectMetadataItem.isCustom` / `fieldMetadataItem.isCustom`; `isRecordFieldReadOnly` now takes a precomputed `isFieldCustom` - Drop `isCustom` from the metadata fragment/mutations/minimal query, FE types, zod schemas, and mock generators; regenerate GraphQL types ## Notes - Breaking change on the (already-deprecated) `Object.isCustom` / `Field.isCustom` GraphQL fields and the `isCustom` filter - FE semantic is "belongs to the workspace custom app" (third-party-app objects/fields are treated as non-custom) - `isCustom` on IndexMetadata / View / Skill / Agent is a separate column and is untouched - Breaking changes on REST metadata API	2026-06-19 01:19:49 +02:00
Weiko	3ee93b5ec9	feat(server): add isSystemSideEffect & merge createOneObject/createOneField side-effect migrations (#21673) ... ## Context When an object is created via the metadata API, `createOneObject` creates its side-effect entities (INDEX view + viewFields, indexes, navigation menu item, "go to" command menu item, record-page fields view, page layout/tabs/widgets) across **three separate `validateBuildAndRunWorkspaceMigration` calls**, purely because the protection behavior (mutations → overrides, delete → deactivate, reset → reactivate) was keyed on *"owned by the standard app"*, forcing the side effects into batches with different application owners. This misrepresents ownership and breaks atomicity. This PR separates two orthogonal concepts: - **Ownership** (`applicationId`), the true owner: the caller's application (the workspace custom app today, 3rd-party apps later). - **Protection** (`isSystemSideEffect`), the row was generated by the system, so user mutations route to overrides, deletion becomes deactivation, and reset restores defaults. Once side effects are re-owned to the caller, the old `applicationId === standardApp` check can no longer tell an original side-effect row from a user-added one so a dedicated `isSystemSideEffect` flag carries the protection instead. This is **PR 1 of 2** (forward-only). It makes newly created objects and fields correct; existing workspaces are handled by a follow-up backfill (see *Out of scope*). ## What this PR does - **`isSystemSideEffect` column** on the 8 affected entities (`view`, `viewField`, `indexMetadata`, `commandMenuItem`, `pageLayout`, `pageLayoutTab`, `pageLayoutWidget`, `fieldMetadata`), with `@WasIntroducedInUpgrade` + an entry in the flat-entity property configuration (`toCompare: true`, read-only). - **Single atomic migration in `createOneObject`**: the three `validateBuildAndRunWorkspaceMigration` calls are merged into one, owned by the caller (`resolvedOwnerFlatApplication`) and the record-page view/fields, page layout, and navigation command item are re-owned to the caller and flagged `isSystemSideEffect: true`. `buildNavigationFlatCommandMenuItem` is parameterized with `applicationUniversalIdentifier` (no longer hardcoded to the standard app). - **Field-creation side effects** (`createManyFields`/`createOneField` already run as a single caller-owned migration, so no re-ownership/merge was needed): the auto-created viewField is flagged `isSystemSideEffect: true`, and a new field now also propagates to the object's **INDEX/table view** (added there as a **hidden** column, `isVisible: false`) in addition to the record-page FIELDS widget. The INDEX view is targeted directly by `key = INDEX` (it is not a page-layout widget), de-duplicated per `(viewId, fieldMetadataUniversalIdentifier)` to respect the per-view unique index. The unique-field index is likewise flagged the inverse relation field stays unflagged (`isSystem: false`). - **Protection predicate** extended: `isCallerOverridingEntity` and the removal/reset split strategies now treat `isSystemSideEffect` rows as protected even when caller-owned (route to overrides / deactivate / reset) and the page-layout-reset guards allow resetting flagged entities. - **Standard compute maps** set the flag consistently so a re-sync produces no diff (standard-object side effects stay `false`; per-object nav command items and custom-object base fields are `true`). - **Read-only GraphQL exposure** of `isSystemSideEffect` on the view / view-field / page-layout / tab / widget / command-menu-item DTOs (not exposed on create/update inputs). => Todo: needs to take this new flag into account. This is fine for now because isSystem remains on object/field. - **Fast instance command** (`2-14`) adding the 8 columns (`NOT NULL DEFAULT false`). ## Scope decisions - **`pageLayout` is not an `OverridableEntity`**, its own row has nothing user-overridable (all customization lives on tabs/widgets). It's dual-purpose (`RECORD_PAGE` side-effect vs. user `DASHBOARD`), so it gets `isSystemSideEffect` for protection only, no `overrides` jsonb. - **`navigationMenuItem` is out of scope.**: Those are side effects only for the metadata API and not marked as "system" (they can be deleted/updated etc...) - **`viewFieldGroup` is not a side effect**, it's only created via the explicit view-field-group API, never by object/field creation, so it gets no flag. ## Out of scope (follow-ups) **PR 2** — slow per-workspace backfill (re-own + flag existing side effects, recreate missing ones) and deterministic v5 identifiers for base fields / pageLayout / tab. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21673?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-17 15:56:27 +02:00
Manish Kumar	25b0e4d81c	fix: #19173 correct labels and icons for custom object default relations (#19224) ... **### Problem** When creating a custom Data Model object, the auto-generated Note and Task relations had incorrect labels ("Note Targets", "Task Targets") and a wrong hardcoded icon (IconBuildingSkyscraper). Expected behavior is to use user-friendly labels ("Notes", "Tasks") and proper icons, consistent with standard objects like Company and Person. **Root causes:** * `icon` in `createFieldInput` was hardcoded to `'IconBuildingSkyscraper'` * `label` was derived from `targetFlatObjectMetadata.labelPlural`, which returns system labels (e.g., "Note Targets") instead of display labels --- **Fix** * Added `sourceFieldOverridesByRelationObjectNameSingular` map to define correct labels and icons for all default relation types * Ensures consistency with standard objects Mappings: * noteTarget: "Note Targets" → "Notes", IconBuildingSkyscraper → IconNotes * taskTarget: "Task Targets" → "Tasks", IconBuildingSkyscraper → IconCheckbox * attachment: "Attachments" → "Attachments", IconBuildingSkyscraper → IconFileImport * timelineActivity: "Timeline Activities" → "Timeline Activities", IconBuildingSkyscraper → IconTimelineEvent * favorite: "Favorites" → "Favorites", IconBuildingSkyscraper → IconHeart * Added type safety using: `satisfies Record<(typeof DEFAULT_RELATIONS_OBJECTS_STANDARD_IDS)[number], ...>` This ensures new default relations must be explicitly defined * Renamed variable: `icon` → `targetFieldIcon` for better clarity (it is only used for the target field) --- **Limitations** * Applies only to newly created custom objects * Existing objects will keep incorrect labels/icons * Requires a separate data migration to fix existing data --- **Testing** 1. Go to Settings → Data Model 2. Create a new custom object 3. Verify: * Labels show "Notes" and "Tasks" (not "Note Targets"/"Task Targets") * Icons match those used in standard objects (e.g., Company, Person) --- ## Update (reworked while merging main) The original approach was reworked: - The label/icon mapping now lives in a shared `STANDARD_RELATION_FIELD_PROPERTIES_BY_RELATION_OBJECT` constant (`msg`-based, so labels stay translatable), used as the single source of truth. Dropped the unused `favorite` entry. - Standard objects now reference that same constant explicitly at each call site (uniformization) instead of duplicating the values. Objects that intentionally differ keep their explicit overrides: note/task → `Relations`, person/workspaceMember → `Events`, workflow attachments → `IconFileUpload`. - Fixed an unrelated typo found along the way: Company's `timelineActivities` icon was `IconIconTimelineEvent`. - For the history (supersedes the "Limitations" above): added a `2.9.0` workspace upgrade command `upgrade:2-9:fix-standard-relation-field-labels-icons` that re-syncs **standard** objects' default relation labels/icons against the source of truth. It deliberately leaves **custom** objects untouched — their relation fields are user-editable and must not be overwritten by an upgrade. ## Testing / Verification Verified locally end-to-end: **New custom objects** - Created a custom object via the Data Model UI and via the metadata API — its note/task/attachment/timeline relations now show `Notes` / `Tasks` / `Attachments` / `Timeline Activities` with the correct icons instead of `Note Targets` + `IconBuildingSkyscraper`. **Standard uniformization (value-preserving)** - Re-seeded a workspace on this branch and inspected all 25 default-relation field definitions across the 10 standard objects: every canonical value is unchanged, every intentional variant (Relations / Events / IconFileUpload) is preserved, and the only diff vs `main` is the Company `IconIconTimelineEvent` → `IconTimelineEvent` fix. **Upgrade command (existing workspaces)** - Simulated a real upgrade: seeded a workspace on `main` (Company icon typo present), created a custom object via the metadata API (it came out with the old buggy labels, as expected on `main`), then switched to this branch and ran the command. - Confirmed via both the metadata API and direct DB inspection: Company's standard `timelineActivities` icon healed to `IconTimelineEvent`, while the custom object's relations were left untouched. - Idempotent: re-running reports "already up to date". **CI**: typecheck, lint, server unit tests, and all server integration-test shards green. --------- Co-authored-by: Manish Kumar <manishkumar@Mac.lan> Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-14 21:06:58 +02:00
Félix Malfait	c05f01f2a3	fix(server): repair 2.13 isUIReadOnly→isUIEditable rename fallout (#21504) (#21537) ... ## Context Follow-up to #21504 ("Rename isUIReadOnly to isUIEditable, add isUICreatable…"), which surfaced two issues: 1. **`column FieldMetadataEntity.isUIReadOnly does not exist`** on twenty-main.com. 2. **`cross-version-upgrade` CI failure** — `SyncStandardUiCapabilityFlags` aborts the v1.22 → 2.13 upgrade. ## Fix 1 — don't drop `isUIReadOnly` in the 2.13 rename command The 2.13 fast instance command physically dropped `isUIReadOnly` from `core."fieldMetadata"` and `core."objectMetadata"`. But migrations run in an ArgoCD **PreSync** hook **before** the new pods roll out (`charts/prod-eu/apps/twenty-server` migration Job is `hook: PreSync`, sync-wave `2`; the api/worker Deployments are sync-wave `10`). So the **previous** release's pods keep serving and still `SELECT isUIReadOnly`, throwing `column ... does not exist` from the moment the column is dropped until the rollout finishes. This keeps the column (already hidden from the app via `@WasRemovedInUpgrade` on both entities) and **defers the physical drop** to a later release. Since 2.13 hasn't shipped to self-hosters yet, the committed command is amended in place. Both tables handled; `isUICreatable` (new, additive column) is unaffected. The eventual physical drop + GraphQL-compat removals are tracked in twentyhq/core-team-issues#2542. ## Fix 2 — allow `isUIEditable` updates on relation field metadata `SyncStandardUiCapabilityFlags` re-syncs `isUIEditable` on standard fields, including morph/relation fields (the activityTargets `target*` relations). The flat-field-metadata validator only permits a fixed property allow-list on relation fields, which omitted `isUIEditable`, so the command failed with `FIELD_MUTATION_NOT_ALLOWED` and aborted the upgrade (leaving workspaces in a FAILED state). `isUIEditable` is a per-field UI-affordance flag that applies to relation fields too, so it's added to the relation-field updatable properties (a constant used **only** by that validator — no diff-engine side effects). ## Coherence notes - Object-level is covered: the drop is deferred on **both** tables, and `ObjectMetadataEntity` has the identical decorators. - `isUICreatable` needs no change: object-only and additive (no drop → no rolling-deploy hazard), and never reaches the field relation allow-list. - The object-metadata validator has no relation allow-list, so there's no object-level analog to change. ## Verification - `nx typecheck twenty-server` ✅ (the `satisfies` guard holds — `isUIEditable` is a `toCompare` property of `fieldMetadata`) - `oxlint --type-aware` + `oxfmt --check` ✅ on changed files - Fix 2's path is exercised end-to-end by the `cross-version-upgrade` CI that originally caught it. --------- Co-authored-by: Claude <noreply@anthropic.com>	2026-06-14 05:51:23 +02:00
Weiko	f63f053444	CommandMenuItem overridable entity (#21486) ... ## Context Second PR of the overridable-entities track (after #21436 for views): command menu items become overridable so that edits on non-owned items are stored as overrides instead of mutating the row, and deletion/deactivation becomes reversible. ## What this does - `CommandMenuItemEntity` now extends `OverridableEntity<CommandMenuItemOverrides>` (adds `isActive` + `overrides`). All editable properties are overridable for now (to discuss). - **Update**: mutations on a command item not owned by the caller (standard items) are written into `overrides`; reads merge them in the DTO. The command palette edit mode (pin, reorder, shortLabel) now preserves standard values, "Reset label to default" gains true post-save semantics. - **Delete**: protected items are deactivated (`isActive = false`) instead of deleted; custom items still hard-delete. - **Object deactivate/enable toggle**: now flips `isActive` on the command item (merged into the main migration call) instead of delete/recreate; a create-if-missing fallback covers legacy deactivated objects. - **Front**: inactive command items are filtered out of the palette selector. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21486?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-13 14:21:27 +02:00
Félix Malfait	1efa3567ef	Rename isUIReadOnly to isUIEditable, add isUICreatable, expose both to app developers (#21504) ... <!-- CURSOR_AGENT_PR_BODY_BEGIN --> # UI capability flags: `isUIEditable` + `isUICreatable` ## Per-verb capability model This PR replaces the negative `isUIReadOnly` metadata flag with positive, per-verb capability flags (à la Salesforce `createable`/`updateable`): - **`isUIEditable: boolean`, default `true`** — rename of `isUIReadOnly` with inverted polarity, on **both** `objectMetadata` and `fieldMetadata`. It is one concept ("can the user edit this through the generic UI?") at two altitudes, so it carries one name at both levels. - **`isUICreatable: boolean`, default `true`** — new, **object-level only** (fields have no create verb). When `false`, no generic UI affordance to create a record of this object appears anywhere (table "+" buttons, board column add, calendar add, relation-section "Add new", record picker "Add new", command-menu create action and its keyboard shortcut). Both flags are **UI-affordance flags only**: the server does not block create/edit mutations based on them, so the system, API, and workflows continue to mutate these records freely. They are orthogonal statements about the object's nature with no implication rule in the data model. Because today's inline creation UX creates a blank record the user must then edit, the frontend create predicate currently requires both `isUICreatable` and effective editability. There is no CREATE permission in `ObjectPermissions`; the frontend keeps gating creation on `canUpdateObjectRecords` as a proxy, ANDed with the new flags. ## Unified create predicate All generic creation entry points now flow through one predicate, `canCreateRecordsForObjectMetadataItem` (`isUICreatable` && not `isSystem` && not effectively read-only, where effective read-only covers `isUIEditable`, `isRemote`, and the `canUpdateObjectRecords` proxy via `isObjectMetadataReadOnly`). This deletes the previously hardcoded suppression lists: - `isRecordTableCreateDisabled.ts` and its hardcoded `WorkflowRun`/`WorkflowVersion` list — deleted; those objects (plus `workspaceMember`) now declare `isUICreatable: false` in the standard application instead. - The hardcoded `workspaceMember` guard inside `useAddNewRecordAndOpenSidePanel.ts` — deleted. - The `CREATE_NEW_RECORD` command menu item's availability expression now checks `objectMetadataItem.isUICreatable`, `isUIEditable`, `isSystem`, and `isRemote`; a workspace upgrade command re-syncs the expression in existing workspaces. Component-local conditions (soft-delete filter active, layout customization mode) stay in their components. ## GraphQL compatibility and removal plan The schema delta versus main is **purely additive plus deprecations — zero breaking changes**: - `isUIReadOnly` remains on both the ObjectMetadata and FieldMetadata GraphQL output types for **one release** as a deprecated field computed as `!isUIEditable` (`deprecationReason: 'Use isUIEditable'`). The Twenty frontend no longer queries it. - `isUIReadOnly` also remains on the **input side** for one release (`CreateFieldInput`, `UpdateFieldInput`, `FieldFilter`, `ObjectFilter`), keeping the schema shape identical to main for those members. On create it acts as a legacy alias mapped to `!isUIReadOnly` (`isUIEditable` wins when both are provided); on update it is ignored, exactly as on main (it was never an editable property). Filtering on the deprecated member keeps working until the column is dropped at upgrade time; after that it is a deprecated no-op surface kept only for schema compatibility. **Removal plan for next release: drop `isUIReadOnly` from the output DTOs (and resolvers' `@ResolveField`s), from the input/filter types, from the create-input mapping, and the `@WasRemovedInUpgrade`-retained entity columns and decorators.** ## ⚠️ Webhook / database-event payload shape change The `database-event-payload` type in `twenty-shared` got a clean rename (no alias): metadata snapshots in webhook and database-event payloads now carry `isUIEditable` (and `isUICreatable` at object level) **instead of** `isUIReadOnly`, with inverted polarity. Consumers of these payloads that read `isUIReadOnly` must switch to `isUIEditable`. ## New manifest properties (app-developer DX) Application developers can now set these flags in their app manifests (purely additive — existing manifests and older `twenty-sdk` versions are unaffected, defaults apply when omitted): - `objects[].isUICreatable?: boolean` (default `true`) - `objects[].isUIEditable?: boolean` (default `true`) - `fields[].isUIEditable?: boolean` (default `true`) The manifest converters previously hardcoded `isUIReadOnly: false`; they now read the manifest values with `?? true` defaults. The types are re-exported through `twenty-sdk` from `twenty-shared`. ## Migration & backfill - One fast instance command: adds `isUIEditable` (NOT NULL default `true`) on `core."objectMetadata"` and `core."fieldMetadata"`, backfills `isUIEditable = false` exactly where `isUIReadOnly = true`, drops `isUIReadOnly`, and adds `isUICreatable` (default `true`) on `objectMetadata`. The `down` is the exact inverse. Uses `ADD/DROP COLUMN IF (NOT) EXISTS`, matching the 2-12 drop-`isCustom` precedent. Verified up and down in separate transactions against a dev database with exact backfill counts. - **Cross-version upgrade safety (multi-version self-hosted jumps):** the upgrade sequence interleaves per version (instance → workspace commands), so pre-2.13 workspace commands run **before** the 2.13 rename when an old instance jumps several versions. Following the `isCustom` precedent: `isUIEditable`/`isUICreatable` are marked `@WasIntroducedInUpgrade` and `isUIReadOnly` stays on both entities as `@WasRemovedInUpgrade`, so the upgrade-aware entity metadata adapter hides the not-yet-existing columns (and keeps the legacy column live) at pre-2.13 cursors. **No committed upgrade command outside the 2-13 directory is modified**: the old 1-21/2-8/2-9 commands keep their original `isUIReadOnly: true` inputs, which still compile (entity property retained, deprecated create-input alias mapped) and still produce the correct legacy column writes pre-rename. - A 2-13 workspace command (`sync-standard-ui-capability-flags`) re-syncs `isUICreatable` **and** `isUIEditable` on standard objects and `isUIEditable` on standard fields from the standard-application definitions. This backfills `isUICreatable: false` on `workflowRun`/`workflowVersion`/`workspaceMember` and heals fields created mid-cross-upgrade by pre-2.13 commands (whose hidden `isUIEditable` value cannot reach the insert). Both 2-13 sync commands pass `isSystemBuild: true` — the flat metadata validator otherwise rejects direct updates to system objects (verified against a deliberately drifted dev database; the run is idempotent). - A second 2-13 workspace command re-syncs the create-record command availability expression. ## Testing - Unit tests for `canCreateRecordsForObjectMetadataItem` (flag/permission/system combinations) and for the manifest converters (flags set / omitted → defaults). - Full `upgrade --dry-run` boots the sequence (107 steps) and validates the upgrade-aware decorator references; both 2-13 sync commands verified end to end against real drift and re-run idempotently. - Schema verified by live introspection after the input-alias restore: all four input/filter members match main, output deprecations intact; frontend metadata types and `twenty-client-sdk` schema regenerated from the running server. - Read-only-related and touched jest suites pass on both packages; typecheck and lint pass on `twenty-server` and `twenty-front`. <!-- CURSOR_AGENT_PR_BODY_END --> <div><a href="https://cursor.com/agents/bc-0f3e04cb-b04a-40be-8330-5609c4538e8a"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-web-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-web-light.png"><img alt="Open in Web" width="114" height="28" src="https://cursor.com/assets/images/open-in-web-dark.png"></picture></a>&nbsp;<a href="https://cursor.com/background-agent?bcId=bc-0f3e04cb-b04a-40be-8330-5609c4538e8a"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-cursor-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-cursor-light.png"><img alt="Open in Cursor" width="131" height="28" src="https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a>&nbsp;</div> <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21504?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com>	2026-06-13 07:10:22 +02:00
Félix Malfait	69a7e614ff	fix: restore isCustom gate in metadata label resolvers (#21432) ... ## Context #21228 removed the stored `isCustom` column and, with it, the `isCustom` early-return in `resolveObjectMetadataStandardOverride` / `resolveFieldMetadataStandardOverride`, on the assumption that falling through the `standardOverrides` checks was equivalent. It isn't: custom object/field labels now reach the Lingui lookup. A custom label that collides with a standard catalog string (e.g. a custom field labeled "Status") gets translated for non-English locales against the user's intent, and every other custom label pays a hash + catalog miss — and, in production, an "Uncompiled message detected" warning (#21415) — on each metadata resolution. ## Fix Restore the gate. `isCustom` is no longer stored, so call sites that build the resolver input from flat entities (dataloader, minimal-metadata, view controller, command-menu-item navigation context) derive it via `belongsToTwentyStandardApp`; GraphQL resolvers keep passing DTOs, which already carry the derived value. ## Testing - Unit tests for both resolvers, including a new regression test: a custom label matching a standard catalog entry is returned verbatim, Lingui never called. --------- Co-authored-by: Weiko <corentin@twenty.com>	2026-06-11 16:10:53 +00:00
Weiko	cfb9772179	feat(server): convert view to overridable entity (#21436) ... ## Context Every entity created as a side effect of object creation must support the overridable pattern (`isActive` + `overrides` + override routing) before we can re-own side effects to their true application. Starting with View. viewField, viewFieldGroup, pageLayoutTab and pageLayoutWidget already extend `OverridableEntity`. This PR brings `view` to the same pattern. ## What this does - `ViewEntity` now extends `OverridableEntity<ViewOverrides>` (adds `isActive` boolean + `overrides` jsonb). All editable view properties are overridable; the 3 fieldMetadata foreign keys are converted to/from universal identifiers like viewField's `viewFieldGroupId`. - **Update**: mutations on a view not owned by the caller (e.g. standard views like "All Companies") are written into `overrides` instead of mutating the row. Reads merge overrides in the DTO. - **Delete/destroy**: views not owned by the caller are deactivated (`isActive = false`) instead of deleted. ~~- **INDEX invariant**: `key = INDEX` views can only be created via object-creation side effect. The API now rejects creating, deleting or destroying INDEX views (object-deletion cascade is unaffected). This was not really needed for this migration but was flagged during implementation.~~ - **Front**: views with `isActive = false` are filtered out of the views selector. - Fast instance command adds the two columns (`2-12-instance-command-fast-...-view-overridable-entity.ts`). ## Notes - Custom (caller-owned) views behave exactly as before: direct updates, soft delete. - View-group side effects (kanban groups) are computed on the override-merged view so overridden `mainGroupByFieldMetadataId` works.	2026-06-11 16:00:52 +00:00
Weiko	9c66975520	isCustom deprecation for Objects and Fields (#21228) ... ## Context `isCustom` was a legacy denormalized boolean on `ObjectMetadataEntity` and `FieldMetadataEntity`. Now that every metadata row carries `applicationId` (via `SyncableEntity`), "is this custom" is fully derivable, and the stored boolean was a redundant second source of truth that could drift. The real meaning of `isCustom` is **"the owning application is not the twenty-standard application"** — i.e. `!belongsToTwentyStandardApp`. Note this is *not* "belongs to the workspace custom app" as I initially thought: third-party-application objects/fields are custom too. The standard application has a globally stable `universalIdentifier`, so the value derives with no per-workspace lookup. ## Changed ## `isCustom` checks — before → after `isCustom` is no longer a stored column. The table below lists every site that branched on it and how it resolves now. The unifying rule: `isCustom ≡ !isTwentyStandardApplicationUniversalIdentifier(applicationUniversalIdentifier)`. ### Server — behavioural checks | Location | Purpose | Before | Now | |---|---|---|---| | `utils/compute-object-target-table.util.ts` | Physical table name `_` prefix | `computeTableName(nameSingular, objectMetadata.isCustom)` | derives from `applicationUniversalIdentifier` (single source for all table-name callers) | | `twenty-orm/factories/entity-schema.factory.ts` + `…/entity-schema-metadata.type.ts` | ORM table name (hot path) | `object.isCustom` | `object.applicationId !== standardApplicationId` (computed in `buildEntitySchemaMetadataMaps`) | | `twenty-orm/repository/workspace-{delete,soft-delete,update}-query-builder.ts` | Table name for mutations | `computeTableName(nameSingular, objectMetadata.isCustom)` | `computeObjectTargetTable(objectMetadata)` | | `index-metadata/utils/generate-deterministic-index-name-v2.ts` | Index name hash (must stay bit-identical) | `flatObjectMetadata.isCustom` | derives from `applicationUniversalIdentifier` | | `object-metadata/object-record-count.service.ts` | Table name for record count | `computeTableName(nameSingular, isCustom)` | `computeObjectTargetTable(flatObjectMetadata)` | | `workspace-manager/dev-seeder/data/services/dev-seeder-data.service.ts` | Match seed config by table name | `computeTableName(item.nameSingular, item.isCustom)` | `computeObjectTargetTable(item)` | | `commands/workspace-export/workspace-export.service.ts` + `…/utils/generate-workspace-schema-ddl.util.ts` | Export table name (raw entity) | `objectMetadata.isCustom` | `!isTwentyStandard…(objectMetadata.application?.universalIdentifier)` | | `flat-field-metadata/services/flat-field-metadata-type-validator.service.ts` | Block users creating reserved field types | `args.flatEntityToValidate.isCustom` | `!args.flatEntityToValidate.isSystem` | | `api/common/.../common-create-many-query-runner.service.ts` | Don't let client overwrite system `createdBy` | `createdByFieldMetadata.isCustom === false` | `createdByFieldMetadata.isSystem === true` | | `field-metadata/utils/resolve-field-metadata-standard-override.util.ts` | Skip i18n/overrides for custom fields | `if (fieldMetadata.isCustom) return raw` | **removed** — falls through on `isDefined(standardOverrides)` | | `object-metadata/utils/resolve-object-metadata-standard-override.util.ts` | Skip i18n/overrides for custom objects | `if (objectMetadata.isCustom) return raw` | **removed** — same fall-through | | `command-menu-item/utils/build-navigation-interpolation-context.util.ts` | Override context for nav labels | passed `isCustom` into resolver | dropped (resolver no longer needs it) | | `api/common/.../data-arg-processor.service.ts` | `isCustom` for record-position table name | `flatObjectMetadata.isCustom` | derives from `applicationUniversalIdentifier` | | `metadata-modules/minimal-metadata/minimal-metadata.service.ts` | Minimal DTO + override context | `flatObjectMetadata.isCustom` | derives from `applicationUniversalIdentifier` | | `commands/upgrade-version-command/1-23/…backfill-record-page-layouts.command.ts` | Filter to custom objects | `objectMetadata.isCustom` | `!isTwentyStandard…(applicationUniversalIdentifier)` | ### Server — DTO / API population | Location | Before | Now | |---|---|---| | `flat-object-metadata/utils/from-flat-object-metadata-to-object-metadata-dto.util.ts` | passthrough `isCustom` | derives from `applicationUniversalIdentifier` | | `flat-field-metadata/utils/from-flat-field-metadata-to-field-metadata-dto.util.ts` | passthrough `isCustom` | derives from `applicationUniversalIdentifier` | | `object-metadata/utils/from-object-metadata-entity-to-object-metadata-dto.util.ts` (REST) | `entity.isCustom` | `entity.applicationId !== standardApplicationId` | | `field-metadata/utils/from-field-metadata-entity-to-field-metadata-dto.util.ts` (REST) | `entity.isCustom` | `entity.applicationId !== standardApplicationId` | | `dataloaders/dataloader.service.ts` | passed `flatFieldMetadata.isCustom` into override resolver | dropped (resolver no longer needs it) | > REST controllers (`object-metadata.controller.ts`, `field-metadata.controller.ts`) resolve `standardApplicationId` once per request from the cached `flatApplicationMaps`. ### Frontend | Location | Purpose | Before | Now | |---|---|---|---| | `settings/.../SettingsObjectFieldDisabledActionDropdown.tsx` | Whether an inactive field is deletable | `isDeletable = isCustomField` | `isDeletable = isCustomField && !isSystemField` | ### Unchanged (out of scope) `isCustom` on `IndexMetadata` / `View` / `Skill` / `Agent` and their guards still read the persisted column. Breaking change is on the isCustom filter on field and object APIs, this is never used in the FE and unlikely used by external consumers	2026-06-09 13:57:19 +00:00
Etienne	b56fea69aa	fix(ai) - optimize metadata CRUD tools (#21235) ... Reduces output tokens for all 13 metadata tools by (~49%) based on production sampling data. GET tools (field + object metadata) System fields are now returned as compact {id, name, type} instead of the full ~20-key payload (opt-in includeFullSystemFields to get full payload). System objects are similarly compacted to {id, nameSingular, namePlural}. Internal fields the agent never uses (searchVector, deletedAt, position, updatedBy) are excluded entirely. workspaceId and applicationId are hoisted into a response envelope instead of being repeated on every record. Null/default-false properties are stripped from custom field and object payloads (e.g. options: null, settings: null, isUIReadOnly: false). CUD tools (create/update/delete) Create and update field tools now return {id, name, type, label} instead of the full DTO. Create and update object tools now return {id, nameSingular, labelSingular} instead of the full DTO. Delete tools return {id, success: true} instead of the full DTO of the deleted entity. Validation errors are grouped by message — e.g. 10 fields failing the same check produce one line with all names instead of 10 identical lines. Learn schemas (all tools) UUID pattern regex stripped from JSON schemas (keeps format: "uuid"). $schema and additionalProperties: false stripped from all generated schemas. All Zod .describe() annotations and tool descriptions shortened. Skill & tool description updates: All references to the removed list_object_metadata_items tool replaced with get_object_metadata / get_field_metadata across skill instructions, dashboard tools, view filter/sort tools, and MCP server instructions.	2026-06-08 11:55:29 +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
Weiko	cc76b7bc50	Fix fields widget new field visibility (#21111) ... Fixes https://github.com/twentyhq/twenty/issues/21043 ## Context Newly created fields were never added to FIELDS widgets, regardless of the "Set fields created in the future as visible" toggle. The widget's newFieldDefaultVisibility was null on widgets that never explicitly set it (it was never populated at creation), so the backend skipped them and no view field was created. ## Implementation Keep newFieldDefaultVisibility nullable with false (not visible) as the behavior when not provided. The FE now reflects that properly and shows "un-toggled" when it's null (iso with BE behavior). The fix also ensures the value is explicitly set to true wherever it should be: - Set newFieldDefaultVisibility: true at every FIELDS widget creation path (backend default record-page layout, frontend createDefaultFieldsWidget + useTemporaryFieldsConfiguration); - Added a 2-9 workspace upgrade command that backfills true onto existing standard FIELDS widgets where the value is null.	2026-06-03 15:29:57 +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
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
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
Weiko	6e5e7963b5	fix(server): map PermissionsException to proper HTTP status on REST API (#20739) ... ## Summary `PermissionsException` thrown by `SettingsPermissionGuard` (and other permission code paths) was bubbling up through every typed REST exception filter and landing in the global `UnhandledExceptionFilter`, which falls back to **500** for anything that isn't an `HttpException`. So a forbidden user (e.g. an API key whose role doesn't have `DATA_MODEL`) calling `GET /rest/metadata/objects` got: ``` HTTP/1.1 500 Internal Server Error "Entity performing the request does not have permission" ``` GraphQL already had the right plumbing via `permissionGraphqlApiExceptionHandler` (`ForbiddenError` → 403, `UserInputError` → 400, `NotFoundError` → 404). This PR mirrors it on the REST side. ## What - New util `permissionRestApiExceptionCodeToHttpStatus` mapping every `PermissionsExceptionCode` → HTTP status, with `assertUnreachable` to force explicit handling of future codes. - New filter `PermissionsRestApiExceptionFilter` (`@Catch(PermissionsException)`) that delegates to `HttpExceptionHandlerService.handleError(...)` with the resolved status. - Wired `PermissionsRestApiExceptionFilter` (placed first, so the typed filter wins over any sibling catch-all) into `@UseFilters(...)` of every REST controller that uses `SettingsPermissionGuard` or whose service can throw `PermissionsException`: - `object-metadata`, `field-metadata`, `webhook`, `api-key` - `view`, `view-sort`, `view-group`, `view-filter`, `view-filter-group`, `view-field` - `page-layout`, `page-layout-widget`, `page-layout-tab` - `front-component`, `ai-generate-text` - Unit tests covering 403 / 400 / 404 / 500 mappings. ## Mapping | Code | Status | |------|--------| | `PERMISSION_DENIED`, `NO_AUTHENTICATION_CONTEXT`, `ROLE_LABEL_ALREADY_EXISTS`, `CANNOT_UNASSIGN_LAST_ADMIN`, `CANNOT_UPDATE_SELF_ROLE`, `CANNOT_DELETE_LAST_ADMIN_USER`, `ROLE_NOT_EDITABLE`, `CANNOT_ADD_OBJECT_PERMISSION_ON_SYSTEM_OBJECT`, `CANNOT_ADD_FIELD_PERMISSION_ON_SYSTEM_OBJECT` | **403** | | `INVALID_ARG`, `INVALID_SETTING`, `CANNOT_GIVE_WRITING_PERMISSION_ON_NON_READABLE_OBJECT`, `CANNOT_GIVE_WRITING_PERMISSION_WITHOUT_READING_PERMISSION`, `ONLY_FIELD_RESTRICTION_ALLOWED`, `FIELD_RESTRICTION_ONLY_ALLOWED_ON_READABLE_OBJECT`, `FIELD_RESTRICTION_ON_UPDATE_ONLY_ALLOWED_ON_UPDATABLE_OBJECT`, `EMPTY_FIELD_PERMISSION_NOT_ALLOWED`, `ROLE_MUST_HAVE_AT_LEAST_ONE_TARGET`, `ROLE_CANNOT_BE_ASSIGNED_TO_USERS` | **400** | | `ROLE_NOT_FOUND`, `OBJECT_METADATA_NOT_FOUND`, `FIELD_METADATA_NOT_FOUND`, `FIELD_PERMISSION_NOT_FOUND`, `PERMISSION_NOT_FOUND` | **404** | | All remaining "internal" codes (rethrown as-is in GraphQL) | **500** | ## Before <img width="507" height="216" alt="Screenshot 2026-05-19 at 19 26 07" src="https://github.com/user-attachments/assets/21d633aa-7ee8-4923-94e4-7ad57258a29e" /> ## After <img width="610" height="385" alt="Screenshot 2026-05-19 at 19 26 01" src="https://github.com/user-attachments/assets/0103b7ee-7df7-4aef-999a-73c22901afd2" />	2026-05-20 13:02:58 +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
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
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
Abdul Rahman	e0563377b5	Fix unclear metadata validation errors (#20234) ... https://github.com/user-attachments/assets/8f8f1122-3de1-4a9b-8bb4-a3c8d31e47ae --------- Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: Charles Bochet <charles@twenty.com>	2026-05-05 18:18:05 +00:00
Weiko	876214bc1d	scaffold record page layout + fields view when adding an object (#19977) ... ## Summary Extends `yarn twenty add` → **Object** so it scaffolds a complete record page out of the box: - A **record-page-fields view** (`<name>-record-page-fields.ts`, FIELDS_WIDGET) pre-populated with the `name` field plus the auto-generated default fields (`createdAt`, `updatedAt`, `createdBy`, `updatedBy`) — the default-field entries are emitted as `generateDefaultFieldUniversalIdentifier({ objectUniversalIdentifier, fieldName: '...' })` calls rather than pre-computed UUIDs, so the generated file double-serves as documentation for the public util. - A **record page layout** (`<name>-record-page-layout.ts`) with a Home tab whose Fields widget points at the new view (via `viewUniversalIdentifier`), plus a Timeline tab. - The companion prompt now covers all three artefacts (was view + nav menu item). Fix: Server-side, renames `viewId` → `viewUniversalIdentifier` on the universal-flat FIELDS widget configuration so it is consistent with other universal-flat references. The DB-side DTO keeps `viewId` (now typed as `SerializedRelation`), and the conversion utils map between the two. <img width="337" height="349" alt="Screenshot 2026-04-22 at 15 40 22" src="https://github.com/user-attachments/assets/59e36540-1761-46b0-808d-648c68604268" />	2026-04-22 16:30:45 +00:00
Raphaël Bosi	a88d1f4442	Introduce standalone page (#19675) ... Add support for standalone pages: a new `PageLayout` type (`STANDALONE_PAGE`) that can be rendered independently at `/page/:pageLayoutId`, not tied to any record or object context. - New `STANDALONE_PAGE` page layout type - New `PAGE_LAYOUT` navigation menu item type: adds a `pageLayoutId` foreign key to `NavigationMenuItemEntity`, allowing sidebar items to link directly to standalone pages - New `GLOBAL_OBJECT_CONTEXT` command menu availability type: separates object-context-dependent commands (Create Record, Import, Export, See Deleted, Create View, Hide Deleted) from truly global ones, so standalone pages only show relevant commands - Frontend routing & rendering: adds a `/page/:pageLayoutId` route with its own page component, header, and command menu - Widget rendering refactor - Instance commands: two fast 1.22 migrations: `pageLayoutId` column + `STANDALONE_PAGE` enum, and `GLOBAL_OBJECT_CONTEXT` availability type enum - Workspace command: backfills existing command menu items from `GLOBAL` to `GLOBAL_OBJECT_CONTEXT` where appropriate - Dev seeds: adds a sample "Star History" standalone page with an iframe widget for local development	2026-04-14 15:52:45 +00:00
Charles Bochet	b284c8323c	Remove Favorite and FavoriteFolder from workspace schema (#19536) ... ## Summary - Removes all workspace schema definitions for `Favorite` and `FavoriteFolder` entities, which have been fully migrated to `NavigationMenuItems` - Deletes 26 standalone files including workspace entities, NestJS modules, services, listeners, jobs, standard application builders (field metadata, views, view fields, view field groups, indexes, page layouts), mocks, and integration tests - Cleans up ~40 modified files: removes `favorites` relation from 10 workspace entities and their field metadata utils, removes entries from all builder maps, shared constants (`STANDARD_OBJECTS`, `CoreObjectNameSingular`, `DEFAULT_RELATIONS_OBJECTS_STANDARD_IDS`), SDK default relations, AI tool filtering, and standard object icons	2026-04-10 12:47:06 +02:00
Weiko	186bc02533	Skip email/calendar tab creation for custom object record page layouts (#19544) ... ## Context Emails and calendars can only be associated with specific objects (companies, people...) and we were adding those tabs for all custom objects. I'm removing these from the default config	2026-04-10 09:41:49 +00:00
Charles Bochet	f6423f5925	Remove DataSourceService and clean up datasource migration logic (#19532) ... ## Summary - **Drop the `objectMetadata.dataSourceId` foreign key and index** via a 1-22 fast instance command — column kept nullable for data preservation - **Delete `DataSourceService`, `DataSourceModule`, and `DataSourceException`** — all code now uses `workspace.databaseSchema` directly - **Remove `IS_DATASOURCE_MIGRATED` feature flag** from default flags and all branching logic - **Simplify workspace/object creation pipelines** — `WorkspaceManagerService`, `DevSeederService`, and the object creation action handler no longer route through `DataSourceService` - **Keep `DataSourceEntity` and the `dataSource` table** for historical data — entity stripped of all ORM relations	2026-04-10 07:34:05 +00:00
Raphaël Bosi	9080180156	[COMMAND MENU ITEMS] Sync object metadata with navigation command menu items (#19456) ... When an object is created or enabled we create a navigation command menu item to that object. And when the object is disabled or deleted, we remove this command menu item.	2026-04-09 08:18:49 +00:00
Weiko	6e23ca35e6	Pagelayout backfill command standard app (#19380) ... ## Context Due to the chosen strategy for "Reset to default" feature for page layouts. Those overridable entities need to be associated to the Standard app to work properly (there is no "Default" state for custom entities). Until we find a better implementation, I'm changing the backfill command to reflect that	2026-04-07 12:49:35 +00:00
Félix Malfait	bb3d556799	Refined demo workspace creation skill (rebased, review fixes) (#19274) ... ## Summary Rebased version of #19051 with all review comments addressed. Clean branch on latest main, lint/typecheck/tests passing. ### Changes from original PR - AI can now create, update, and delete **view filters** (`ViewFilterToolsFactory`) and **view sorts** (`ViewSortToolsFactory`) - `create_view` now accepts `calendarFieldName`, `calendarLayout`, and `fieldNames` to configure views at creation time - Three new standard skills: `view-building`, `view-filters-and-sorts`, `custom-objects-cleanup` - `workspace-demo-seeding` skill reworked to keep standard objects and enrich them with custom fields - Cache invalidation for nav menu items when object `isActive` changes - Dashboard tool descriptions improved (RECORD_TABLE widget workflow) ### Review comments addressed (all 10 from #19051) 1. **Sentry + Cubic**: Calendar field DATE/DATE_TIME validation — added `resolveCalendarFieldMetadataId` using `isFieldMetadataDateKind` 2. **Cubic**: "navigate tool" → "navigate_app tool" in skill metadata (all 7 occurrences) 3. **Copilot**: KANBAN views now require `mainGroupByFieldName` — throws clear error if missing 4. **Copilot**: CALENDAR views now require both `calendarFieldName` and `calendarLayout` — validated before DB call 5. **Copilot**: Mock field fixtures include `type` property (DATE_TIME, TEXT, SELECT) 6. **Copilot**: `ViewFilterValue` type assertion instead of unsafe `as string` casts (3 locations) 7. **FelixMalfait**: Removed `NavigationMenuItemObjectDeactivationListener` — replaced with cache invalidation 8. **FelixMalfait**: Consolidated `ViewFilterToolProvider` and `ViewSortToolProvider` into single `ViewToolProvider` 9. Removed `VIEW_FILTER` and `VIEW_SORT` from `ToolCategory` enum (merged into `VIEW`) 10. Removed stale `existingFeatureFlagsMap` param incompatible with current main ## Test plan - [x] `npx nx lint:diff-with-main twenty-server` — passes - [x] `npx nx typecheck twenty-server` — passes - [x] `view-tools.factory.spec.ts` — all 20 tests pass (including 3 new validation tests) Supersedes #19051 https://claude.ai/code/session_01QPV74NU6vzmJb32e4i899E --------- Co-authored-by: Claude <noreply@anthropic.com>	2026-04-03 09:19:46 +02:00
Weiko	c1e4756f9c	Add is active to overridable entities and deactivation logic for page layouts (#19200) ... - Replace soft-deletion (deletedAt) with isActive boolean for overridable entities (tabs, widgets, viewFieldGroups, viewFields). Standard entities are deactivated (isActive: false) when removed from update payloads, while custom entities are hard-deleted. - When a viewFieldGroup is deactivated/deleted, its viewFields are reassigned to the next section by position (or null if none remain). - Add isActive: true filters to viewFieldGroup and viewField API queries so deactivated entities are excluded from responses. Next: - fields-widget-upsert.service.ts should be refactored a bit - Add restore logic	2026-04-02 14:50:50 +00:00
Charles Bochet	e8cb086b64	chore: remove completed migration feature flags and upgrade commands <= 1.18 (#19074) ... ## Summary - Remove 3 completed migration feature flags: `IS_ATTACHMENT_MIGRATED`, `IS_NOTE_TARGET_MIGRATED`, `IS_TASK_TARGET_MIGRATED` — these were already enabled by default for all new workspaces via `DEFAULT_FEATURE_FLAGS` - Delete all upgrade command directories for versions <= 1.18 (`1-16/`, `1-17/`, `1-18/`) along with their module registrations, removing ~6,600 lines of dead migration code - Simplify frontend utility functions (`getActivityTargetObjectFieldIdName`, `getActivityTargetsFilter`, `getActivityTargetFieldNameForObject`, `generateActivityTargetMorphFieldKeys`, `findActivitiesOperationSignatureFactory`) by removing the `isMorphRelation` parameter and always using the morph relation path - Remove feature flag checks from 7 frontend hooks/components that were gating attachment and activity target behavior behind the removed flags - Simplify `buildDefaultRelationFlatFieldMetadatasForCustomObject` server util to always treat attachment, noteTarget, and taskTarget as morph relations without checking feature flags	2026-03-29 09:15:26 +02:00
Abdul Rahman	5efe69f8d3	Migrate field permission to syncable entity (#18751) ... Co-authored-by: Copilot Autofix powered by AI <223894421+github-code-quality[bot]@users.noreply.github.com> Co-authored-by: Charles Bochet <charles@twenty.com>	2026-03-27 14:47:27 +01:00
Baptiste Devessier	da1b1f1cbc	Combine and clean upgrade commands for record page layouts (#19004) ... - Remove the label identifier field for all standard objects as it's a first-class citizen that is displayed specifically in the app; it doesn't make a lot of sense to display it in the Fields widgets - Disable logic that made the label identifier required and in first position - Add all fields for all standard objects in record page layout view fields - Do not include position and ts vector fields in custom objects > [!IMPORTANT] > The command will create Field widgets for all relations. It is consistent to the way the frontend dynamically generates them as of today. We will have to decide which relations we pin as individual Field widgets before the release. (This will likely land in this command or in another one.)	2026-03-26 17:50:29 +01:00
Baptiste Devessier	cc247c2e8e	Fix record page layout upgrade commands (#18962) ... - Fix issue with name that must be first in the view field list - Improve dry run and logs of backfill page layouts command --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: prastoin <paul@twenty.com>	2026-03-25 16:43:54 +00:00
Félix Malfait	5f0d6553f6	Add object type filter dropdown to side panel record searches (#18912) ... ## Summary - Adds an object type filter dropdown to the side panel, allowing users to scope record search results to a specific object type (e.g. People, Companies, Opportunities) - The filter appears as a funnel icon next to the search input in both the global search (SearchRecords page) and the "Pick a record" sidebar flow - Replaces the AI sparkles button on the search records page with the filter icon - Uses colored icons matching the navigation menu style (NavigationMenuItemStyleIcon + getStandardObjectIconColor) ## Test plan - [ ] Open the side panel, type something to enter SearchRecords mode, verify the filter icon appears - [ ] Click the filter icon, verify the dropdown opens with "Object" header, search input, "All Objects" and individual object types with colored icons - [ ] Select an object type, verify only records of that type appear in search results - [ ] Select "All Objects", verify all record types appear again - [ ] Verify the filter icon turns blue when a filter is active - [ ] In layout customization mode, add a new sidebar item > Record, verify the filter dropdown also works there - [ ] Close and reopen the side panel, verify the filter resets to "All Objects" - [ ] Verify the AI sparkles button no longer appears on the command menu root page - [ ] Verify the AI edit icon still appears on Ask AI pages Made with [Cursor](https://cursor.com)	2026-03-25 16:02:24 +01:00
Charles Bochet	a74edbf715	fix: route object color through standardOverrides for standard objects (#18717) ... ## Summary - Fixes object `color` to use the `standardOverrides` mechanism for standard objects, matching how `label`, `description`, and `icon` already work - Previously, color was written directly to the `objectMetadata.color` column for **both** standard and custom objects, which meant user color customizations on standard objects could be overwritten during metadata syncs - Custom objects continue to have `color` updated directly on the entity (no change) ## Changes | File | What changed | |------|-------------| | `object-metadata-standard-overrides-properties.constant.ts` | Added `'color'` to `OBJECT_METADATA_STANDARD_OVERRIDES_PROPERTIES` so `sanitizeRawUpdateObjectInput` routes color into `standardOverrides` for standard objects | | `resolve-object-metadata-standard-override.util.ts` | Extended to support `'color'` as a key — handled like `icon` (no i18n/translation, just direct override check) | | `object-metadata.resolver.ts` | Added `@ResolveField` for `color` that resolves through `resolveObjectMetadataStandardOverride`, matching the existing `labelSingular`/`labelPlural`/`description`/`icon` resolve fields | | `flat-object-metadata-validator.service.ts` | Removed `'color'` from `allowedOverrideKeys` for system objects since it now flows through `standardOverrides` | | `resolve-object-metadata-standard-override.util.spec.ts` | Added test cases for custom object color, standard object color override, and standard object color fallback | | `successful-update-one-standard-object-metadata.integration-spec.ts` | Added `'when updating color'` test case, included `color` in GraphQL queries and `standardOverrides` fragment, reset color in `afterEach` cleanup | ## How it works now | Object type | Color update flow | |---|---| | **Custom** | Written directly to `objectMetadata.color` column | | **Standard** | Stored in `objectMetadata.standardOverrides.color`, resolved via `@ResolveField` at query time | This is identical to how `label`, `description`, and `icon` have always worked. ## Test plan - [x] Unit tests pass (`resolve-object-metadata-standard-override.util.spec.ts` — 21 tests) - [x] Typecheck passes (`npx nx typecheck twenty-server`) - [x] Lint passes (`npx nx lint:diff-with-main twenty-server`) - [ ] Integration test snapshot regenerates correctly (`successful-update-one-standard-object-metadata`) - [ ] Verify standard object color editing from sidebar persists via `standardOverrides` - [ ] Verify custom object color editing from sidebar persists directly on entity Made with [Cursor](https://cursor.com)	2026-03-18 10:40:57 +01:00
Charles Bochet	a121d00ddd	feat: add color property to ObjectMetadata for object icon customization (#18672) ... ## Summary - Adds a `color` column to `ObjectMetadataEntity` with full GraphQL support so object icon colors are persisted at the metadata level - Adds a `type` column to `NavigationMenuItemEntity` (enum: `OBJECT`, `VIEW`, `FOLDER`, `LINK`, `RECORD`) replacing field-based type inference - Updates frontend to read object colors from `objectMetadata.color` (falling back to standard defaults) in the sidebar nav, record index header, and record show breadcrumb - Simplifies `NavigationMenuItemIcon` color resolution via `getEffectiveNavigationMenuItemColor` util ## Color rules | Item type | Color source | Editable in sidebar? | |-----------|-------------|---------------------| | **Object** | `objectMetadata.color` | Yes — persisted to `objectMetadata.color` on Save | | **Folder** | `navigationMenuItem.color` | Yes | | **Link** | Fixed default (`DEFAULT_NAVIGATION_MENU_ITEM_COLOR_LINK`) | No | | **View** | `objectMetadata.color` (from the parent object) | No | | **Record** | None | No | - **Object** items represent the whole object (e.g. "Companies") and point to the INDEX view. Changing their color updates `objectMetadata.color` via `useSaveObjectMetadataColorsFromDraft`. - **View** items represent specific non-INDEX views. Their color comes from the parent object's metadata (read-only). - Only **folders** store their color on `navigationMenuItem.color` — enforced by `hasNavigationMenuItemOwnColor` util. - `getEffectiveNavigationMenuItemColor` returns `objectColor` for both OBJECT and VIEW items, folder's own color for folders, and the fixed default for links. ## NavigationMenuItemType enum - Shared enum created in `twenty-shared` with values: `OBJECT`, `VIEW`, `FOLDER`, `LINK`, `RECORD` - Registered as a GraphQL enum on the backend - Replaces string literals across entity, DTOs, input, converters, and frontend hooks - Migration backfills existing rows: INDEX views → `OBJECT`, non-INDEX views → `VIEW`, based on join with the view table ## Design decisions - **OBJECT vs VIEW distinction**: Items pointing to INDEX views are typed as `OBJECT` (represent the whole object, color editable). Items pointing to non-INDEX views are typed as `VIEW` (specific view, color read-only from parent object). - **Dual color storage**: `navigationMenuItem.color` is preserved for folders only. Objects use `objectMetadata.color` as their source of truth. - **Type discriminator**: The `type` column replaces field-based inference (checking `viewId`, `link`, `targetRecordId` presence) with an explicit enum, simplifying `isNavigationMenuItemLink` / `isNavigationMenuItemFolder` to simple `item.type ===` checks. - **No settings page color picker**: Object color editing is done from the sidebar edit panel, not the data model settings page. ## Test plan - [ ] Verify objects display their default standard colors in the sidebar - [ ] Verify object color editing works in the sidebar edit panel (persists to objectMetadata.color) - [ ] Verify folder color editing works in the sidebar edit panel - [ ] Verify views, links, and records do NOT show a color picker in the sidebar edit panel - [ ] Run `npx nx typecheck twenty-front` and `npx nx typecheck twenty-server` - [ ] Verify the database migrations add `color` to `objectMetadata` and `type` to `navigationMenuItem` Made with [Cursor](https://cursor.com)	2026-03-16 23:54:56 +01:00
Weiko	b6b96be603	Fix custom object view fields creation (#18629)	2026-03-16 17:24:44 +01:00
Assad Robles	cb4efb1d0e	fix: respect standard object rename across all locales (Closes #18650) (#18652) ... ## Fix: Standard object rename ignored when UI language is not English (Closes #18650) ### Problem When a user renames a standard object (for example, changing **"People" → "Contacts"**), the custom name is only respected when the UI language is set to **English**. For any other locale, the resolver ignores the user-defined override and falls back to the i18n translation of the original default label. As a result, the custom name defined by the user is not displayed when the UI language changes. ### Root Cause `resolveObjectMetadataStandardOverride` only applied direct overrides when the locale matched `SOURCE_LOCALE` (English): ```ts if ( safeLocale === SOURCE_LOCALE && isNonEmptyString(objectMetadata.standardOverrides?.[labelKey]) ) { return objectMetadata.standardOverrides[labelKey] ?? ''; }	2026-03-16 17:01:04 +01:00
Weiko	48172d60fd	View field override (#18572) ... ## Context This PR introduces overrides for view fields which will be useful for page layout FIELDS widgets fields position/groups/visibility override + restore logic.	2026-03-14 12:40:15 +01:00
Charles Bochet	6b48f197d4	feat: deprecate WorkspaceFavorite in favor of NavigationMenuItem (#18624) ... ## Summary - **Removes the entire `modules/favorites/` directory** (~66 files, ~5000 lines deleted) — components, hooks, states, types, utils, tests, and the favorite-folder-picker sub-module - **Eliminates the dual-write pattern** where creating a favorite also created a NavigationMenuItem — all consumers now use `useCreateNavigationMenuItem` directly - **Removes `IS_NAVIGATION_MENU_ITEM_EDITING_ENABLED` feature flag checks** from ~12 files, always taking the NavigationMenuItem code path - **Cleans up backend dual-writes** in `object-metadata.service.ts` and `twenty-standard-application.service.ts` that were creating Favorite records alongside NavigationMenuItems - **Updates prefetch system** to only load NavigationMenuItems (removes favorites prefetch effects and states) - **Cleans up test infrastructure** — updates Storybook decorators, mock data, and graphql mocks to remove favorites references ### What was intentionally kept - **Backend entity definitions** (`FavoriteWorkspaceEntity`, `FavoriteFolderWorkspaceEntity`) — these define the database schema and need a proper database migration to remove - **Cascade deletion listeners** — still needed to clean up existing Favorite data in workspaces that haven't been fully migrated - **v1.18 migration commands** — needed for workspaces upgrading from older versions --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>	2026-03-13 19:45:40 +01:00
martmull	5bfa4c5c39	Fix wrong uuid error (#18590) ... as title --------- Co-authored-by: Charles Bochet <charles@twenty.com>	2026-03-12 16:12:30 +01:00
Weiko	c433b2b73f	Implement page layout override (#18472)	2026-03-09 17:21:08 +00:00
martmull	403db7ad3f	Add default viewField when creating object (#18441) ... as title	2026-03-06 14:59:31 +01:00
Charles Bochet	9d57bc39e5	Migrate from ESLint to OxLint (#18443) ... ## Summary Fully replaces ESLint with OxLint across the entire monorepo: - **Replaced all ESLint configs** (`eslint.config.mjs`) with OxLint configs (`.oxlintrc.json`) for every package: `twenty-front`, `twenty-server`, `twenty-emails`, `twenty-ui`, `twenty-shared`, `twenty-sdk`, `twenty-zapier`, `twenty-docs`, `twenty-website`, `twenty-apps/*`, `create-twenty-app` - **Migrated custom lint rules** from ESLint plugin format to OxLint JS plugin system (`@oxlint/plugins`), including `styled-components-prefixed-with-styled`, `no-hardcoded-colors`, `sort-css-properties-alphabetically`, `graphql-resolvers-should-be-guarded`, `rest-api-methods-should-be-guarded`, `max-consts-per-file`, and Jotai-related rules - **Migrated custom rule tests** from ESLint `RuleTester` + Jest to `oxlint/plugins-dev` `RuleTester` + Vitest - **Removed all ESLint dependencies** from `package.json` files and regenerated lockfiles - **Updated Nx targets** (`lint`, `lint:diff-with-main`, `fmt`) in `nx.json` and per-project `project.json` to use `oxlint` commands with proper `dependsOn` for plugin builds - **Updated CI workflows** (`.github/workflows/ci-*.yaml`) — no more ESLint executor - **Updated IDE setup**: replaced `dbaeumer.vscode-eslint` with `oxc.oxc-vscode` extension, configured `source.fixAll.oxc` and format-on-save with Prettier - **Replaced all `eslint-disable` comments** with `oxlint-disable` equivalents across the codebase - **Updated docs** (`twenty-docs`) to reference OxLint instead of ESLint - **Renamed** `twenty-eslint-rules` package to `twenty-oxlint-rules` ### Temporarily disabled rules (tracked in `OXLINT_MIGRATION_TODO.md`) | Rule | Package | Violations | Auto-fixable | |------|---------|-----------|-------------| | `twenty/sort-css-properties-alphabetically` | twenty-front | 578 | Yes | | `typescript/consistent-type-imports` | twenty-server | 3814 | Yes | | `twenty/max-consts-per-file` | twenty-server | 94 | No | ### Dropped plugins (no OxLint equivalent) `eslint-plugin-project-structure`, `lingui/*`, `@stylistic/*`, `import/order`, `prefer-arrow/prefer-arrow-functions`, `eslint-plugin-mdx`, `@next/eslint-plugin-next`, `eslint-plugin-storybook`, `eslint-plugin-react-refresh`. Partial coverage for `jsx-a11y` and `unused-imports`. ### Additional fixes (pre-existing issues exposed by merge) - Fixed `EmailThreadPreview.tsx` broken import from main rename (`useOpenEmailThreadInSidePanel`) - Restored truthiness guard in `getActivityTargetObjectRecords.ts` - Fixed `AgentTurnResolver` return types to match entity (virtual `fileMediaType`/`fileUrl` are resolved via `@ResolveField()`) ## Test plan - [x] `npx nx lint twenty-front` passes - [x] `npx nx lint twenty-server` passes - [x] `npx nx lint twenty-docs` passes - [x] Custom oxlint rules validated with Vitest: `npx nx test twenty-oxlint-rules` - [x] `npx nx typecheck twenty-front` passes - [x] `npx nx typecheck twenty-server` passes - [x] CI workflows trigger correctly with `dependsOn: ["twenty-oxlint-rules:build"]` - [x] IDE linting works with `oxc.oxc-vscode` extension	2026-03-06 01:03:50 +01:00
Baptiste Devessier	4965790ecc	Backfill record page layouts for custom objects (#18428)	2026-03-05 17:52:21 +01:00