# Complete color refactoring
Closes https://github.com/twentyhq/core-team-issues/issues/1779
- Updated all colors to use Radix colors with P3 color space allowing
for brighter colors
- Created our own gray scale interpolated on Radix's scale to have the
same values for grays as the old ones in the app
- Introduced dark and light colors as well as there transparent versions
- Added many new colors from radix that can be used in the tags or in
the graphs
- Updated multiple color utilities to match new behaviors
- Changed the computation of Avatar colors to return only colors from
the theme (before it was random hsl)
These changes allow the user to use new colors in tags or charts, the
colors are brighter and with better contrast. We have a full range of
color variations from 1 to 12 where before we only had 4 adaptative
colors.
All these changes will allow us to develop custom themes for the user
soon, where users can choose their accent colors, background colors and
there contrast.
Adding an early return when no select field exists and you are
redirected to the setting page otherwise it tries to call
setAndPersistViewType with kanban and fails with "No fields for kanban -
should not happen"
Fixes https://github.com/twentyhq/twenty/issues/15369
It's the first time we are hitting this weird behavior on apollo
onCompleted / onError. Theoretically if the reference of the onCompleted
(resp onError) callback is changing, this will trigger a re-run of
onCompleted. But also theretically the reference here is a
recoilCallback so should never change.
As this is synchronous I have move this logic to a sync way
Closes#15345
The issue was that when the `onChange` was called on the Select
component in `WorkflowEditActionFindRecords.tsx`, the limit was being
reset to 1, but it wasn't rendering immediately. The sidebar had to be
closed and reopened.
I have added a `useEffect` as a hack to re-render the
`FormNumberFieldInput` when it's `defaultValue` is changed. I understand
that using `useEffect` is not a good choice. Please suggest a better fix
if any and I will implement it.
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
# Introduction
Please first review this PR initial base
https://github.com/twentyhq/twenty/pull/15358
In a nutshell refactored the frontend fetchers to display v2 errors
format smoothly
Please note that the v2 now finished the whole validation and does fail
fast anymore ( summary is hardcoded for the moment )
```json
[
{
"extensions": {
"code": "BAD_USER_INPUT",
"errors": {
"cronTrigger": [],
"databaseEventTrigger": [],
"fieldMetadata": [
{
"errors": [
{
"code": "INVALID_FIELD_INPUT",
"message": "Default value should be as quoted string",
"value": "",
},
{
"code": "INVALID_FIELD_INPUT",
"message": "Default value "" must be one of the option values",
"value": "",
},
],
"flatEntityMinimalInformation": {
"id": Any<String>,
"name": "testField",
"objectMetadataId": Any<String>,
},
"status": "fail",
"type": "create_field",
},
],
"index": [],
"objectMetadata": [],
"routeTrigger": [],
"serverlessFunction": [],
"view": [],
"viewField": [],
"viewFilter": [],
"viewGroup": [],
},
"message": "Validation failed for 0 object(s) and 0 field(s)",
"summary": {
"invalidCronTrigger": 0,
"invalidDatabaseEventTrigger": 0,
"invalidFieldMetadata": 0,
"invalidIndex": 0,
"invalidObjectMetadata": 0,
"invalidRouteTrigger": 0,
"invalidServerlessFunction": 0,
"invalidView": 0,
"invalidViewField": 0,
"invalidViewFilter": 0,
"invalidViewGroup": 0,
"totalErrors": 0,
},
"userFriendlyMessage": "Validation failed for 0 object(s) and 0 field(s)",
},
"message": "Multiple validation errors occurred while creating fields",
"name": "GraphQLError",
},
]
```
## What's done
- `usePersistView` tool ( CRUD )
- renamed `usePersistViewX` tools accordingly ( no more records or core
)
- Now catching a lot of before unhandled exceptions
- refactored each services to handle their own exception handlers and
return either the response or the error within a discriminated union
record
## Result
### Primary entity error
When performing an metadata operation on a given metadata, if validation
errors occurs we will display each of them in a toast
Here while creating an object metadata.
<img width="700" height="327" alt="image"
src="https://github.com/user-attachments/assets/0c33d13c-c66c-4749-af36-b253abd3449b"
/>
### Related entity error
Still while creating an object
<img width="700" height="327" alt="image"
src="https://github.com/user-attachments/assets/52607788-c4e9-470c-ac8c-23437345ee5c"
/>
### Translated
<img width="700" height="327" alt="image"
src="https://github.com/user-attachments/assets/a7198c20-ae82-47a6-910c-761de9594672"
/>
## Conclusion
This PR is an extract of https://github.com/twentyhq/twenty/pull/15331
close https://github.com/twentyhq/core-team-issues/issues/1776
## Notes
- Not refactor around triggers services as they're not consumed directly
by any frontend services
Two bug fixes here:
# MorphRelationOneToManyFieldDisplay
we expect an empty array, not undefined (run time error otherwise)
Fixes `Cannot read properties of undefined (reading 'length'): Cannot
read properties of undefined (reading 'length')` in
**MorphRelationOneToManyFieldDisplay**
```js
morphValuesWithObjectNameSingular.every(
(morphValueWithObjectNameSingular) =>
morphValueWithObjectNameSingular.value.length === 0,
);
```
# create record in table mode
if the record has a relation there is currenlty a bug in production when
it is created. A cache issue.
`Missing field 'companyFoundedId' while writing result `
Fixes - https://github.com/twentyhq/twenty/issues/15263
- Replaced `useLoadSelectedRecordsInContextStore` with
`useLoadMergeRecords` in `useOpenMergeRecordsPageInCommandMenu` for
improved functionality.
- Updated `useMergePreview`, `useMergeRecordsActions`, and
`useMergeRecordsSettings` to utilize `mergeRecordsState` instead of the
deprecated context store hook.
- Cleaned up imports and ensured consistency across merge-related hooks.
https://github.com/user-attachments/assets/453539c9-7f2b-4e8c-bfa1-3ceebca07081
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
Here's a concise PR description for your changes:
---
## Fix morph relation fields showing placeholder in kanban view
**Problem:** Morph relation fields always displayed placeholders in
kanban view even when records were selected, because
`useRecordFieldValue` was checking the base field name (e.g.,
`"favorite"`) instead of the computed morph field names (e.g.,
`"favoriteCompany"`).
**Solution:** Modified `useRecordFieldValue` to accept an optional
`fieldDefinition` parameter and added special handling for morph
relations that uses
`recordStoreMorphManyToOneValueWithObjectNameFamilySelector` and
`recordStoreMorphOneToManyValueWithObjectNameFamilySelector` to
correctly retrieve values. Updated `useIsFieldEmpty` to pass the field
definition through, enabling proper empty state detection for morph
relation fields.
**Impact:** Morph relation fields now correctly display their values in
kanban board cards instead of showing placeholders.
Fixes https://github.com/twentyhq/core-team-issues/issues/1323
<img width="681" height="420" alt="Screenshot 2025-10-22 at 14 11 07"
src="https://github.com/user-attachments/assets/de357379-ebff-42c6-bb93-1f0c43ce086d"
/>
Adds the field on the Show page and side panel for Morph relation
fields.
Updates
`packages/twenty-front/src/modules/object-record/record-field/ui/meta-types/input/hooks/useOpenMorphRelationOneToManyFieldInput.tsx`
to use the correct `recordPickerInstanceId` when opening the picker so
the helper consistently renders (fixes [core-team-issues
#1324](https://github.com/twentyhq/core-team-issues/issues/1324)).
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
- Use aggregate operations in the widget configuration instead of
extended aggregate operations
- Use aggregate operation from generated graphql in the frontend
## Context
The _expected response body_ does not use monaco-editor, so enabling
`formatOnPaste `as mentioned in this
[comment](https://github.com/twentyhq/twenty/issues/13506#issuecomment-3188746787)
didn't fix the issue below. However, the `TextVariableEditor` uses
tiptap editor which has a `handlePaste` option that we can use to format
JSON.
- Issue https://github.com/twentyhq/twenty/issues/13506
## Implementation:
1. Insert the clipboard text at the current selection.
2. Retrieve the full editor content, parse it as JSON and stringify it
with indentation.
3. Re-use the method that transforms the text into `JSONContent`.
4. Replace the root node with the newly formatted `JSONContent`.
5. Update the cursor position based on the type of pasted text.
6. Apply the transaction with `view.dispatch()`
Note: If parsing fails (invalid JSON), the input will fall back to a
normal paste.
## test
Loom:
https://www.loom.com/share/f2e84d078662481f9f9f71fc98b772a1?sid=a649c4e9-8c55-4cbe-b031-7aba60af0e05
Fixes [Dependabot Alert
85](https://github.com/twentyhq/twenty/security/dependabot/85) -
prototype pollution in lodash.
Added a shared pick helper (with unit tests) in twenty-shared and
refactored front-end/server code to import { pick } from the shared
barrel instead of lodash.pick.
---------
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
Co-authored-by: martmull <martmull@hotmail.fr>
Step 1 towards fixing issue #14976
Refactored WorkflowSendEmailBody to FormAdvancedTextFieldInput For its
reusability across application
- `useEmailEditor` is transformed to `useAdvancedTextEditor`: A
reuseable hook for managing the text editor state and functionality.
- `WorkflowSendEmailBody` is transformed to
`FormAdvancedTextFieldEditor`: A wrapper component for the advanced text
editor.
- `WorkflowSendEmailBody` is transformed to
`FormAdvancedTextFieldInput`: A component integrating the advanced text
editor into forms.
- `ImageBubbleMenu`, `LinkBubbleMenu`, and `TextBubbleMenu`: Contextual
menus for image, link, and text formatting options. are moved to
ui/components for access in FormAdvancedTextFieldInput
Additionally, the email action workflow component was updated to utilize
the new reuseable text editor, enhancing the user experience for
composing emails.
This update also includes storybook entries for the new components to
facilitate testing and documentation.
---------
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
Co-authored-by: Félix Malfait <felix@twenty.com>
This PR fixes two bugs :
- Data loading not working between 60 and 120 records on an object
- Table not refreshing when creating a record in an empty table.
Fixes https://github.com/twentyhq/twenty/issues/15196
## Overview
This PR fixes instances where `height` properties were incorrectly
defined multiple times within the same styled component definitions
across the codebase.
## Problem
Several styled components had duplicate `height` CSS properties where
the exact same property was declared twice in the same selector, causing
confusion and reducing code maintainability. The second declaration
would override the first, making the first one dead code.
## Changes
Fixed 4 files across the codebase:
### Duplicate `height: 100%` Removed
**StyledShowPageRightContainer** in twenty-front:
- `PageLayoutRendererContent.tsx`
- `ShowPageSubContainer.tsx`
- `PageLayoutRecordPageRenderer.tsx`
Each had `height: 100%` declared twice in the same component definition
(strict duplicates).
### Duplicate `height` with Different Values Removed
**StyledCommandKey** in twenty-ui:
- `MenuItemHotKeys.tsx` - Had both `height: ${({ theme }) =>
theme.spacing(5)}` and `height: 18px` declared. Removed the first
declaration as the second was overriding it.
## Testing
- ✅ ESLint checks pass
- ✅ TypeScript compilation successful
- ✅ CodeQL security analysis - no issues
- ✅ Comprehensive codebase scan confirms no remaining strict height
duplicates
## Impact
- **Visual Changes**: None - purely cleanup refactoring
- **Performance**: No runtime impact
- **Breaking Changes**: None
- **Code Quality**: Improved CSS maintainability by removing dead code
---
**Total:** 4 files modified, 5 lines removed
Created from VS Code via the <a
href="https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-pull-request-github">GitHub
Pull Request</a> extension.
<!-- START COPILOT CODING AGENT SUFFIX -->
<details>
<summary>Original prompt</summary>
> Hi! It seems that a few styled components in the #codebase are defined
with duplicate `height: 100%`, like in
#file:PageLayoutRendererContent.tsx:27-36.
>
> Your job is to find all the places where we defined `height: 100%`
incorrectly several times and to keep only one `height` property.
</details>
Created from VS Code via the [GitHub Pull
Request](https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-pull-request-github)
extension.
<!-- START COPILOT CODING AGENT TIPS -->
---
💡 You can make Copilot smarter by setting up custom instructions,
customizing its development environment and configuring Model Context
Protocol (MCP) servers. Learn more [Copilot coding agent
tips](https://gh.io/copilot-coding-agent-tips) in the docs.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: Devessier <29370468+Devessier@users.noreply.github.com>
Co-authored-by: Baptiste Devessier <baptiste@devessier.fr>
This PR fixes advanced filters classic in view bar which crashes after
the recent refactor on chart advanced filters.
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
This fixes#15156
Issue:
Restore and Destroy buttons not appearing in action menu for deleted
records until the record detail view is opened.
Cause:
The record index/table view queries only fetched fields that were
visible as table columns
The [deletedAt] field (along with [createdAt] and [updatedAt]) was not
included in these queries since it's not a visible column
The action menu logic checks [selectedRecord?.deletedAt] to determine if
a record is deleted and which actions to display
Without the [deletedAt] field in the record store, the action menu
couldn't detect deleted records
Opening the detailed view would fetch all fields (including
[deletedAt]), which is why the buttons would appear afterward
Solution
Modified [useRecordsFieldVisibleGqlFields] to always include the
standard fields ([createdAt], [updatedAt], [deletedAt]) in record index
queries, regardless of column visibility. This ensures the action menu
can immediately detect deleted records
---------
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
Co-authored-by: Félix Malfait <felix@twenty.com>
This PR adds the components for advanced filters on chart settings.
It also refactors what's in common between this new command menu page
and the workflow advanced filters.
This PR makes some hooks/functions/components more generic. I untied
them from dashboards as they will be needed for any page layout type.
---------
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
This PR determines the minimal setup required to render dashboards
without errors while extracting them from the record show page. The
ultimate goal is to create a `PageLayoutRenderer` component that takes
any page layout configuration and correctly renders dashboards or record
pages.
Currently, the `DashboardCard` component renders itself the
`PageLayoutRenderer` component. The next step is to reverse the flow of
control and make `PageLayoutRenderer` take a configuration and decide
whether it should render a dashboard or something else.
This PR takes into consideration two comments left by Charles on [the
first PR scaffolding the
refactor](https://github.com/twentyhq/twenty/pull/15021): renaming
`targetRecord` to `targetRecordIdentifier` and adding tests to
`evaluateTabVisibility()`.
## Demo to assert this PR doesn't break everything
https://github.com/user-attachments/assets/b5b99cf3-08fa-43d3-8da1-79018bc63641
# Introduction
Adding view-group to core engine v2
Following https://github.com/twentyhq/twenty/pull/15010 ( same pattern )
## What's done
- Created flat-view-group
- flat view group runner
- flat view group builder
- create view group service v2 and input transpilers
- refactor the existing view group resolver to fix standard (
BREAKING_CHANGE on graphql api update especially ) REST stays the same
- refactored the front to consume the mutations autogenerated
close https://github.com/twentyhq/core-team-issues/issues/1665
- Added readableFields for visible record field selector to take
permission into account
- Force refresh of table virtualization when updating view fields
Avoid fetching full steps and trigger for versions that are not the
current version. Because those won't be used anyway. Better for
performances.
Only difficulty was for the `createDraft` mutation. I needed to return
the full created version so I can store it in cache and use it as new
`currentVersion`. Otherwise the current version is considered as
incomplete for a short time, since workflow is fetched separately from
the current version.
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
This big PR implements table virtualization with an offset paging,
allowing a way more fluid UX.
It is a v1 that should be improved in the future with partial data
loading and optimization of the browser display performance of a row.
But with this PR we have the solid enough technical foundation, both
frontend and backend, to get to a smooth table UX.
Fixes and improvements after first successful round of development
(needed to have main clean) :
- [x] Delete should refresh virtualized portion only and reset all table
- [x] Fix add new : top and bottom
- [x] Table empty shouldn’t show when first loading
- [x] Fix d&d
- [x] Fix sorts
- [x] Fix drag when scrolling after a full virtual page (it throws an
error)
- [x] Si update mais qu’on a un sort ou filter, alors il faut trigger le
refresh
- [x] Reset scroll position between tables
- [x] Reset scroll shadows between tables
- [x] Setup d&n for virtual list :
https://github.com/hello-pangea/dnd/blob/main/docs/patterns/virtual-lists.md
- [x] Full table re-render when entering edit mode
- [x] Clean code and prepare for merge
Fixes https://github.com/twentyhq/core-team-issues/issues/1613 that
contains other bugs to be fixed before merge
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
## Refactor: Prepare frontend record layouts for backend-driven
configuration
This PR simplifies and prepares the frontend record layout system for
eventual migration to backend-driven layouts, aligning the architecture
with the existing PageLayout system used for dashboards.
### Key Changes
**Architecture Improvements:**
- Created unified LayoutRenderingContext that works for both record
pages (with targetRecord) and dashboards (standalone)
- Replaced prop drilling with context-based data flow - cards access
targetRecord and isInRightDrawer via context hooks
- Introduced useTargetRecord() helper hook that provides type-safe
access to the current record
- Created generic CardRenderer component that handles configuration
injection and context guards uniformly
**Configuration System:**
- Converted all tab icons from React components to JSON-serializable
strings (e.g., Icon: IconCheckbox → icon: 'IconCheckbox')
- Added configuration field to cards, matching the widget configuration
pattern on the backend
- Created CardConfiguration types system similar to WidgetConfiguration
on the backend
- Moved widget-specific props (like showDuplicatesSection) into
configuration objects
**Code Organization:**
- Extracted visibility evaluation logic into reusable
evaluateTabVisibility() utility
- Organized layouts into dedicated files (one per object:
base-record-layout.ts, company-record-layout.ts, etc.)
- Renamed components to match their purpose: Notes → NotesCard,
Attachments → FilesCard, etc.
- Consolidated card rendering from registry object to direct
getCardComponent() function
**API Alignment:**
- Made ifNoReadPermissionObject an explicit part of TabVisibilityConfig
(follows if* naming convention)
- Removed redundant targetObjectNameSingular from tab-level (now derived
from visibility config)
- Card API now mirrors Widget API (both use type, configuration,
accessed via context)
## Problem
With Twenty usage growing, we are facing challenges on server side to
respond to the demand. The current bottleneck we are facing is server
CPU.
While investigating CPU performances, we figured out that loading all
relation fields was the biggest issue.
### About graphql query response size
**Example:** on `People Index` Table page:
we query: `person.company` and we query **all non relation fields** on
company relation field.
`{ person { company { id, name, domainName, employees, address ... } }`
However we only need **company.id, company.name and company.domainName**
to be able to render the Company Chip in the company column (RELATION)
in the table.
`{ person { company { id, name, domainName } }`
We initially assumed that the querying all non relation fields was not
an issue because it was not adding additional load on database (which is
also partially true: if a field is containing a huge json this will add
load on postgres as data needs to be transfered)
This assumption is wrong on CPU side:
- when loading one to many relations (company.people), this quickly ads
up and we end up with response of 20kB quite quickly, even without
adding any custom field on person.
- even when loading a many to one relation, if the user is storing big
data in a given field (note.body for instance, or workflowRun.state),
this starts also being an issue.
- Worst case scenario are starting to happen: on a production workspace
with 20 active workflows. Loading workflow table while displaying
workflow runs commands (20 workflows x 60 workflowRuns x
workflowRun.state which is a big JSON) result in a response of... 125MB.
### Why is it an issue?
When yoga (graphql engine) parses a response to send it back in server
response, it's using `JSON.parse `(or stringify depending on the case).
Parsing data is CPU instensive (as you need to validate, transform) and
this is more or less `O(n)`.
This means returning 125MB is very intense on the CPU and will likely
use 100% of the CPU for ~1sec in our production servers.
NodeJs (nodeV8) is single threaded. It's able to process multiple
requests in parallel but to do that, it will cut them in "microTasks"
and process each microTasks (that can belong to different requests) one
after the other. Exactly like a single threaded CPU would allocate some
time to a process and then to the next one, etc.
This means that this big response request will actually block the other
request.
As a result, all requests are slow and our infrastructure is multi
tenant so some customers are impacting others.
This is even a bigger issue when our health checks start to fail and
containers are starting being considered as unhealthy and killed by the
orchestrator
## How to fix this
1. On Front end side, we should only query what we need. In this PR, I'm
forcing the relations to only query: `id`, `labelIdentifier`,
`imageIdentifier`
2. (later) as we are API first, we also need to do something to protect
the servers from this side too. To do that, Graphql APIs can associate a
cost to each graphql field (maybe 1 for a test fixed, 2 for a JSON
field, 10 for relations, etc...) and we can throttle based on that.
## Changes in this PR
It's mainly about refactor the tooling to generate `RecordGqlFields`
(`generateDepthOneGqlFields`). this tooling is used to generate the list
of fields we want to query. Most of the time we want to query a record
with one level of nesting.
1) Refactor to remove duplicate code => `generateDepthOne` become
`generateDepth` and can handle both `depth = 0 | 1`
2) Introduce `generateDepthRecordGqlFieldsFromFields.ts` which is the
base and can give you a list of gqlFields based on FieldMetadataItems
3) Introduce `generateDepthRecordGqlFieldsFromObject` which is a
shortcut for an object
4) Introduce `generateDepthRecordGqlFieldsFromRecords` which is the
intersection between `generateDepthRecordGqlFieldsFromObject` and a
given record (useful for cache tooling)
5) Replace all usages + introduce a hook
`useGenerateDepthRecordGqlFieldsFromObject` to ease usage
Charles Bochet