## 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
## Summary
1. This change introduces the ability to limit how many values a
multi-value field can contain (for example: maximum number of emails,
phone numbers, links, or array items).
2. It centralizes the limit as a shared constant and type, validates
settings on the server, updates front-end types and components to
consume the setting, and adds a small settings UI so workspace admins
can change the limit per field.
3. Default behavior is preserved: if no max is configured, the existing
default (10) is used.
## **Fixes Issue:** [#14740
](https://github.com/twentyhq/twenty/issues/14740)
## Manual Test Screenshot
<img width="383" height="451" alt="Screenshot 2025-10-08 002413"
src="https://github.com/user-attachments/assets/a7704af6-10ef-4d10-b8c9-a9eeca03bfd9"
/>
### Values in fields
https://github.com/user-attachments/assets/7f59c4f7-3aca-4f83-8c04-3d44988316e3
Let me know if any changes are needed
---------
Co-authored-by: Félix Malfait <felix@twenty.com>
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
Storybook had issues. This PR intends to solve them
Main things to care :
I had to change the way the provider was given to the Calendar view. Not
sure how it may impact the final component, so if someone with some
knowledge about it could take a look that would be great
TODO:
Only one remaining test to fix : prefetch loading. Couldn't find out how
to solve this issue. When you open the story you see that the companies
are not fetched.
## Scope
- Refactor SingleRecordPicker to handle morphItem and match Multiple one
- fix query generation to take morph into account
Left:
- double check SingleRecordPicker in Workflows / Form
- Fix tests / stories
This PR follows the multiSelect PR merged previously. It will enable
morph relation Many to One to be handled from the table, using a
singleSelect picker
Main point : I decided to change the singleSelect API to take an array
of **objectMetadataName** instead of only one to deal with both our
usecases.
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
fix:Ability to add a new option for a multi-select on the fly
Issues:#13877
---------
Co-authored-by: ehconitin <nitinkoche03@gmail.com>
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
## Performance short term fix
Done in this PR:
workflowVersions and workflowRuns are heavy object. I'm preventing
loading their data when they are loaded as relations. This will reduce
the work on backend
## Long term fix
Todo:
We should make sure workflow data is ligher
This PR is the first part of the creation of the Chart editor.
https://github.com/user-attachments/assets/8b0af8ea-be41-4506-84cb-e40f5521cbf0
Done:
- Bar chart settings (except filters)
- Line chart settings (except filters)
In progress:
- Pie chart settings
- Number chart settings
- Gauge chart settings
Left to do:
- Loosen the backend validation to allow the user to save a partial
configuration, validate the graph configuration in the frontend and
display a error friendly message in the graph if the config is not
completed yet
- Implement the filter edition
- Finish the other graph types settings
# Calendar View: Add "+" Button to Calendar Day Cards
## Description
This PR implements the "+" button on calendar day cards in the Month
view, allowing users to create new records directly from the calendar.
- The "+" button appears **on hover** only.
- Newly created records include the **day representing the card** in the
payload (UTC, with only the date part).
- Respects **object permissions** and **soft delete filters**.
- Automatically integrates with **active filters** used in Table and
Kanban views.
## Implementation Notes
- `RecordCalendarAddNew` component handles button visibility and record
creation.
- UTC date is passed to the create function to ensure proper timezone
handling.
- No unit tests added yet (need senior guidance).
---
[Screencast from 2025-09-24
20-10-18.webm](https://github.com/user-attachments/assets/bd117b43-6c1b-4267-874f-b36844733d9e)
### Video ->
## Related Issues
Fixes: https://github.com/twentyhq/core-team-issues/issues/1552
---------
Co-authored-by: Weiko <corentin@twenty.com>
Following https://github.com/twentyhq/twenty/pull/14762
In this PR
- moved logic around any field filter formatting to twenty-shared
- added any field filter to the filters applied to groupBy when viewId
is defined
- added integration test
In the BE we have stored filter operand as IS_EMPTY, IS_NOT_EMPTY, etc.
For some reason in the FE we were manipulating IsEmpty, IsNotEmpty, etc.
(maybe because they were used before in Views before they were moved to
core)
So we were converting the operands in the FE from IS to Is
(convertViewFilterOperandFromCore) to read and manipulate viewFilters,
and then back to BE version to send mutations etc., from Is to IS
(convertViewFilterOperandToCore).
The migration is now over, so we can remove and simplify that code.
(In the 1-5:migrate-views-to-core command we still do the migration from
Is format to IS format.)
Closes https://github.com/twentyhq/core-team-issues/issues/1560
If viewId is defined in a groupBy query, we want to apply all filters of
the view to the query.
This required to move a lot of code from twenty-front to twenty-shared
to convert the filters as stored in the db into graphql filters,
applying the right combinations between filters etc., which was
previously only done in the FE.
This PR does not handle any field filters, it will be done in a later pr
https://github.com/user-attachments/assets/d6c565eb-9a29-4830-9396-5f979c8caa7b
- Added a new component for manual trigger (mostly duplicated from
previous one). Will remove the old one once all data are migrated
- Updated schema output so the current item of the iterator can be typed
Todo left:
- migrate old triggers
- add an util to search iterator output. Today current item fields will
be displayed as not found
- set new manual triggers for workflow runs
This PR essentially refactors some hard-coded values for width and
height in the table.
It also fixes a few differences from the Figma design, on the checkbox
column width and the top bar and view bar left alignment with the table.
The blue color has been set like before the refactor of the focus portal
(`theme.adaptiveColors.blue4`)
Fixes in https://github.com/twentyhq/core-team-issues/issues/1490 :
- Fix first drag and drop column width that has changed from main (see
Figma)
- Unify all widths, heights, z-index, etc. with constants
- Put same blue as before for focused portal
Also removed `focus-active` class because we now use a portal for the
focus.
Fixes https://github.com/twentyhq/twenty/issues/14442
Issues were
1. Table headers always used label metadata identifier (or record text)
as first column, while table body followed viewFields positions
2. Label metadata identifier should always be visible and in first
position for the table views to work as expected, while when updating
the label metadata identifier for an object, no changes were brought to
the viewFields
To fix that
1. In the BE:
- a new logic is implemented to i) update label identifier's viewFields
position and visibility when an object's label identifier is updated to
a new field; ii) add validation on the update of a viewField's position
and visibility to make sure the label identifier's viewField always has
the lowest position + is visible
- a command was added to check all existing views and viewfields
3. In the FE: at first I tried to replicate the logic of the headers
(based on the label identifier rather than the positions) on the body,
but it was too complex and error-prone as in multiple places we are
based on the positions. It also feels more right to have only one source
of truth which is the viewField position. @lucasbordeau if that does not
suit you, we can throw an error if the field with the lowest position is
not the label metadata identifier, as you said the table view will be
very buggy / wont work if the label identifier is not in the first
position. but now it should never be the case thanks to the validation
implemented in the BE
This should be migrated to viewFieldService V2 when relevant @Weiko
@prastoin
This PR brings more UX fixes for table.
Fixes in https://github.com/twentyhq/core-team-issues/issues/1490 :
- Fix any field filter chip formatting
- Empty placeholder should be centered on screenwidth and not scrollable
width on table
- First cell is automatically active on table but we can't move => We
now allow focus position to be null as it is a portal
Fixes https://github.com/twentyhq/twenty/issues/14573
### Description
Field values in RecordInlineCell were disappearing on hover even when
read-only.
This was caused by the hover CSS being applied unconditionally and
readonly prop not used properly.
Fixes#14582
---
### Changes
- Added $readonly prop to StyledValueContainer to conditionally apply
hover opacity.
- Read-only fields now display values normally;
---
### Video ->
[Screencast from 2025-09-18
06-17-20.webm](https://github.com/user-attachments/assets/d1ad8a0a-5903-4709-b02a-77ae2e1315f1)
This PR fixes the focused row that was making the group section border
bottom disappear if collapsed.
In https://github.com/twentyhq/core-team-issues/issues/1490, fixes :
- Section border-bottom disappear if the focus is on the first row of a
collapsed section
Fixes:
- relation one to many cannot be set (we have deprecated limit: keyword
in graphql at it was not use, we should only use first or last)
- https://github.com/twentyhq/twenty/issues/14556
This PR fixes a few z-index issues on table with groups.
Once the z-index issues will have been stabilized, we'll refactor this
big constant file which is hard to maintain.
In https://github.com/twentyhq/core-team-issues/issues/1490, fixes :
- Aggregate footer label identifier is hidden
- Bug sticky footer label identifier on table with groups has not the
right z-index
This PR fixes the column resize handle issues.
Fixes in https://github.com/twentyhq/core-team-issues/issues/1490 :
- We see the pointer blink when resizing => Already here before
refactor, this is because the mouse enter / leave events shouldn't be
triggered while resizing.
- Resizing handle sometimes cannot be clicked anymore / does not appear
anymore (see if another listener doesn't prevent this)
The code will need to be cleaned after all fixes have been done though
has it duplicates logic between the different header components.
This PR fixes the last column of a table with groups that was wrapping
on a new line on a empty table or its filtering equivalent (filter
without result)
Fixes in https://github.com/twentyhq/core-team-issues/issues/1490 :
- Fixes most urgent : Empty table with groups header wraps
- Fixes less urgent : Resizing a table with groups makes some filling
resize in the wrong direction
Guillim