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
## ✨ Add accent-insensitive search functionality
### 🎯 Overview
Implements accent-insensitive search across all searchable fields in
Twenty CRM.
Users can now search for "jose" to find "José", "muller" to find
"Müller", "cafe" to find "café", etc.
### 🔍 Problem
Twenty's search functionality was accent-sensitive, requiring users to
type exact accented characters to find records.
This created a poor user experience, especially for international names
and content.
### 💡 Solution
Added PostgreSQL `unaccent` extension with a custom immutable wrapper
function to enable accent-insensitive full-text search across all
searchable field types.
### 📋 Changes Made
**Modified Files:**
- `packages/twenty-server/scripts/setup-db.ts`
-
`packages/twenty-server/src/engine/api/graphql/graphql-query-runner/utils/compute-where-condition-parts.ts`
-
`packages/twenty-server/src/engine/workspace-manager/workspace-sync-metadata/utils/get-ts-vector-column-expression.util.ts`
### 🗄️ Database Setup (`setup-db.ts`)
```sql
-- Added unaccent extension
CREATE EXTENSION IF NOT EXISTS "unaccent";
-- Created immutable wrapper function
CREATE OR REPLACE FUNCTION unaccent_immutable(text) RETURNS text AS $$
SELECT public.unaccent($1)
$$ LANGUAGE sql IMMUTABLE;
```
### 🔍 Search Vector Generation
(`get-ts-vector-column-expression.util.ts`)
Applied `public.unaccent_immutable()` to all searchable field types:
- TEXT fields (job titles, names, etc.)
- FULL_NAME fields (first/last names)
- EMAILS fields (both email address and domain)
- ADDRESS fields
- LINKS fields
- RICH_TEXT and RICH_TEXT_V2 fields
### 🔎 Query Processing (`compute-where-condition-parts.ts`)
Enhanced search queries to use `public.unaccent_immutable()` for both:
- Full-text search (`@@` operator with `to_tsquery`)
- Pattern matching (`ILIKE` operator)
### 🧠 Technical Rationale: Why the Wrapper Function?
**The Challenge:**
PostgreSQL's built-in `unaccent()` is marked as **STABLE**, but
`GENERATED ALWAYS AS` expressions (used for search vector columns)
require **IMMUTABLE** functions.
**The Solution:**
Created an IMMUTABLE wrapper function that calls the underlying
`unaccent()` function:
- ✅ Satisfies PostgreSQL's immutability requirements for generated
columns
- ✅ Maintains the exact same functionality as the original `unaccent()`
- ✅ Uses fully qualified `public.unaccent_immutable()` to ensure
function resolution from workspace schemas
**Alternative Approaches Considered:**
- ❌ Modifying `search_path`: would affect workspace isolation
- ❌ Computing unaccent at query time: would hurt performance
- ❌ Using triggers: would complicate data consistency
### 🎯 Impact
For **Person** records, accent-insensitive search now works on:
- Name (first/last name): `"jose garcia"` finds `"José García"`
- Email: `"jose@cafe.com"` finds `"josé@café.com"`
- Job Title: `"manager"` finds `"Managér"` or `"Gerente de Café"`
Applies to all searchable standard objects:
- Companies, People, Opportunities, Notes, Tasks, etc.
- Any custom fields of searchable types (TEXT, EMAILS, etc.)
### ✅ Testing
- Database reset completes successfully
- Workspace seeding works without errors
- Search vectors generate with unaccent functionality
- All searchable field types properly handle accented characters
---------
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
In the case of DB events, id field will be prefixed with
'property.after'. This is why we need to use the fieldIdName when
provided.
Before: When providing only id, Company variable is {{trigger.id}}.
Which does not exists on DB event output schema
<img width="939" height="462" alt="Capture d’écran 2025-09-16 à 17 57
42"
src="https://github.com/user-attachments/assets/c46dc00a-bb0e-45b9-af42-e9ddd0a08aea"
/>
After: Company variable is {{trigger.property.after.id}}
<img width="939" height="578" alt="Capture d’écran 2025-09-16 à 17 57
14"
src="https://github.com/user-attachments/assets/ede11de0-b98e-40df-89a1-9b283a2692ff"
/>
This is the third PR from the split of
https://github.com/twentyhq/twenty/pull/14458 - refactoring only the
PieChart widget.
Plus small performance improvements on already refactored widgets
In this PR:
- Refactored the page layout renderer
- Converted all the states to component states
- Removed the page layout edition in settings
TODOs in next PRs:
- Fix bug with the drag selector not taking the scroll into account to
display the dragged area
- Readd the tab edition in edit mode
This PR fixes table issues while displaying on mobile, the label
identifier cell and footer cells where using a width not corresponding
to the header cell.
We fix this by creating a shared constant and adapting the CSS for this
case with a media query.
Fixes https://github.com/twentyhq/core-team-issues/issues/1454
This PR fixes z-indices on all cases for table with and without groups.
It also fixes 1px glitches that appeared previously already and also
during this refactor, with active and focused rows.
The focus on cells is no a portal similar to hovered portal, which works
really easily thanks to the z-index management already done on hovered
portal.
The urgent issues here
https://github.com/twentyhq/core-team-issues/issues/1490 have been
fixed.
This PR fixes https://github.com/twentyhq/twenty/issues/13022
It was due to a mouse leave event that worked for table without groups
but not with table with groups, the fix is to handle this event higher
up in the table.
This PR also fixes a bug that happened when hiding a column, the page
crashed because of an indexed array returning undefined that TS didn't
catch, linked to
https://github.com/twentyhq/core-team-issues/issues/1205.
This PR brings fixes to the table after the div refactor.
There is still work to do to simplify and clean code, fix some left
bugs, but overall this PR brings a way cleaner experience already.
The table with groups still needs some work as it is often less tested,
thus it has more bugs and code to clean.
What this PR fixes :
- Started refactoring hard-coded height and widths into constants (still
some work to do)
- Refactored TABLE_Z_INDEX and its consumer to separate into withGroups
and withoutGroups (still some refactoring to simplify this)
- Refactored common placeholder cells : add button, dynamic filling
cell, checkbox, drag and drop
- Fixed UI issues in table with groups action rows (load more and create
new)
- Started fixing z-index issues on record table with groups (some left
to do)
# Introduction
Initially this PR was about introducing integration coverage for view
field v2 tests
But feature itself wasn't finished, so ended up in a TDD style
devlopment
## The new orchestrator
Orchestrator will organize each flat entity diffing inferring either
validation errors or actions sequentially.
A new builder has been introduced when extended requires to define flat
entity validation utils and action generation for `delete` `update`
`create` operations. It's highly typed using generics
## View field integration testing
Introduce coverage on failing basic tests cases for view field
operations, successfull create is also covered. We could still add more
coverage, will be done later in following PRs
## Remaining tasks for upcoming PRs:
- [ ] rename builder methods names to add generate action in their names
- [x] refactor view validation to handle field and view uniqueness index
combination
- [ ] implem strict update validator on view and view field
- [ ] dynamic cache invalidation post run
- [ ] Add coverage to successful and failing view field operations
- [ ] error formatting summary computation
- [ ] extract types out of the workspace entity builder
## Some vision
Currently flat field metadata maps is nested in the flat object metadata
maps, making its build nested too. ( not extending the new generic
builder )
We will refactor this part for both to be stored extra flat such as the
other existing flat entities.
It will require a small refactor to the generic builder that will not
only have impact on the currently built flat entity optimistic cache but
to an other one ( for example when building a create object action it
will also have an impact flat field maps )
