489 Commits

Author	SHA1	Message	Date
Félix Malfait	393e62ba9f	Make AI chat streaming render cost independent of message length (#23831) ... Follow-up to #23573: chip-heavy answers are long by design, and each stream flush re-ran `protectChatReferencesForMarkdown` and `marked.lexer` over the whole message, so render cost grew quadratically with message length. This makes the per-flush cost proportional to the appended text instead, and offsets the new code by removing dead AI chat code. ## Streaming render - **Incremental block splitting.** `getMarkdownBlocksIncrementally` reuses blocks that can no longer change and re-tokenizes only the trailing ones. Two trailing blocks stay unstable, not one: a loose list followed by a blank line still merges with a later item (`- a\n\n` + `- b` is one list token). Uses `Lexer.blockTokens` instead of `marked.lexer` since only block raws are needed and the full lexer also runs the inline tokenizer. Simulated stream over a 22 KB chip-heavy message (120 chars/flush, matching the 100 ms flush throttle): 191 ms → 3.7 ms cumulative. The test suite pins char-by-char equivalence against full `marked.lexer` output across loose lists, unclosed fences, setext headings, tables, CRLF and chip markers. - **Per-block reference protection.** `protectChatReferencesForMarkdown` moved behind the existing block memo, so settled blocks never re-run reference parsing during a stream. - **Anchored open pattern.** `(?<!\[)\[\[+` anchors marker matching to the start of a bracket run. The greedy `+` from #23798 backtracked at every position inside a run, once per alternative: 429 ms → ~1 ms on a 10 KB bracket-run input. A run start always yields the same match, so no valid marker is lost. Also an `includes('[[')` bail-out in `findChatReferences`, which runs on every text node of the streaming block. ## Chip lookups `fieldMetadataItemByIdSelector` did `objectMetadataItems.find(obj => obj.fields.some(...))` per chip — O(workspace fields) each time the agent's tool calls trigger a metadata refetch mid-chat. The by-id and by-name map selectors mostly already existed with almost no consumers; this wires `fieldMetadataItemByIdSelector`, `objectMetadataItemFamilySelector` and `viewFromViewIdFamilySelector` to them (adding the missing `objectMetadataItemsByIdMapSelector` and `viewsByIdMapSelector`) and adds `areEqual` so unchanged lookups keep referential stability. ## Offscreen messages Settled messages (everything except the streaming last one) get `content-visibility: auto`, so long threads skip layout and paint for messages scrolled out of view. `contain-intrinsic-size: auto` keeps remembered heights, so scroll positions stay accurate once a message has been painted. ## Removed `ReasoningSummaryDisplay`, `agentChatMessagesComponentState`, `CHAT_THREADS_PAGE_SIZE`, `AgentResponseFormat` and `getFieldIcon` had no consumers. `TextWithChatReferences` and `protectChatReferencesForMarkdown` shared a duplicated segment-slicing loop, now in `getChatReferenceSegments`, and the nine identical per-tag markdown component entries collapse into `createChatReferenceElement`. The branch lands at +354/−329 including the new test suite; production code is net negative. Incidental: `marked` added to jest's `transformIgnorePatterns` allowlist (ESM-only, previously imported by no test). --- _Generated by [Claude Code](https://claude.ai/code/session_01MN8FVc63J4SJQHXWwzUwkh)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23831?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-08-05 20:31:57 +02:00
Abdul Rahman	5effee7754	Fix grouping a view that can no longer be changed or removed (#23619) ... Fixes #23529 https://github.com/user-attachments/assets/2dbcf5ac-9b2e-4331-b7e8-703c8c5384b5 Grouping People by Company was a one-way door: once the view was grouped, the grouping could neither be changed nor removed. Two independent bugs on the same path caused it, and both had to be fixed. ## 1. The Group by entry was disabled, so the picker was unreachable `ObjectOptionsDropdownRecordGroupsContent` disabled the `Group by` entry whenever the object had a single groupable field. People exposes exactly one (Company), so the entry was always disabled there. That entry is the only way back to the field picker once a view is grouped: `ObjectOptionsDropdownCustomView` sends `Group` to the picker while the view is ungrouped, and to the group management screen once it is grouped. With the entry disabled, the picker, and with it the `None` option, became unreachable. A table view can always drop its grouping through `None`, so the entry now stays enabled there and is only disabled for layouts that require a grouping. ## 2. The view groups created by the server were never synced back The server deletes and recreates the view groups whenever `mainGroupByFieldMetadataId` changes (`handleFlatViewUpdateSideEffect`), and returns them in the `updateView` payload. `usePerformViewAPIUpdate` only wrote the view itself back to the metadata store, so the `viewGroups` entity kept the pre-change rows. The view create path already syncs them; the update path did not. On top of that, `useHandleRecordGroupField` overwrote the groups returned by the mutation with client-generated ones whose ids matched no persisted row, and `resetRecordGroupField` bailed out on `viewGroups.length === 0`. Since a relation grouping legitimately starts with no groups, clicking `None` was a no-op even when it could be reached. - sync the view groups returned by `updateView` into the metadata store - use those groups instead of regenerating them client-side - reset the grouping based on `mainGroupByFieldMetadataId`, and reload the record index states so the table regroups and ungroups without a refresh ## 3. Drive-by: No Value missing from the widget draft preview `buildDraftViewGroupsForFieldMetadataItem` mirrors `computeFlatViewGroupsOnViewCreate` so the page layout widget preview matches what gets persisted, but it returned early for relation fields and skipped the empty group. The server keeps creating it for nullable fields, relations included, so the group appeared out of nowhere once the widget was saved. It now skips only the option groups and keeps the empty group. ## Not changed Grouping by a relation shows no groups until you add them through `New group`. That is intended, since a relation can have an unbounded number of groups, and nothing here changes it.	2026-08-05 09:39:18 +00:00
Charles Bochet	4b3614b413	fix(front): show relation value chip (Me / record names) in advanced filters (#23718) ... ## Problem In advanced filters, a relation filter on a workspace-member field (e.g. Assignee "is Me") displayed its raw JSON value `{"isCurrentWorkspaceMemberSelected":true,...}` instead of a readable chip. Regular (non-advanced) filters handle this correctly: `EditableRelationFilterChip` computes the label at runtime via `useComputeRecordRelationFilterLabelValue`, rendering "Me", the selected record names, or "N members". The advanced filter value input instead relied on the deprecated stored `displayValue` through `getRecordFilterDisplayValue`, which has no `RELATION` branch and falls back to the raw value. When a saved view filter carries no `displayValue` (it defaults to the raw stringified value in `mapViewFiltersToFilters`), the raw JSON leaked into the UI. ## Fix - Extract the relation value-label computation into a shared hook `useComputeRecordRelationFilterDisplayValue` (parses the relation value, resolves "Me" + record names). - `useComputeRecordRelationFilterLabelValue` now consumes it (regular chips unchanged). - The advanced filter clickable select renders a dedicated `AdvancedFilterRelationValueInputClickableSelect` for `RELATION` filters, computing the label at runtime just like regular filters. ## Proof Both filter surfaces render the relation value as **Me**, not the raw `{"isCurrentWorkspaceMemberSelected":...}` JSON. The advanced-filter shot loads a **saved view in a fresh session** — the exact bug condition, where the view filter carries no stored `displayValue`. **Regular filter chip** <img width="1280" height="760" alt="image" src="https://github.com/user-attachments/assets/8a867f51-a538-46f2-ba21-a16bb70d85a5" /> **Advanced filter** <img width="1280" height="760" alt="image" src="https://github.com/user-attachments/assets/b09b9d70-5692-4bac-8cec-3cb006961042" /> ## Test Verified manually on a local instance: created a saved view with an advanced filter `Account Owner Is Me`, then reloaded it in a fresh session — the condition where the view filter carries no stored `displayValue`. The value renders as "Me" instead of the raw JSON. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23718?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-08-04 11:11:53 +00:00
Thomas Trompette	a747e62970	fix(workflow): use as draft with an existing draft and cross-object record page filters (#23524) ... Fixes two workflow issues. ### "Use as draft" fails when a draft already exists `UseAsDraftWorkflowVersionSingleRecordCommand` rendered its own `OverrideWorkflowDraftConfirmationModal`. Headless commands are unmounted by `HeadlessEngineCommandWrapperEffect` as soon as `execute` resolves, so the modal was removed from the tree right after `openModal` was called and the user saw nothing happen. This regressed when the command was converted from a rendered `<Command onClick>` to a self-unmounting effect. The command now uses `HeadlessConfirmationModalEngineCommandEffect`, the existing mechanism for headless commands that need a confirmation: it opens the app-wide `CommandMenuConfirmationModalManager` and keeps the command mounted until the modal emits its result. `OverrideWorkflowDraftConfirmationModal`, its modal id and its config state are deleted. To keep the "Go to Draft" shortcut, the shared confirmation modal config gains an optional `linkButton` rendered as a secondary link button that emits a `cancel` result on click. The command also resolved the workflow id through `useWorkflowVersion`, which is `undefined` while the query is in flight, so it threw and surfaced an error snackbar through the command error boundary. It now reads the workflow id off the selected record like the sibling workflow version commands, and waits for the workflow to load before deciding whether a confirmation is needed. ### `workflow object doesn't have any "workflowId" field` when opening a workflow from a version `useRecordShowPagePagination` builds prev/next queries from the parent view stored in `contextStoreRecordShowParentViewComponentState`. Navigating from a workflow version record page to its workflow through the relation chip keeps the workflow version parent view, whose relation filter compiles to `workflowId: { in: [...] }` and is then sent against the `workflow` object, which the API rejects. `useQueryVariablesFromParentView` now ignores the parent view when `parentViewObjectNameSingular` does not match the current object, which covers every navigation path between record pages of different objects. ### Test Added `useQueryVariablesFromParentView.test.tsx` covering both the matching and mismatching parent view object. Manually checked on a local instance: override with an existing draft, "Go to Draft", cancel then re-trigger, and the no-existing-draft path, plus navigating from a filtered workflow versions view to a workflow. --------- Co-authored-by: Tom <tom@twenty.com>	2026-07-30 16:45:25 +00:00
Félix Malfait	3a8f086d15	Converge drag and drop on shared dnd-kit primitives, remove @hello-pangea/dnd (#23211) ... Follow-ups recorded in #23023, done in one pass. ## Shared primitives - Folded `PageLayoutWidgetSortableItem` and `PageLayoutWidgetDropLine` into the shared `DragDropItemSortableCell` / new `DragDropItemDropLine` (new `data`, `dropLine`, `highlightWhileDragging`, `hasTransition` props). - Added generic `DragDropProviderDragStartEvent` (and DragMove/DragOver/DragEnd/DropTarget) helpers and deleted the 7 copied `Parameters<...>` extractions across the dnd hooks. - Replaced the `useMovePageLayoutWidgetUp/Down` implementations (~140 lines) with `moveWidgetWithinTabInDraft`. - Migrated the remaining page-layout test suites onto `pageLayoutDraftFixtures`. ## Tab reordering off Pangea - Tabs are sortable cells on the same provider as widget drags, segregated by dnd type, so widget drops on tab buttons keep working while tabs reorder. - Reordering is ID based (`reorderTabInDraft`: insert before the hovered tab), which keeps the pinned first tab in place without index arithmetic. - Preserved overflow behaviors: the dropdown stays open while a tab drag is in flight, dropping a tab on the "+N More" button appends it and opens the dropdown, and both the visible strip and the overflow list have end drop zones. ## Fields configuration editors off Pangea - Group reorder, field reorder and cross-group field moves now run on the shared cells (same drop line and end-zone patterns). ## DraggableList off Pangea - `DraggableList` / `DraggableItem` keep their consumer-facing API — the ~9 consumers now type their handlers with a local `DraggableListDropResult` instead of pangea's `DropResult` — but run on the shared sortable cells; each list's uuid group doubles as its dnd type so nested lists stay isolated from page-level providers. - Items register their index in a list-scoped registry so the end drop zone can resolve the append index at drop time (with insert-before semantics an item could otherwise never reach the last position). - Deleted three dead files that only existed for pangea plumbing (the side panel navigation placeholder, `getCssCompatibleDraggableProps`, the orphaned `recordGroupPendingDragEndReorderState`). ## Record table row drag off Pangea - Rows register through `useSortable` directly on the row element — no wrapper div, so row CSS, sticky cells and virtualization stay untouched — with the grip cell wired as the drag handle via the shared sortable handle ref context. - Both table modes (virtualized flat list and record groups) share a `DragOverlay` clone that replaces pangea's virtual-mode `renderClone`, and end drop zones per record group (and after the virtualized list) allow dropping after the last row or into an empty group. - The drop handlers keep their pangea-shaped result object, retyped as a local `RecordDragDropResult`, so the position computation logic is untouched. ## Pangea removed `@hello-pangea/dnd` is gone from `package.json` and the lockfile, along with its orphaned transitive entries (`css-box-model`, `raf-schd`, `react-redux`, `redux`). Nothing in the repo imports it anymore. ## Dashboards: cross-tab widget drag for grids react-grid-layout drags never enter dnd-kit, so the bridge hit-tests the pointer against the tab buttons' `data-page-layout-tab-drop-target-id` rects during grid drags, highlights the hovered tab through state, and on drop moves the widget to the destination grid below its existing content (`moveWidgetToGridTabInDraft`, `buildTabWidgetLayouts`). The grid's own post-drag layout commit is suppressed once so it does not overwrite the cross-tab move. ## Fixes found while testing - With `feedback: 'clone'`, the drag source is its own initial drop target and its placeholder is a DOM clone taken at drag start, so the drop line rendered into the source got baked into the placeholder and stuck there for the whole drag. The line is now hidden on the source cell, leaving a single indicator at the actual target. - Reorderable tabs collapsed to text height and sat top-aligned next to "+ New Tab" because the sortable cell wrapper defaults to `display: block; height: auto`, breaking the tab height chain — the tab list now uses the cell's `fill` mode so tabs stretch to the strip height again. ## Testing Playwright against the dev app: - Record page: widget reorder up and down in the pinned column (single blue drop line at the target), drag to another tab via its tab button (highlight + move), drag back into content at a specific position, chained cross-tab moves, tab reorder with vertical drop line, new tab creation. - Overflow (narrow viewport): drop a tab on "+N More" (appends last, dropdown opens), reorder inside the dropdown (stays open), drag a tab from the dropdown back to the visible strip. - Dashboard: grid drag within a tab, cross-tab drag onto a tab button (hover highlight, widget lands below destination content, remaining widgets keep their positions), save and reload persistence in both directions. - Fields editor: field reorder, group reorder, field move across groups, plus the Move Up / Move Down widget actions. Since the pangea-removal commits: - Typecheck, oxlint and oxfmt green over the full front source; unit suites green including the migrated `useStartRecordDrag` test (jest needed a scoped transform exemption for `@preact/signals-core` once dnd-kit reached the side-panel suites). - Storybook visual regression unchanged across ~700 stories — expected, since the migrated surfaces render identical DOM at rest (drop lines and drag overlays only exist mid-drag). - The tab strip fix reverses the exact regression mechanism: the sortable cell wrapper defaulted to `display: block; height: auto`, collapsing the tab height chain next to the full-height "+ New Tab" button; `fill` restores the stretch. --- _Generated by [Claude Code](https://claude.ai/code/session_01XKRCzzu8oGyocXZtFp7VEG)_ <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23211?utm_source=github" rel="nofollow noreferrer noopener" target="_blank">``&lt;img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"&gt;``</a>	2026-07-24 14:04:13 +02:00
Paul Rastoin	987995636f	Sync metadata store after view child entity mutations server response (#23150) ... ## Summary - View persist hooks (`usePerformView(Sort|Field|Filter|Group|FieldGroup|FilterGroup|)APIPersist`) now write successful mutation results back to the metadata store (`addToDraft` / `updateInDraft` / `removeFromDraft` + `applyChanges`), following the existing pattern from `usePerformViewAPIUpdate`. - Previously the store only updated via SSE, so until that landed, save flows diffed against stale view data and re-sent creates with the same id — failing server-side with a duplicate key error. Fixes TWENTY-SERVER-HQM	2026-07-22 19:05:22 +02:00
Félix Malfait	3ad3e8bd1a	feat: kanban, calendar and group-by table layouts for dashboard view widgets (#22963) ... ## Context Dashboard view widgets previously only rendered flat tables. This PR ships the full feature: **Table with group-by**, **Kanban**, and **Calendar** layouts for dashboard view widgets — server API + frontend, end-to-end. (Originally staged as a 4-PR stack — #22966, #22967, #22968 — consolidated here per review.) ## Server / API - **View typing.** Adds `KANBAN_WIDGET` and `CALENDAR_WIDGET` to `ViewType` (following the `TABLE_WIDGET` precedent) so widget-backing views keep their layout in `view.type` while staying excluded from record-index pickers. Shared `getViewLayoutFromViewType()` maps widget types to their base layout; `isWidgetViewType()` centralizes the exclusions that were previously hardcoded per-site. - **Migrations.** Two fast instance commands (**2.23**): `ALTER TYPE core.view_type_enum ADD VALUE` for both values, and a widened `CHK_VIEW_CALENDAR_INTEGRITY` constraint covering `CALENDAR_WIDGET` (entity `@Check` updated for fresh installs). - **Validation.** `FlatViewValidatorService` keys kanban/calendar validation on the mapped layout, so widget views get the same invariants as index views (kanban needs a groupable group-by field; calendar needs a date field + layout). Calendar widget views default to month; a non-month (DAY/WEEK) layout is rejected at the API level **unless** the `IS_CALENDAR_WEEK_VIEW_ENABLED` feature flag is enabled for the workspace — the same flag that gates day/week on index calendars. - **API.** `upsertViewWidget` (LAYOUTS permission) accepts a nested `view` settings input (`type`, `mainGroupByFieldMetadataId`, `shouldHideEmptyGroups`, kanban aggregate/column-width, calendar layout/fields). Routes through the standard update path, so `viewGroups` auto-generate from SELECT options exactly like index views. Only widget view types accepted; only `RECORD_TABLE` widgets can change view settings. - **AI tools.** `create-complete-dashboard` + `create_view` now use/allow the `*_WIDGET` types (previously they created plain `TABLE` views that leak into index pickers). ## Frontend **Settings panel.** The **Source** (object) row comes first, since which layouts are available depends on it. The **Layout** row below is a working dropdown (Table / Kanban / Calendar); layouts the source object can't support are **disabled with a hint** ("Needs a Select field" / "Needs a Date field") rather than hidden. Group-by row (select fields; searchable) with a **Hide empty groups** toggle while grouped; **Date field** row replaces Group by while Calendar is active, and — when the `IS_CALENDAR_WEEK_VIEW_ENABLED` flag is on — a **Calendar view** row (Day / Week / Month) appears beside it; **Limit** row hidden while grouped (only the flat virtualized loader enforces it). Kanban keeps its group-by locked (no `None` option). **Instant edit-mode preview.** Draft snapshots carry `viewGroups`; picking a group-by synthesizes them client-side (`buildDraftViewGroupsForFieldMetadataItem`, mirroring the server&#39;s generation), so grouped tables/boards preview immediately before dashboard save. On save, `upsertViewWidget` responses hand back the server-generated groups, which replace the client-generated ones in the persisted snapshot. **Renderers.** `RecordTableWidgetRendererContent` branches on the backing view&#39;s layout: `RecordBoardWidget` (wraps the standard `RecordBoardContainer`) and `RecordCalendarWidget` (mounts the existing `RecordCalendar`, which renders month / day / week) inside the same per-widget provider sandbox the table uses. **Read-only semantics.** Two flags with distinct scopes, each documented on its state: - `isRecordBoardViewSettingsReadOnlyComponentState` — locks the board chrome that edits view settings (add group, column reorder/resize/menu, aggregates); **card drag still updates records** under object permissions. - `isRecordCalendarReadOnlyComponentState` — widget calendars are read-only by default (no drag, no add-new, no in-calendar layout switch); cards open the side panel. The one exception, behind `IS_CALENDAR_WEEK_VIEW_ENABLED`: a **live (non edit-mode) day/week** widget calendar allows drag-to-reschedule and record creation under object permissions. Month calendars and edit-mode previews stay read-only. **Calendar state componentization.** The calendar module&#39;s three settings move from global atoms to component states keyed on `RecordCalendarComponentInstanceContext` (same pattern as record-board), so several calendar widgets and an index-page calendar can coexist without leaking state. All readers resolve the ambient instance; calendar unit tests updated. **Multi-instance fixes that also fix index pages:** record drag states were written against a different instance than every reader resolves (now use the ambient instance); the board sticky-header DOM id is namespaced per board; dragged board cards portal to `document.body` while dragging so react-grid-layout&#39;s transforms can&#39;t offset the clone from the pointer. ## Scope (v1) - Widget calendars are month-only and read-only by default. With `IS_CALENDAR_WEEK_VIEW_ENABLED` enabled, day/week layouts become selectable (UI + API) and live day/week widget calendars support drag-to-reschedule and record creation under object permissions. - Widget group-by offers SELECT fields only (server auto-generates groups from options; widgets have no per-record add-group flow). ## Tests - Integration: `upsert-view-widget-view-settings.integration-spec.ts` (9 tests — group auto-creation, invalid type/field rejections, non-month calendar widget rejected while the week/day flag is off and accepted once it&#39;s enabled, combined settings+fields call); pre-existing `upsert-view-widget` suite (20) green. - Front: new suites for draft view-group generation and snapshot clone/build utils; calendar suites componentized; full `twenty-front` jest, typecheck, oxlint green; `twenty-server` typecheck + lint green. - Browser-verified end-to-end (real dev server + seeded workspace): configure → live edit-mode preview → save → reload for all three layouts; measured drag with pointer inside the card; index-page calendar re-verified (with the week/day flag enabled). https://claude.ai/code/session_01E5N87kwwZWhDtEQaP72cMf	2026-07-21 15:41:08 +02:00
Weiko	25bd2897a3	Add weekly layout to record calendar (#22819) ... ## Summary - Add a week layout to record calendar views and persist the selected layout. - Render `DATE` calendars as an all-day week and `DATE_TIME` calendars as an hourly week. - Add an optional end date field across calendar configuration, metadata, persistence, and complete-view upserts. - Use configured end values for ranged and multi-day events, with a one-hour fallback when a `DATE_TIME` end is absent or invalid. - Keep calendar cards consistent with the existing compact view, including checkbox selection and whole-card record opening. - Gate the weekly layout and end-date behavior behind the public Labs `IS_CALENDAR_WEEK_VIEW_ENABLED` workspace feature flag. ## Week interactions - Show overlapping timed events side by side and cap the visible records at two per day. - Display start and end times on timed cards, enforce a readable 30-minute minimum height, and keep today’s text contrast stronger. - Drag timed events between days and times with 30-minute snapping while preserving their duration, including zero-duration events. - Show a create button when hovering a 30-minute slot; keyboard users can focus a day, move the slot with the arrow keys, and reach the same contextual action. - Initialize new records with the selected slot time and a compatible writable end value one hour later. - Show the workspace time zone and current-time indicator in timed weeks; date-only weeks keep the all-day section without an hourly grid. ## Configuration and data loading - Only allow end fields that match the start field type, and prevent selecting the same field for both boundaries. - Load records whose ranges overlap the visible period so month and week layouts display the same relevant records. - Resolve and persist calendar end fields when updating existing views through `upsert_complete_view`. - Fall back to Month and ignore the configured end field while the flag is disabled, without overwriting either persisted setting, so re-enabling restores the previous configuration. - Expose the flag in Labs and keep it default-off for workspaces without a stored value; enable it in the development seeder. <img width="1285" height="808" alt="Screenshot 2026-07-15 at 15 50 17" src="https://github.com/user-attachments/assets/b7e3f7f1-ca77-492f-8cce-cca186ebca0b" />	2026-07-15 16:30:18 +02:00
Thomas des Francs	e609320666	Squirclesssss 🟦🔵 (#22535)	2026-07-04 07:07:29 +02:00
souheyl gouadria	1b2f2c71c3	Move filter group destruction after filter operations (#22248) ... ### The current order is: 1. Create filter groups 2. Update filter groups 3. Destroy filter groups ← **happens here** 4. Clean up store (cascade) 5. Create/update/delete filters (which may reference groups just destroyed) The fix is to move filter group destruction after filter operations, so filters that reference those groups get created/updated/deleted first. ### after fix : The persistence order is now: 1. Create filter groups 2. Update filter groups 3. Create/update/delete view filters (these can safely reference groups that still exist) 4. Destroy filter groups (only after all filter mutations are done) 5. Clean up store (cascade-deleted filters **root cause :** step 4 happened before step 3, so filter creates/updates would reference groups that had already been deleted in the same save cycle ; causing the backend to fail with "Migration execution failed" when it couldn't resolve the `viewFilterGroupId `foreign key. this fixes the bug : #21351 <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22248?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: Souheyl Gouadria <souheyl.gouadria@medius.com> Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-29 16:54:15 +02:00
Abdul Rahman	db5338cf32	Feat: group records by many to one relation (#22123) ... ## Group records by relation (Kanban + Table) Adds grouping by `MANY_TO_ONE` relation fields on both board and table views, reusing the existing `ViewGroup` storage (`fieldValue = related record id`). - **New group** record picker to create relation-backed groups (board column + table row) - Relation-aware group headers (name/avatar), filtering, and drag-drop (writes the FK join column) — all using one canonical `${name}Id` column - Sort menu hides alphabetical options when grouping by a relation (no comparable title) - A group whose backing record no longer exists renders a "Deleted" chip instead of a blank header - **Backend:** allow `MANY_TO_ONE` relations as the Kanban `mainGroupByField` in the flat-view validator https://github.com/user-attachments/assets/267077a6-2667-4506-b178-eee420a16f20 <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22123?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-25 13:55:50 +02:00
Priyanshu Bartwal	4c966bfc32	[Twenty-front]: Bunch of View Picker Fixes and improvements. (#21290) ... While working on #21208, I found a few related improvements and fixes that were worth including in this PR. 1. Improved View Picker UX: - Added optimistic updates when selecting a view from both the drag-and-drop view picker - Added optimistic updates when editing view. Before it used to close the whole dropdown. - Added highlighting for the currently selected view. - Before: https://github.com/user-attachments/assets/469fc60c-e65f-4452-a5a4-7df6188ab19d - After: https://github.com/user-attachments/assets/d3b151c1-0c10-45e7-a796-b5e6061c898d 2. Remove Favorites from the View Picker - Added support for removing a favorite directly from the view picker without needing to open additional menus. - Before: https://github.com/user-attachments/assets/70437fb9-d4c1-488b-aab9-0ea92d1bad99 - After: https://github.com/user-attachments/assets/442546bd-24ae-43d5-abe1-268ef3ff6475 --------- Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-22 10:56:34 +02:00
Félix Malfait	b8ea742a88	fix(front): respect user number format for counts and aggregates (#21894) ... ## Problem Several user-facing numbers were rendered raw (e.g. `153909`) instead of honoring the workspace member's **Number format** preference (e.g. `153 909` with `Spaces and comma`). The formatting utilities already existed (`formatNumber` / `useNumberFormat`) but were not applied on these surfaces. ## Root cause `transformAggregateRawValueIntoAggregateDisplayValue` — the shared helper behind every table/board/chart aggregate — returned the `COUNT` branch as a raw string and never threaded the user's locale format into `formatNumber` for the other branches (so they silently fell back to `COMMAS_AND_DOT`). Its existing `numberFormat` param actually held the chart `SHORT`/`FULL` abbreviation setting, so it is renamed to `chartNumberFormat`, and a new `numberFormat: NumberFormat` now carries the locale separators. ## Surfaces fixed - Record table footer aggregates, including the raw **"Count all"** total - Record board column / group-section aggregates - Aggregate chart and pie-chart center metric (including their raw `COUNT` early-returns) - View picker `<view> · <count>` total - Record show breadcrumb pagination `(x/y)` - Record index header and side panel `N selected` counts The board-column header needs no change — it now receives an already-formatted string from the transform. ## Out of scope (intentionally left raw) The editable `SettingsCounter` input (formatting would break parsing), the advanced-filter pill, the `+N` overflow badge, and the AI routing debug display. ## Testing - New + existing unit tests pass (`transformAggregateRawValueIntoAggregateDisplayValue`, `formatNumber`, `useNumberFormat`), with added locale-aware coverage (`SPACES_AND_COMMA` → `153 909`, `DOTS_AND_COMMA` → `153.909`). - `nx typecheck twenty-front`, oxlint and oxfmt on the diff all pass. > Note: two i18n strings change placeholder shape (`{count} selected` → `{0} selected`); a `lingui:extract` will refresh the catalogs (runtime falls back to source text meanwhile). https://claude.ai/code/session_013XNL2Xa11Bw7fsnPFQgsGX --- _Generated by [Claude Code](https://claude.ai/code/session_013XNL2Xa11Bw7fsnPFQgsGX)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21894?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-20 14:28:12 +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
Abdul Rahman	0758a4fcef	reset filter search input on field select (#21850) ... ### Before https://github.com/user-attachments/assets/3e5d2193-c638-4898-a11b-a9a1b9607206 ### After https://github.com/user-attachments/assets/99eab3e2-8475-46dd-915b-0324ada53e5a <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21850?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-19 18:56:00 +05:30
Thomas des Francs	de9af38a67	Fix view type label casing (#21772) ... ## Summary Fix the view type label shown in the object Options menu by introducing a shared `ViewType` label map instead of formatting raw enum values at each call site. I chose to fix the root cause instead of only patching the symptom: the menu was displaying the generated enum value `TABLE`, and `capitalize()` only uppercased the first character without lowercasing the rest. The new mapping gives each view type an explicit translated UI label, so the parent Options menu, the Layout submenu, the view picker, and application content rows all use the same casing source. ## Before / After | Before | After | | --- | --- | | The Options menu showed `TABLE` in uppercase. | The Options menu now shows `Table`, and the Layout submenu still shows `Table`, `Calendar`, and `Kanban`. | |  |  | ## Tests - `git diff --check` - Browser smoke test on `http://apple.localhost:3001/objects/companies` - default view Options menu still opens - custom view Options menu shows `Layout` contextual text as `Table`, not `TABLE` - Layout submenu still shows `Table`, `Calendar`, and `Kanban` - no browser console errors Not run: package lint/test commands, because this checkout has no `node_modules` installed.	2026-06-18 23:37:28 +00:00
nitin	9bc0db5666	fix: exclude non-groupBy date fields (deletedAt) from calendar field selection (#21764) ... Closes #21608 The Tasks Calendar renders an empty grid because `GroupByTasks` fails with `Field "deletedAt" is not supported in groupBy` while the header count (`AggregateTasks`) still succeeds. The calendar renders by grouping records on the selected date field. Calendar-field eligibility only checked `isFieldMetadataDateKind`, so `deletedAt` (a system DATE_TIME field) could be picked or auto-defaulted as the calendar field — and the groupBy engine correctly rejects it (only `createdAt`/`updatedAt` are groupable system date fields). Fix: gate calendar-field eligibility on `isFieldMetadataSupportedInGroupBy` (the same authority the backend groupBy validator uses), so non-groupable date fields can no longer be selected. - `useGetAvailableFieldsForCalendar` — add the groupBy-support check alongside the date-kind filter - `ObjectOptionsDropdownCalendarFieldsContent` — reuse the hook's list instead of re-filtering raw fields	2026-06-18 12:48:08 +00:00
Raphaël Bosi	8034c7725f	Reorganize twenty-ui into best-practice component domains and per-component folders (#21745) ... Reorganizes `twenty-ui`'s component organization to follow how the best UI libraries (MUI, Mantine, Base UI, Polaris) structure their source, now that the package has stabilized. **Taxonomy** — dissolves the meaningless `components/` junk-drawer and the 107-file `display/` mega-category. New domains/subpaths: `data-display`, `typography`, `icon`, `surfaces`; `feedback` and `layout` absorb the rest (banners/callout/info + placeholders → feedback; modal/card → surfaces; motion + separators → layout). **Per-component layout** — every component is now `<domain>/<ComponentName>/<ComponentName>.tsx` with colocated styles/stories/types, `internal/` for private helpers and `parts/` for re-exported compound sub-parts. The redundant inner `/components/` is gone. `icon` and `json-visualizer` are kept as cohesive subsystems. **Also:** adds a tree-shakeable root barrel (`import { Button } from 'twenty-ui'`), the generator now owns `individual-entry.ts`, and a real barrel-leak bug is fixed (private `internals/` parts were leaking into the public API). Consumer imports (~1.2k files) and the `twenty-sdk` UI aggregator were updated by codemod. The change is **export-neutral** except 16 intentionally-removed private internals symbols (all verified unconsumed). Gates green: typecheck, lint, build, size-limit, storybook. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21745?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-18 10:31:29 +02:00
Raphaël Bosi	9c9c34fccf	Remove twenty-ui-deprecated and migrate frontend to twenty-ui (#21596) ... Migrates `twenty-front`, `twenty-sdk`, and `twenty-front-component-renderer` from `twenty-ui-deprecated` to `twenty-ui` (mechanical import swap — the packages have API parity) and deletes the deprecated package along with its workspace/CI/config wiring. Also adds `@linaria/react`/`@linaria/core` as direct deps of `twenty-front` (it used them transitively via the deprecated package). Note: move the required status check from `ci-ui-status-check` to `ci-new-ui-status-check`. Argos: the Storybook box-model/button-reset baseline shift (the bulk of the visual diffs) is isolated in #21665 — Storybook now loads twenty-ui's global `reset.scss`, which the production app already ships. Once #21665 merges and this branch is rebased, the remaining Argos diffs are component-level visual-parity items only.	2026-06-17 09:41:11 +00:00
Charles Bochet	14d8105f22	fix(front): remove runtime default-view creation fallback (#21652) ... ## Problem `useCreateDefaultViewForObject` was a temporary runtime fallback that created a view + one view field per field (each with a fresh `v4()` id) whenever `RecordIndexLoadBaseOnContextStoreEffect` found no view for the current view id. Because the created view got a fresh id that never matched the requested `contextStoreCurrentViewId`, the next load missed again and re-created another duplicate — leaking `core.view` / `core.viewField` rows without bound (notably during the 2.13.0 cache-first bootstrap window). #21592 made the fallback idempotent as a stop-gap, but the mechanism is no longer needed at all: standard/index views are created server-side at object creation and during standard app installation, so the client never needs to mint them. ## Change Remove the fallback entirely: - Delete `useCreateDefaultViewForObject`. - In `RecordIndexLoadBaseOnContextStoreEffect`, when no view resolves for the current id, do nothing and let the loaded views settle (the effect re-runs once the view is present and loads it). ## Note This removes the leak at the source for any client running the new bundle. Clients still on old cached JS will keep creating duplicates until they reload; the already-leaked rows are being cleaned up separately via SQL. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21652?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-16 11:08:48 +02:00
Félix Malfait	87c878b101	fix(twenty-front): stop unbounded default-view creation on record-index load (#21592) ... ## Problem Since the 2.13.0 deploy, `core.viewField` and `core.view` rows are being created without bound. From Sentry (`twenty-server`, prod), comparing equal 24h windows before/after the deploy: | INSERT (per day) | Before (Jun 11→12) | After (Jun 14→15) | |---|---|---| | `core.viewField` | 1,885 | 193,719 (**103×**) | | `core.view` | 161 | 12,130 (**75×**) | All under `POST /metadata`, via the `CreateManyViewFields` operation (with frequent "Could not find view for given viewId" races). The accumulating rows then feed a quadratic flat-map rebuild, ramping `POST /metadata` tail latency (p99 0.67s → 7s → 11s and climbing) and server CPU. ## Root cause `useCreateDefaultViewForObject` is a temporary fallback that creates a view + a view field per field, each with a fresh `v4()` id. [`RecordIndexLoadBaseOnContextStoreEffect`](https://github.com/twentyhq/twenty/blob/main/packages/twenty-front/src/modules/object-record/record-index/components/RecordIndexLoadBaseOnContextStoreEffect.tsx) calls it whenever the current view id has no match in the loaded views: ```ts if (isDefined(view)) { loadRecordIndexStates(...) } else { createDefaultViewForObject(objectMetadataItem); } // fires when the lookup misses ``` This is **non-convergent**: the created view gets a *fresh* id, never equal to the requested `contextStoreCurrentViewId`, so the next load misses again and creates another duplicate — every record-index load mints a view + ~17 view fields forever. **Why it started at 2.13.0:** the lookup now misses during normal loads because of the cache-first bootstrap experiment (#21532, which is the `v2.13.0` tag commit). It opens the app gate from cache before the network revalidation, so the record-index effect runs while `contextStoreCurrentViewId` is set but the views aren't settled — the exact window that trips the fallback. ## Fix Make the fallback idempotent: never auto-create a default view for an object that already has one. During the cache-first load window the object's views are present (just not the specifically-requested id), so the guard short-circuits; and once any view exists, it can never re-create. The legitimate case (an object genuinely without views) still creates exactly one. ## Scope / follow-ups - This is the **root-cause** fix for the leak. - The quadratic amplification is mitigated separately by the O(N²)→O(N) change in the flat-map builder (#21585). - The cache-first experiment (#21532) should be reviewed — it's marked "[Experiment] — not for merge as-is" yet shipped; reverting/gating it is the fastest standalone stop-gap, and confirms the trigger if `viewField` inserts drop. - The already-leaked duplicate `core.view` / `core.viewField` rows need a cleanup pass. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21592?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-15 16:01:11 +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
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
Raphaël Bosi	c596a5e342	Rename twenty-ui to twenty-ui-deprecated and twenty-new-ui to twenty-ui to prepare package release (#21315) ... ## Description Promotes the next-gen UI library (formerly `twenty-new-ui`) to the name **`twenty-ui`** (v0.1.0, publishable) and renames the old package to **`twenty-ui-deprecated`**. Rewrites ~1,730 `twenty-ui` imports → `twenty-ui-deprecated`, updates all configs/CI/Docker/deps, and migrates twenty-front's `Toggle` to the new package (first consumer) as a drop-in. ## Next steps - Wire the `ui/v*` publish dispatch (`cd-deploy-tag.yaml` + `.yarnrc.yml`), then tag `ui/v0.1.0` to publish. - Continue migrating components from `twenty-ui-deprecated` → `twenty-ui`.	2026-06-08 18:12:28 +02:00
Parship Chowdhury	e04eef0461	fix: wrong record count on deleted and normal records (#21292) ... ## Summary - Resolves #11977 - When looking into the deleted records from People tab (or any object list), the record detail header showing 0/(total records) instead of the correct position among deleted records only, e.g. 1/3 or 3/7. So, this PR makes the count match what users see in the deleted-records list. - Also normal records showing `0/N` in the header when opened from a list view (e.g. `0/48` -> `2/48`). ## Approach I tried to keep the change small and avoid extra server requests: - when a user came from a deleted-records view, we tell our existing queries to include soft-deleted records. - for the position number, we use the record list the user already had open (from the index view they came from) instead of apollo cache, which didn’t include records, especially deleted ones, but also normal records. - normal list behavior is not changed on the server side. ## Test plan - Open people/company, delete a record - Use the side menu -> “see deleted records” - open a deleted record’s details - confirm the header showing the correct position and total (e.g. 1/2, not 0/100) - for normal list: open People (normal list, not deleted) -> click a record -> open full page -> confirm header shows correct position and total (e.g. `2/48`, not `0/48`) ## Screenshots ### Before: <img width="1513" height="309" alt="Screenshot 2026-06-07 135204" src="https://github.com/user-attachments/assets/4754f1a7-8315-4a7a-815f-dda977b09331" /> <img width="1514" height="261" alt="Screenshot 2026-06-07 141735" src="https://github.com/user-attachments/assets/dd5b1834-5d84-49fe-8d20-633428d73502" /> ### After: <img width="1511" height="224" alt="Screenshot 2026-06-07 134946" src="https://github.com/user-attachments/assets/9450af7d-84b9-40bb-95e9-5a8665cc0923" /> <img width="1514" height="288" alt="Screenshot 2026-06-07 135045" src="https://github.com/user-attachments/assets/029ae632-ad7e-451e-8170-a4e4e71ac6f9" /> <img width="1512" height="229" alt="Screenshot 2026-06-07 141642" src="https://github.com/user-attachments/assets/576f4cad-a9e9-4380-aa67-e5f0e976a193" /> --------- Signed-off-by: Parship Chowdhury <parshipchowdhury@gmail.com> Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-08 16:44:03 +02:00
Mani bharadwaj	79c9c75776	fix: use correct userWorkspaceId for navigation menu comparisons (#21299) ... ## What does this PR do? Fixes a bug where `NavigationMenuItem.userWorkspaceId` was being compared/set to `WorkspaceMember.id` instead of the correct `UserWorkspace.id`, causing the favorites functionality to not work correctly. Fixes #21291 ## Problem The `isFavorite` check in `ViewPickerOptionDropdown` and `createManyNavigationMenuItems` calls in multiple files were using `currentWorkspaceMemberId` (which is `WorkspaceMember.id` from the `workspace_*` schema) instead of the correct `UserWorkspace.id` (from the `core` schema). This caused: - `isFavorite` to always return `false` for user favorites - Navigation menu items to be created with incorrect `userWorkspaceId` ## Root Cause In `useNavigationMenuItemsData.ts`: - `currentWorkspaceMemberId` was derived from `currentWorkspaceMember?.id` (WorkspaceMember.id) - But `NavigationMenuItem.userWorkspaceId` expects a `UserWorkspace.id` - These are two different entities from different schemas (core vs workspace) ## Solution 1. Added `currentUserWorkspaceId` to the `useNavigationMenuItemsData` hook return type 2. `currentUserWorkspaceId` is derived from `currentWorkspaceMember?.userWorkspaceId` 3. Updated all comparisons and assignments to use `currentUserWorkspaceId` when dealing with `userWorkspaceId` ## Files Changed - `packages/twenty-front/src/modules/navigation-menu-item/display/hooks/useNavigationMenuItemsData.ts` - Added `currentUserWorkspaceId` to return type - `packages/twenty-front/src/modules/views/view-picker/components/ViewPickerOptionDropdown.tsx` - Fixed `isFavorite` check and `createManyNavigationMenuItems` call - `packages/twenty-front/src/modules/command-menu-item/engine-command/record/single-record/components/AddToFavoritesSingleRecordCommand.tsx` - Fixed `createManyNavigationMenuItems` call - `packages/twenty-front/src/modules/navigation-menu-item/edit/hooks/useNavigationMenuItemEditController.ts` - Fixed `targetUserWorkspaceId` assignment ## Testing - No existing tests directly cover the `useNavigationMenuItemsData` hook - The fix is a simple type/field correction that should not affect other components - CI will verify TypeScript compilation and linting ## Checklist - [x] I have read the [CONTRIBUTING.md](https://github.com/twentyhq/twenty/blob/main/.github/CONTRIBUTING.md) file - [x] Changes are tested locally (TypeScript compilation) - [x] Commit message follows repository conventions - [x] PR is linked to the relevant issue (#21291) --------- Co-authored-by: Mani bharadwaj <Manibharadwaj@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>	2026-06-08 09:17:07 +00:00
Charles Bochet	1a9f786e42	refactor(filters): pass fieldMetadataItems array to dispatcher (#20737) ... ## Summary Alternative to #20717. Same goal (clean up the filter dispatcher API after #20670) but smaller and follows the codebase's "pass data, not behavior" style. The dispatcher takes a `fieldMetadataItems: FieldShared[]` array directly instead of a `findFieldMetadataItemById: (id) => FieldShared | undefined` callback. The util builds the id lookup internally — once per call, used for both source-field and relation-target-field lookups. No new types, no separate hydration step. ## What changes **`twenty-shared`** - `computeRecordGqlOperationFilter` / `turnRecordFilterIntoRecordGqlOperationFilter` / `turnRecordFilterGroupsIntoGqlOperationFilter`: replace `findFieldMetadataItemById` param with `fieldMetadataItems` / `fieldMetadataItemById` (internal Map). - Remove the exported `FindFieldMetadataItemById` type. - `turnAnyFieldFilterIntoRecordGqlFilter`: rename its internal `fieldById` Map for consistency. - Tests updated to pass arrays. **Frontend (15 call sites)** - Switch from `fieldMetadataItemByIdMapSelector` to `flattenedFieldMetadataItemsSelector`. - Pass `fieldMetadataItems: flattenedFieldMetadataItems` to the dispatcher. - `useFindManyRecordsSelectedInContextStore` keeps the Map selector because it still does a per-filter lookup for the soft-delete check. **Server (5 call sites)** - Pass `Object.values(flatFieldMetadataMaps.byUniversalIdentifier).filter(isDefined)`. ## Why this over #20717 #20717 moves resolution into a separate hydration step + introduces a `HydratedRecordFilter` type. The bug that #20717 originally surfaced was Sentry catching 4 critical runtime errors during review (`fieldMetadataItemByIdMap` declared but not passed). The added type and the explicit hydration boundary are extra surface area for not much benefit — the existing API was a callback wrapping a Map at every call site, and the natural simplification is to just pass the Map (or its array) directly. Net diff: **196 insertions, 203 deletions** (~7 lines net removed). 32 files. ## Test plan - [x] Shared filter unit tests pass (461 tests) - [x] Frontend filter/context-store tests pass (13 tests) - [x] Frontend typecheck passes - [x] Server typecheck passes - [x] Lint passes (frontend + server) - [ ] Integration tests on #20670 still pass — workflow find-records + chart-data with relation-traversal filter still work end-to-end through the new array param	2026-05-19 22:49:53 +02:00
Félix Malfait	291ce5ccdb	fix(filters): make filter dispatcher own relation-target resolution (#20670) ... ## Summary Two relation-traversal bugs surfaced post-merge of #20533, both rooted in the same architectural smell: the GraphQL filter dispatcher took a flat `fields: FieldShared[]` array and silently dropped any filter whose `relationTargetFieldMetadataId` wasn't in that array. Callers had to remember to pre-augment the list with relation targets — and 16+ call sites did not all know this. This PR fixes both bugs and removes the smell. ### Bug 1 — Save as new view loses the relation target `useCreateViewFromCurrentView` built the create-filter input without `relationTargetFieldMetadataId`. The saved view's filter persisted without the traversal — on reload the chip showed "Company contains 'air'" instead of "Company → Name contains 'air'". Discarded at save time, not at read time. Fix: include `relationTargetFieldMetadataId` in the create input. (Commit 1.) ### Bug 2 — Workflow Search Records drops one-hop traversals `FindRecordsWorkflowAction` built its fields list from `flatObjectMetadata.fieldIds` only (source object's fields). The shared dispatcher then couldn't resolve the relation target field on the related object and silently dropped the filter — a configured "People where Company → Name Contains 'Airbnb'" came through as `{ and: [] }`. This was the same shape as bugs already fixed in 5 other call sites (chart filters, view filters, record table, etc.). The pattern was: caller forgets to augment fields → dispatcher silently drops the filter. Fix (commit 2): change the dispatcher to take a `findFieldMetadataItemById: (id) => FieldShared | undefined` resolver callback. Both source-field and relation-target-field lookups go through the same resolver, so callers no longer need to know about the augmentation requirement. Frontend callers pass a workspace-wide resolver built from `flattenedFieldMetadataItemsSelector`; server callers wrap `findFlatEntityByIdInFlatEntityMaps` on `flatFieldMetadataMaps`. In both cases relation-target lookups just work, because the resolver can see fields on related objects. ## Why this matters Before: "if you call the dispatcher, pre-augment your fields list with relation targets, or filters get silently dropped." An invariant only enforceable by code review, broken often enough to ship two user-visible bugs in one week. After: the dispatcher resolves field ids itself. There's no list to forget to augment. The failure mode (filter silently dropped) becomes structurally impossible at the dispatcher boundary. Net diff: 240 insertions, 319 deletions. Removed `augmentFieldsWithRelationTargets` (frontend) and the workflow whack-a-mole code (server). ## Test plan - [ ] Save view: create an advanced filter using a one-hop relation traversal, click "Save as new view", reload, confirm the chip still reads "Source → Target operator value" - [ ] Workflow: configure a Search Records action with a relation-traversal filter, run the workflow, confirm the filter is actually applied - [ ] Dashboard chart: configure a chart with a relation-traversal filter, confirm the chart data respects it - [ ] Record table, group-by, calendar, total count, footer aggregates: all continue to work with both plain and relation-traversal filters	2026-05-19 11:55:22 +02:00
Félix Malfait	c938fbf4d6	feat(twenty-front): relation traversal in filter dropdown (stacked) (#20533) ... **Stacked on #20527** https://github.com/user-attachments/assets/48995655-401a-4c35-8094-e88da8408bdd ## Summary Surfaces the one-hop relation traversal added in #20527 through the existing **composite sub-field dropdown pattern**. Clicking a MANY_TO_ONE relation field in the "+ Filter" picker now opens the same second-level dropdown that composite fields (FULL_NAME, ADDRESS, CURRENCY, etc.) already use — populated with the target object's filterable fields. Picking one (e.g. `Company → Name`) builds a filter that serializes to the nested GraphQL filter the backend now accepts: `{ company: { name: { ilike: "%X%" } } }`. No new components. The whole feature reuses `AdvancedFilterSubFieldSelectMenu` + the existing `subFieldNameUsedInDropdownComponentState` + the existing `MenuItem hasSubMenu` indicator. Only the conditions that gate the sub-menu (and the sub-menu's content for relations) were broadened. ## What landed | File | Change | |---|---| | `ObjectFilterDropdownFilterSelectMenuItem` | Sub-menu chevron now shows on MANY_TO_ONE relations (`isManyToOneRelationField` util). | | `AdvancedFilterFieldSelectMenu` | Relation clicks open the sub-menu alongside composite clicks. | | `AdvancedFilterSubFieldSelectMenu` | New branch: when the sub-menu type is `'RELATION'`, render the target object's filterable fields via `useFilterableFieldMetadataItems(targetObjectMetadataId)`. Composite logic untouched. | | `objectFilterDropdownSubMenuFieldType` state | Widened to accept a `'RELATION'` sentinel. Role-permissions sub-field menu narrows it back out (it doesn't traverse relations). | | `useSelectFieldUsedInAdvancedFilterDropdown` | New optional `targetFieldMetadataItem` arg. When present, the stored RecordFilter's `type` is the target field's type so the operand picker and value input render the target's operands (`'TEXT'` operators when filtering `company.name`, etc.). | | `turnRecordFilterIntoGqlOperationFilter` (shared) | When the filter targets a `RELATION` field with a `subFieldName`, synthesize a field-metadata for the target, recurse to build the inner filter, then wrap it under the relation field's name → `{ relationName: { targetFieldName: { ...operator } } }`. | `RecordFilter.subFieldName` stays narrowly typed as `CompositeFieldSubFieldName` so the wide downstream consumers (`shouldShowFilterTextInput`, composite handlers in the serializer, etc.) don't change. The relation target field's name is stored through a narrowly-scoped cast at the dropdown's storage point — the serializer checks `filter.type === 'RELATION'` before interpreting it as a target field name, so the cast can't be mis-read by composite-only code paths. ## Test plan - [ ] Open a table view on People, click "+ Filter", click "Company" → sub-menu opens with Company's filterable fields - [ ] Pick "Name" → operand picker shows TEXT operators (Contains, Equals, …) - [ ] Type "Airbnb" → filter applies, table shows people whose company name contains "Airbnb" - [ ] Verify network tab: the GraphQL filter variable is `{ company: { name: { ilike: "%Airbnb%" } } }` - [ ] Same flow with a composite target field (e.g. `Company → annualRecurringRevenue → amountMicros`) — should work end-to-end (backend supports composite-within-relation; #20527 has an integration test covering this) - [ ] Composite fields (FULL_NAME, ADDRESS) still open their normal sub-menu and filter correctly — no regression - [ ] Role-permissions field-select sub-field menu is unaffected (it bails out early on the RELATION sentinel) ## Out of scope - ONE_TO_MANY traversal (no backend support yet) - Aggregates (`people.count > 5`) - Persisting relation-traversal filters into a saved view (ViewFilter has no `relationPath` column yet; that's a separate slice) - REST API DSL changes - AI Tools 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-15 16:42:47 +02:00
Félix Malfait	e16977f97b	[breaking: deploy server before front] feat(view-sort): pick sort sub-field inline on the chip (#20445) ... ## Summary Lets users choose which sub-field of a composite column to sort by — directly from the sort chip — by clicking the sub-field label and picking from a dropdown. Persists per view via a new nullable \`subFieldName\` column on \`ViewSort\`. Replaces #20438, which proposed a field-settings (admin) configuration for the same problem. The chip-level approach is more discoverable (the option lives where the user is looking) and per-view, so different views on the same object can sort by different sub-fields. ### What changes for users - **FullName columns**: previously sorted by \`firstName\` and \`lastName\` together as a stable dual-key sort. Now the user can pick which sub-field is primary (the other is the tie-breaker). Default remains \`firstName\` primary, \`lastName\` tie-breaker. - **Address columns**: previously not sortable at all (not in \`SORTABLE_FIELD_METADATA_TYPES\`). Now sortable, with a chip dropdown listing each enabled sub-field. Default is \`addressCity\` if enabled, else the first enabled sub-field. Disabling a sub-field at the field-metadata level (existing setting) removes it from the dropdown. - **Other composite types** (Currency, Phones, Emails, Links, Actor) and scalar fields keep their existing single-key sort behavior. ### UX ``` ┌─────────────────────────┐ ┌─────────────────────────┐ │ ↑ Name · Last name ✕ │ │ ↑ Address · City ✕ │ └────────┬────────────────┘ └────────┬────────────────┘ ▼ (click sub-field) ▼ ┌────────────┐ ┌────────────┐ │ First name │ │ Address 1 │ │ Last name ✓│ │ Address 2 │ └────────────┘ │ City ✓│ │ State │ │ Postcode │ │ Country │ └────────────┘ ``` The chip body still toggles direction on click — the \`Dropdown\`'s internal wrapper calls \`stopPropagation\` so the sub-field click doesn't bubble to the chip's onClick. ## What changed **Backend:** - \`ViewSortEntity\` — new nullable \`subFieldName: varchar\` column - \`ViewSortDTO\`, \`CreateViewSortInput\`, \`UpdateViewSortInputUpdates\` — new \`@Field(() => String, { nullable: true })\` - \`FLAT_VIEW_SORT_EDITABLE_PROPERTIES\` — \`'subFieldName'\` added so the property flows through the update merge path - \`ALL_ENTITY_PROPERTIES_CONFIGURATION_BY_METADATA_NAME.viewSort\` — new \`subFieldName\` entry with \`toCompare: true\` so cache diffs notice it - \`fromCreateViewSortInputToFlatViewSortToCreate\` — threads \`subFieldName\` through - Instance command migration (\`add-sub-field-name-to-view-sort\`) — single \`ALTER TABLE core.viewSort ADD subFieldName varchar\` / \`DROP\` **Frontend:** - \`RecordSort\` and \`ViewSort\` types — \`subFieldName?: string | null\` - \`VIEW_SORT_FRAGMENT\` — adds \`subFieldName\` so the field round-trips - \`mapRecordSortToViewSort\` + \`areViewSortsEqual\` — carry the new field through, include it in the diff so the usual \`useSaveRecordSortsToViewSorts\` create/update flow fires when it changes - \`useSaveRecordSortsToViewSorts\` — passes \`subFieldName\` in both \`CreateViewSortInput\` and \`UpdateViewSortInputUpdates\` - \`getOrderByForFieldMetadataType(field, direction, subFieldName?)\` — new optional third arg. \`turnSortsIntoOrderBy\` threads \`sort.subFieldName\` into it. - \`Address\` added to \`SORTABLE_FIELD_METADATA_TYPES\` - New helpers: \`getEnabledAddressSubFields\` (filters by the field's \`subFields\` setting, falls back to the 6 default visible address sub-fields), \`getDefaultSortSubFieldForAddress\`, \`getDefaultSortSubFieldForFullName\` - New shared types/constants: \`AllowedFullNameSubField\`, \`ALLOWED_FULL_NAME_SUBFIELDS\`, \`DEFAULT_VISIBLE_ADDRESS_SUBFIELDS\` - \`SortOrFilterChip\` — new \`labelSubField?: ReactNode\` slot; renders as \` · {sub-field}\` with subdued weight after the main label - \`EditableSortChip\` — builds options from field metadata (\`ALLOWED_FULL_NAME_SUBFIELDS\` for FullName, \`getEnabledAddressSubFields\` for Address), uses i18n-wrapped labels, persists picks via \`upsertRecordSort\` ## Test plan - [x] \`npx nx typecheck\` passes for twenty-shared, twenty-front, twenty-server - [x] \`oxlint --type-aware\` on all 19 frontend + 9 server changed files: 0 errors - [x] \`prettier --check\`: clean - [x] 16 unit tests pass — \`getOrderByForFieldMetadataType\` covers the new \`subFieldName\` override branch for FULL_NAME and ADDRESS; \`getDefaultSortSubFieldForAddress\` covers the city/first-enabled fallback path; \`getDefaultSortSubFieldForFullName\` exercises its constant - [ ] Manual: sort a People view by Full Name → click the chip's sub-field label → switch between First name and Last name → reload page → choice is preserved - [ ] Manual: sort a Company view by Address → confirm dropdown lists only enabled sub-fields → disable Address \`addressCity\` in field settings → confirm dropdown options update and runtime falls back to the first enabled sub-field 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com> Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>	2026-05-13 21:25:15 +02:00
Cheng Yin	97ec720d2c	fix: show active advanced filter count badge in dropdown button (#20229) ... ## Summary Replaces the hardcoded `0` in `ViewBarFilterDropdownAdvancedFilterButton` with the actual count of active advanced filter rules, matching the behavior of `AdvancedFilterChip` in the view bar. ## What changed In `packages/twenty-front/src/modules/views/components/ViewBarFilterDropdownAdvancedFilterButton.tsx`: - Imported `useAtomComponentSelectorValue` and `rootLevelRecordFilterGroupComponentSelector` - Imported `useChildRecordFiltersAndRecordFilterGroups` - Replaced `const advancedFilterQuerySubFilterCount = 0; // TODO` with the real computed count via the same hook pattern used in `AdvancedFilterChip.tsx` The pill badge will now appear on the "Advanced filter" dropdown menu item showing the number of active advanced filter rules (e.g. "2" when two rules are active). ## References - Fixes #20207 --------- Co-authored-by: wadeKeith <wade@twenty.app> Co-authored-by: Charles Bochet <charles@twenty.com> Co-authored-by: Cursor <cursoragent@cursor.com>	2026-05-04 15:08:30 +00:00
Abdul Rahman	fcba0ca30a	Add search to add column dropdown (#19763) ... https://github.com/user-attachments/assets/4a64fff0-6495-4651-934b-43f4ad0dc966	2026-04-17 07:19:07 +00:00
Abdul Rahman	270069c3e3	Add search to Fields dropdown (#19750) ... Issue link: https://discord.com/channels/1130383047699738754/1489198502998315100 https://github.com/user-attachments/assets/7d0a859e-c33e-4f9e-bdb3-5867fc0dd80f	2026-04-16 12:59:01 +00:00
Etienne	94b8e34362	Object view widget - Introduce new TABLE_WIDGET view type (#19545) ... closes https://discord.com/channels/1130383047699738754/1491549365263667230/1491804729397743666	2026-04-15 13:30:37 +00:00
Weiko	47bdcb11d8	Move is active to fe (#19649) ... ## Context Moving isActive filtering to the frontend for page layout tabs and widgets, hiding inactive entities from the UI while keeping them in state for future reactivation Next we will implement deactivated standard tab re-activation during tab creation (cc @Devessier) <img width="234" height="303" alt="📋 Menu (Slots)" src="https://github.com/user-attachments/assets/17a25ac6-55e2-4778-b7f0-e7554ed69704" />	2026-04-14 10:18:09 +00:00
Etienne	9c07ecd363	Fix view filter/sort deletion (#19567) ... fixes https://github.com/twentyhq/twenty/issues/19543 + bonus bug : when deleting an advanced filter, it triggers a destroy which cascade-deletes associated view filters. Then, view filters deletion throws.	2026-04-14 09:43:52 +00:00
martmull	bf5cc68f25	Rename standard and custom apps (#19631) ... as title no migration for existing apps, changes only apply on new workspaces	2026-04-13 13:13:59 +00:00
Weiko	238018dc7b	Reset Tab Page Layout (#19453) ... ## Context - Add "Reset to default" for page layout tabs and widgets — backend mutation resets overrides, reactivates deactivated children, and deletes custom children - Fix override write bug where mutating an overridable property (e.g. widget title) on a standard-app entity incorrectly overwrote the base column instead of writing to the overrides JSONB — PageLayoutUpdateService now uses resolveFlatEntityOverridableProperties for accurate diffing and routes properties through sanitizeOverridableEntityInput - Deprecate isOverridden - We need more time to think about this feature. Currently this adds too much complexity for a very small benefit https://github.com/user-attachments/assets/a84546c8-1e15-4d9e-a489-0825cf8b8ed2	2026-04-08 18:43:57 +02:00
Etienne	d2cf05f4f4	Fix - Not shared message on record index (#19103) ... quality-feedbacks : https://discord.com/channels/1130383047699738754/1486711185436053514/1486711185436053514 <img width="1000" height="500" alt="Screenshot 2026-03-30 at 09 42 48" src="https://github.com/user-attachments/assets/fe9027fe-0056-4fec-af51-5b39bb467bb5" /> <img width="1000" height="500" alt="Screenshot 2026-03-30 at 09 42 34" src="https://github.com/user-attachments/assets/8cd05ea0-7eb2-4490-b87e-3a7dcd57add2" /> --------- Co-authored-by: Weiko <corentin@twenty.com>	2026-03-30 13:53:35 +00:00
Rayan Salhab	6f0ac88e20	fix: batch viewGroup mutations sequentially to prevent race conditions (#19027) ... ## Bug Description When reordering stages in the Kanban board, the frontend fires all viewGroup update mutations concurrently via Promise.all, causing race conditions in the workspace migration runner's cache invalidation, database contention, and a thundering herd effect that stalls the server. ## Changes Changed `usePerformViewGroupAPIPersist` to execute viewGroup update mutations sequentially instead of concurrently. The `Promise.all` pattern fired all N mutations simultaneously, each triggering a full workspace migration runner pipeline (transaction + cache invalidation). The sequential `for...of` loop ensures each mutation completes (including its cache invalidation) before the next begins, eliminating the race condition. ## Related Issue Fixes #18865 ## Testing This fix addresses the root cause identified in the Sonarly analysis on the issue. The concurrent mutation pattern was causing: - PostgreSQL row-level lock contention on viewGroup rows - Cache thundering herd from repeated invalidation/recomputation cycles - Server stalls requiring container restarts The sequential approach ensures proper ordering and prevents these race conditions. --------- Co-authored-by: Rayan <rayan@example.com> Co-authored-by: Charles Bochet <charles@twenty.com>	2026-03-27 08:13:51 +00:00
Abdul Rahman	37640521d5	Batch create, update, and delete navigation menu items (#18882) ... Co-authored-by: Charles Bochet <charles@twenty.com>	2026-03-24 20:24:47 +00:00
Charles Bochet	611947e031	fix: metadata store lifecycle during sign-in, sign-out, and locale change (#18901) ... ## Summary Fixes metadata lifecycle bugs during sign-in, sign-out, and locale change: - **Cross-tab sign-out**: Broadcasts sign-out via `BroadcastChannel` so other tabs clear their session gracefully instead of hitting stale-token errors - **SSE teardown on sign-out**: Handles `UNAUTHENTICATED`/`FORBIDDEN` errors in the SSE event stream effect instead of throwing unhandled errors - **Locale switch resilience**: `invalidateAndReload` now invalidates collection hashes instead of clearing the store to empty, so components never see 0 metadata items during the reload transition - **Sign-in background mock**: Uses non-throwing `objectMetadataItemFamilySelector` instead of hooks that throw on missing metadata - **View name placeholders**: Guards against `undefined` `viewName` during metadata transitions (the minimal metadata query doesn't include `name`) - **Session cleanup**: Selective `localStorage` clearing (`clearSessionLocalStorageKeys`) preserves metadata keys; `clearAllSessionLocalStorageKeys` for full clears - **Metadata reload API**: New `useMetadataStoreActions` hook as the high-level API for metadata lifecycle operations (`applyMockedMetadata`, `invalidateAndReload`, `loadMockedMetadataAtomic`) ## Test plan - [ ] Sign out on Tab A → Tab A shows sign-in page with no console errors - [ ] Tab B (logged in) receives cross-tab broadcast and redirects to sign-in - [ ] No "Forbidden resource" SSE errors in console during sign-out - [ ] Change language in Settings > Experience → no crash, metadata refreshes in background - [ ] Sign back in after sign-out → metadata loads correctly, app is functional - [ ] Re-sign-in after locale change → correct locale is preserved	2026-03-24 14:57:53 +00:00
Charles Bochet	d5a7dec117	refactor: rename ObjectMetadataItem to EnrichedObjectMetadataItem and clean up metadata flows (#18830) ... ## Summary - Renames `ObjectMetadataItem` to `EnrichedObjectMetadataItem` across the entire frontend (~440 files) to clarify that this type includes derived fields (`readableFields`, `updatableFields`, nested `fields[]`, `indexMetadatas[]`) computed at read time from the metadata store - Creates `splitObjectMetadataGqlResponse` that goes directly from a GraphQL `ObjectMetadataItemsQuery` response to flat store items (combining the old `mapPaginatedObjectMetadataItemsToObjectMetadataItems` + `splitObjectMetadataItemWithRelated` two-step flow into one call) - Removes `ObjectMetadataItemWithRelated` type and all "WithRelated" naming - Renames `generatedMockObjectMetadataItems` to `generateTestEnrichedObjectMetadataItemsMock` to make it clear this is test-only enriched data - Deletes `useLoadMockedObjectMetadataItems` hook (consolidated into `useLoadMockedMinimalMetadata`) - Ensures nothing destined for the metadata store computes `readableFields`/`updatableFields` (preventing the localStorage bloat from #18809) ## Type hierarchy (before → after) **Before:** ``` ObjectMetadataItemsQuery → mapPaginated → ObjectMetadataItemWithRelated → enrich → ObjectMetadataItem → split → FlatObjectMetadataItem (store) ``` **After:** ``` ObjectMetadataItemsQuery → splitObjectMetadataGqlResponse → FlatObjectMetadataItem (store) → mapPaginated + enrich (tests only) → EnrichedObjectMetadataItem ``` ## Test plan - [x] `npx nx typecheck twenty-front` passes - [x] `npx nx test twenty-front` passes (767 suites, 4505 tests) - [x] `npx nx lint twenty-front` passes - [ ] CI checks pass Made with [Cursor](https://cursor.com)	2026-03-22 15:53:47 +01:00
Lucas Bordeau	fc9723949b	Fix AI chat re-renders and refactored code (#18585) ... This PR: - Breaks useAgentChatData into focused effect components (streaming, fetch, init, auto-scroll, diff sync) - Splits message list into non-last (stable) + last (streaming/error) to prevent full re-renders on each stream chunk - Adds scroll-to-bottom button and MutationObserver-based auto-scroll on thread switch - Lifts loading state from context to atoms - Adds areEqual to selector factories We could improve further but this sets up a robust architecture for further refactoring. ## Messages flow The flow of messages loading and streaming is now more solid. Everything goes out from `AgentChatAiSdkStreamEffect`, whether loaded from the DB or streaming directly, and every consumers is using only one atom `agentChatMessagesComponentFamilyState` ## Data sync effect with callbacks new hook See `packages/twenty-front/src/modules/apollo/hooks/useQueryWithCallbacks.ts` which allows to fix Apollo v4 migration leftovers and is an implementation of the pattern we talked about with @charlesBochet We could refine this pattern in another PR. # Before https://github.com/user-attachments/assets/84e7a96f-6790-405d-8a73-2dacbf783be5 # After https://github.com/user-attachments/assets/4c692e3a-2413-4513-abcc-44d0da311203 Co-authored-by: Charles Bochet <charles@twenty.com>	2026-03-21 12:52:21 +00:00
Charles Bochet	3d49c21b51	fix: decouple viewPicker favorite detection from sorted navigation menu items (#18803) ... ## Summary - Reverts the `useSortedNavigationMenuItems` coupling in `ViewPickerOptionDropdown` introduced by #18791 - The viewPicker now uses `useNavigationMenuItemsData` directly for the `isFavorite` check, keeping view ordering and navigation menu item ordering independent ## Why PR #18791 replaced `useNavigationMenuItemsData` with `useSortedNavigationMenuItems` in the viewPicker for favorite detection. While the intent was to filter out stale/orphaned navigation items, this created an unnecessary coupling: `useSortedNavigationMenuItems` subscribes to `viewsSelector` and `objectMetadataItemsSelector`, making the viewPicker transitively dependent on the navigation menu item ordering system. View ordering in the picker (driven by `view.position`) and navigation menu item ordering (driven by `navigationMenuItem.position`) should remain decorrelated. ## Test plan - [ ] Open the viewPicker dropdown and verify views are listed in correct order - [ ] Drag-and-drop to reorder views in the viewPicker — confirm it works - [ ] Verify the "Add to Favorite" / "Manage favorite" label still correctly reflects favorite state - [ ] Reorder navigation menu items in the sidebar — confirm viewPicker order is unaffected Made with [Cursor](https://cursor.com)	2026-03-20 16:08:26 +00:00
Sri Hari Haran Sharma	7c8f060b08	Fix orphan navigation menu items for deleted views (#18791) ... ## Summary Fixes #18757 This fixes a set of Favorites / navigation-menu-item integrity problems related to deleted views, stale hidden items, and upgraded workspaces with orphaned navigation items. ## What changed - delete `navigationMenuItem` entries when their favorited view is deleted - keep the client metadata store in sync immediately when a view is deleted - determine whether a view is already favorited from visible valid navigation items instead of raw stale items - add a `1.20.0` upgrade repair command that deletes orphan navigation menu items and normalizes positions - add regression coverage for deletion of both record-based and view-based navigation menu items ## Details Server: - extend `NavigationMenuItemDeletionService` so cleanup applies to deleted views as well as deleted records - add regression tests covering record-based deletion, view-based deletion, and no-op behavior - add `DeleteOrphanNavigationMenuItemsCommand` to remove orphaned items pointing to: - deleted views - deleted records - missing folders - normalize positions per scope (`userWorkspaceId + folderId`) after repair - wire the new repair command into the `1.20.0` upgrade flow Frontend: - add `useRemoveNavigationMenuItemByViewId` - remove the related navigation item from client metadata immediately when deleting a view - use sorted / visible navigation items for favorite detection so stale hidden rows do not block re-adding a favorite ## Why Issue `#18757` reports mismatches between Favorites shown in the UI and rows users can still find in the database. We found that current Favorites behavior is driven by `navigationMenuItem`, not the legacy `favorite` table, and that stale / orphaned `navigationMenuItem` rows could: - remain after deleting a favorited view - stay hidden from the UI if they point to invalid targets - still cause the UI to think a view was already favorited - persist in workspaces with migration damage from skipped sequential upgrades This patch addresses those cases directly and adds an upgrade-time repair path for older corrupted workspaces. ## Validation Passed: - `./node_modules/.bin/jest --config packages/twenty-server/jest.config.mjs --runInBand packages/twenty-server/src/engine/metadata-modules/navigation-menu-item/services/__tests__/navigation-menu-item-deletion.service.spec.ts` - `./node_modules/.bin/tsc -p packages/twenty-front/tsconfig.json --noEmit --pretty false` Known unrelated existing failure: - `./node_modules/.bin/tsc -p packages/twenty-server/tsconfig.json --noEmit --pretty false` The server typecheck failure is pre-existing and unrelated to this branch. Current errors are around `@file-type/pdf` module resolution and `is-psl-parsed-domain.type.ts`. --------- Co-authored-by: Charles Bochet <charles@twenty.com> Co-authored-by: Charles Bochet <charlesBochet@users.noreply.github.com>	2026-03-20 15:54:33 +01:00
Charles Bochet	394a3cef15	fix: restore ViewFilter value stringification lost in converter removal (#18745) ... ## Summary - **Restores `convertViewFilterValueToString()` calls** that were lost when the converter layer was removed in #18667. The GraphQL `ViewFilter.value` is typed as `JSON` (can be a string, array, or object), but the frontend type system expects a `string`. Without stringification, SELECT/MULTI_SELECT filter values (e.g. `['LOST']`) reach `arrayOfStringsOrVariablesSchema` as raw arrays, causing a `ZodError: expected string, received array`. - **Fixes applied at two data boundary points**: `splitViewWithRelated` (primary entry from metadata store) and `mapViewFiltersToFilters` (which also accepts `GqlViewFilter[]` directly). Fixes a production regression introduced by #18667. ## Test plan - [ ] Apply a SELECT filter (e.g. filter Opportunities by Stage = "Lost") — should no longer throw ZodError - [ ] Apply a MULTI_SELECT filter — should work correctly - [ ] Verify filters with multiple selected values work (e.g. Stage is "Lost" or "Won") - [ ] Verify empty filters and "is not" operands still work - [ ] Verify filters loaded from saved views still work after page refresh Made with [Cursor](https://cursor.com)	2026-03-18 19:06:43 +01:00
Charles Bochet	f1dfcfd163	refactor(twenty-front): reorganize NavigationMenuItem module into common/display/edit subfolders (#18691) ... ## Summary - Reorganizes the `navigation-menu-item` frontend module from a flat structure into `common/`, `display/`, and `edit/` subfolders with type-specific subdirectories (`link/`, `folder/`, `object/`, `view/`, `record/`) - Every file is now in a leaf folder describing its type: `components/`, `hooks/`, `utils/`, `types/`, or `constants/` - Moves 14 NavigationMenuItem-related components out of `object-metadata/` and `side-panel/pages/` into the `navigation-menu-item` module where they belong - Creates type-specific display utility functions (e.g., `getLinkNavigationMenuItemLabel`, `getObjectNavigationMenuItemComputedLink`) to replace generic switch-based functions - Unifies the Favorites section drag-and-drop from `@hello-pangea/dnd` to `@dnd-kit/react`, matching the Workspace section's DnD library - Renames Favorites section components from `CurrentWorkspaceMember*` to `Favorites*` for clarity - Deletes unused `FavoritesDragDropProviderContent` and `NavbarDragProvider` ## Test plan - [x] `npx nx typecheck twenty-front` passes - [x] `npx nx lint:diff-with-main twenty-front` passes (0 warnings, 0 errors) - [x] `npx nx test twenty-front` passes (763 suites, 4467 tests) - [ ] Verify favorites drag-and-drop still works in the UI (reorder items, move between folders) - [ ] Verify workspace edit mode drag-and-drop still works - [ ] Verify "add to navigation" drag from command menu/side panel still works	2026-03-17 06:46:50 +01:00
Charles Bochet	1be87eb97b	chore: frontend dead code removal and naming cleanup (#18690) ... ## Summary - **Delete 10 unused files**: 7 hooks (`useWorkflowRunUnsafe`, `useGetViewById`, `useCreateViewFieldGroup`, `useDeleteViewFieldGroup`, `useUpdateViewFieldGroup`, `useCreateManyViewFieldGroups`, `useMoveViewColumns` + test), 1 component (`SettingsSummaryCard`), 1 utility (`createEventContext`) - **Rename `objectMetadataItemsState` → `objectMetadataItemsSelector`** across ~85 files to accurately reflect it is a derived selector (via `createAtomSelector`), not a base Jotai atom ## Details ### Dead code removed | Type | Name | Reason | |------|------|--------| | Hook | `useWorkflowRunUnsafe` | Never imported — duplicate of `useWorkflowRun` without schema validation | | Hook | `useGetViewById` | Never imported — `useViewById` is used instead | | Hook | `useCreateViewFieldGroup` | Never imported — CRUD done via `usePerformViewFieldGroupAPIPersist` | | Hook | `useDeleteViewFieldGroup` | Same as above | | Hook | `useUpdateViewFieldGroup` | Same as above | | Hook | `useCreateManyViewFieldGroups` | Same as above | | Hook | `useMoveViewColumns` | Only imported by its own test — no production usage | | Component | `SettingsSummaryCard` | Never imported anywhere | | Utility | `createEventContext` | Never imported anywhere | ### Rename `objectMetadataItemsState` is created via `createAtomSelector` (it derives from `objectMetadataItemsWithFieldsSelector`), so naming it `*State` is misleading. Renamed to `objectMetadataItemsSelector` for consistency with sibling selectors like `objectMetadataItemsByNamePluralMapSelector`.	2026-03-17 00:49:37 +01:00
nitin	e552704201	fix: add viewFieldGroupId to ViewField fragment and connect page layout selectors to live metadata store (#18676)	2026-03-16 14:24:41 +01:00