# 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.
Pg scan was redundant because historically the workspaceId was
`varchar`, even though below migration won't change that we had a look
to workspaceId col declaration across the codebase
# Introduction
Initially wanted to reactive the test introduced in
https://github.com/twentyhq/twenty/pull/15393, that was failing because
of direct data source access removing all views ( even seeded one )
which was making the test fail
While doing so discovered a lot of issue with the rest API:
- Rest api wasn't consuming the v2 at all
- Rest api wasn't prepared to handle v2 exceptions
- Rest api did not handled unknown exceptions ( timeout )
Refactored the cleanup of each test to follow black box pattern and
avoid test leakage
closes https://github.com/twentyhq/core-team-issues/issues/1606
As discussed in DMS -- overlapping is not a concern since the library
handles the collision and handles overlapping widgets (if created
through api) using the compact type vertical (ie, move the widget
vertically to create space)
To be done in an other PR, move graphql-query-runner handlers in
common-api-query-runner folder (+ renaming + typing improvments)
Fixes :
- totalCount on findMany (Rest)
- getAllSelectedFields did not handle composite field (Rest)
- issue with endCursor (Rest)
- args processing for updateOne and createOne (Rest + Gql)
- fix findDuplicates (Gql)
Soft deletion events use before in event properties. But we set the
after instead, that only contains a few data.
Fixes https://github.com/twentyhq/twenty/issues/15120
Debugging raised an additional issue. UpdateMany, RestoreMany and
SoftDeleteMany were broken for custom objects. The `where` clause was
using "_objectName.id" instead of "objectName.id" during select. That's
why we need to use different where clause between the select of the
existing value and the actual mutation.
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
2025-10-28 17:13:39 +01:00
Thomas TrompetteGitHubgreptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
When using primitive types such as array, number and boolean, we display
a text field in filters because fieldmetadataId is empty. We should
instead support these as we would do for our own fields.
Adding also a fix for https://github.com/twentyhq/twenty/issues/15282
---------
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
# Introduction
A while ago we migrated view from workspace to metadata
Their standard objects workspace entities declaration remained we can
now remove them
## Deprecating commands before 1.5
The view migration command from workspace to metadata was introduced in
`1.5.0`. Removing the `baseWorkspaceEntity` make this command obsolete.
If tomorrow twenty handles auto upgrade in latest and a user having an
instance in `1.3.0` starts auto-upgrading he won't be able to migrate
his views ( that's why we should not support upgrade before 1.5 anymore
here )
We will have the same use case with FavoritesFolders
Now that all existing and new workspaces have the following syncStage:
- CALENDAR_EVENT_LIST_FETCH_PENDING
- MESSAGE_LIST_FETCH_PENDING
We can fully deprecate the old FULL_CALENDAR_EVENT_LIST_FETCH_PENDING
and PARTIAL_CALENDAR_EVENT_LIST_FETCH_PENDING (full vs partial is now
directly inferred from the presence of a cursor)
# Introduction
Fixing self relation field creation in v2
- When computing related flat field to delete on object metadata
deletion that has self relation fields
- On self relation creation validation name availability not searching
for the relation target field of the current object field if it's the
field being validated
## Coverage
- added CUD integration testing on self relation fields
close https://github.com/twentyhq/twenty/issues/15153
Resolves [Dependabot Alert
289](https://github.com/twentyhq/twenty/security/dependabot/289) and a
couple other alerts.
Removed types for `imapflow` since the package ships them internally
now. `yarn.lock` has major changes due to an upgraded AWS SDK
`@aws-sdk/client-sesv2` which is used by Nodemailer 7.
- No breaking changes were introduced in imapflow and mailparser.
- Nodemailer's breaking change was dropping the legacy SES transport; we
already use the SMTP transport + our own AWS SES client, so nothing else
needs changing.
## Description
Fixes#15348
The Vercel AI SDK serializes tool schemas with a `jsonSchema` wrapper
(`{ jsonSchema: {...} }`), but the Model Context Protocol specification
expects the schema directly (`{ type: 'object', properties: {...} }`).
This was causing MCP clients like Claude Desktop to silently reject all
tool definitions as invalid, leaving users with no available tools.
## Changes
Modified `handleToolsListing()` in `mcp.service.ts` to unwrap the
`jsonSchema` key before returning tools to MCP clients.
## Before
```json
{
"name": "create_company",
"description": "...",
"inputSchema": {
"jsonSchema": {
"type": "object",
"properties": {...}
}
}
}
```
## After
```json
{
"name": "create_company",
"description": "...",
"inputSchema": {
"type": "object",
"properties": {...}
}
}
```
## Testing
Tested with:
- Direct curl request to verify schema format
- Claude Desktop client via mcp-proxy
- Verified tools now appear correctly in MCP clients
## References
- [MCP Tools
Specification](https://modelcontextprotocol.io/specification/2025-06-18/server/tools)
- Related discussion in #12953
Legacy workspaces still hold the old stored expression, which omits
public.unaccent_immutable, so their tsvectors remain accented and can’t
match the new, unaccented queries. Metadata sync doesn’t touch
asExpression, so only a targeted drop/recreate fixes the underlying
column.
In simpler words, the search vector should contain `mader` instead of
`mäder` for the search to work properly. Therefore, this command
regenerates the search vector across every object that uses
`SEARCH_FIELDS_FOR_*`.
Note that dashboard has a searchVector, but breaks the pattern of using
`SEARCH_FIELDS_FOR_DASHBOARD`. If you look at
packages/twenty-server/src/modules/dashboard/standard-objects/dashboard.workspace-entity.ts:116,
the searchVector field is hard-coded as
```
asExpression: `to_tsvector('english', title)`
```
Therefore, the following code snippet.
```
const storedExpression = hasAsExpressionSetting(
searchVectorFieldMetadata.settings,
)
? searchVectorFieldMetadata.settings.asExpression
: undefined;
if (storedExpression) {
return storedExpression;
}
return undefined;
```
It checks whether the searchVector field already carries its own
asExpression value in metadata. If the settings object includes that
string, it returns it so the upgrade can reuse the existing expression
for objects that aren’t in our predefined lists. If not, it returns
undefined, signaling there’s no stored expression to fall back on.
---------
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
Co-authored-by: Félix Malfait <felix@twenty.com>
