In this PR:
## Improve recompute metadata cache performance. We are aiming for
~100ms
Deleting relationMetadata table and FKs pointing on it
Fetching indexMetadata and indexFieldMetadata in a separate query as
typeorm is suboptimizing
## Remove caching lock
As recomputing the metadata cache is lighter, we try to stop preventing
multiple concurrent computations. This also simplifies interfaces
## Introduce self recovery mecanisms to recompute cache automatically if
corrupted
Aka getFreshObjectMetadataMaps
## custom object resolver performance improvement: 1sec to 200ms
Double check queries and indexes used while creating a custom object
Remove the queries to db to use the cached objectMetadataMap
## reduce objectMetadataMaps to 500kb
<img width="222" alt="image"
src="https://github.com/user-attachments/assets/2370dc80-49b6-4b63-8d5e-30c5ebdaa062"
/>
We used to stored 3 fieldMetadataMaps (byId, byName, byJoinColumnName).
While this is great for devXP, this is not great for performances.
Using the same mecanisme as for objectMetadataMap: we only keep byIdMap
and introduce two otherMaps to idByName, idByJoinColumnName to make the
bridge
## Add dataloader on IndexMetadata (aka indexMetadataList in the API)
## Improve field resolver performances too
## Deprecate ClientConfig
In morph relation pickers, we were not taking into account permissions
when computing the list of objects to search for, while we should not
search for objects we don't have read permissions on (permission denied
error)
- id field should only be available for search records action
- create record action does not work for relations. Requires to send
`accountOwner: { id: string }` instead of `accountOwner: string`
- hidding `runs` for version views as we did for workflows
# Introduction
Greater than filtering wasn't inclusive whereas lower than was,
resulting in sending empty array to filtering resolver
Also refactored the transpilation methods to avoid asserting on the
`RATING_VALUES` order
closes https://github.com/twentyhq/twenty/issues/12779
Export to PDF was throwing an error due to fonts not being registered.
Maybe linked to the async loading changes or blocknote upgrades.
I wasn't a fan of hardcoding the fonts here (makes a second source of
truth for Inter), but after a few tests this seemed like the best
compromise
Let's introduce an object-limited role for Tim, to test and/or spot
incompatibilities with restricted permissions in the future.
Our main user tim@apple.dev is now assigned a role that has all settings
permissions, and all object permissions except for update on Pets (to
test read-only view) and read on Rockets.
Since we still need an admin user for each workspace we are introducing
a new member, Jane, who has the admin role
---------
Co-authored-by: Félix Malfait <felix@twenty.com>
Fixes:
- Trigger labels have been updated in the workflows
- Workflow runs are now opened by default in the side panel when
launched manually by the user
We were using a global ValidationPipe in main.ts. This is an issue as
@Controllers should return HttpExecption and @Resolvers should return
GraphqlErrors
Removing the global pipe and creating a ResolverValidationPipe able to
generate GraphqlError. We also need to handle the exception in a filter
to avoid nest to think it's unhandled and make it flow to logs
Next step:
- it would be nice to have both @UsePipes(ResolverValidationPipe) +
@UseFilters(GraphqlValidationExceptionFilter) come together. This should
be possible if we create a @GraphQLResolver annotation
## Introduction
For a custom object if the selected identifier field metadata is an
number type than it wouldn't get be converted to a string
#closes https://github.com/twentyhq/twenty/issues/12717
## Concerns
Kinda the same than for https://github.com/twentyhq/twenty/pull/12728
Here ObjectRecord unknown fields are typed as any, we might wanna do a
poc in order to migrate to `unknown` usage
```ts
import { BaseObjectRecord } from '@/object-record/types/BaseObjectRecord';
export type ObjectRecord = Record<string, any> & BaseObjectRecord;
```
Test was flaky because sometimes a calendar event is associated to an
account which the user does not have access to
Removing the snapshot to test the exact response value but the test is
still there (more flexible)
Test:
- On upload > No dialog at modal closing
- On match > Confirm cancel dialog at closing (escape, click outside,
cancel cross)
- On match > Restart dialog at Restart Import
- On validation > Confirm cancel dialog at closing (escape, click
outside, cancel cross)
- On import > Confirm cancel dialog at closing (escape, click outside,
cancel cross)
- On import > No confirm at import end
closes : https://github.com/twentyhq/core-team-issues/issues/1071
In order to put back relations on track, we need to allow the
preexisting indexes to be created in indexmetadata, but also to avoid
failure when the migration runner will try to re-apply a pre-existing
index
## Context
- Whole row is now clickable
- Fix padding on role tables
- Fix tab being persistant between roles
- Change various texts/descriptions
- Add un/check all on settings permissions
- Fix flash between role detail and roles
- Add "Granted for X object(s)"
- Swap permissions and assignment tabs position
- add tooltip for object level permission actions
- Add the inherited info on object-level permissions
- Introduced `createCaptchaRefreshLink` to trigger captcha token refresh
automatically.
- Removed redundant manual captcha refresh calls and integrated it into
Apollo Provider.
- Fix an issue where custom object were seeded with 2 views, and with
the wrong icon
- ACME becomes YCombinator
- Allow 2 workspaces to have different metadata seeded
- Add many seeds for messages
- Add many seeds for calendar events
- Randomize createdBy for person and companies
---------
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
Sometimes, we try to set the viewport, but the nodes' dimensions have
been reset. Trying to set the viewport when the nodes' dimensions are
incorrect leads to an incorrect viewport.
This PR ensures we only try to set the viewport if the nodes' dimensions
are valid. Otherwise, we wait for them to be computed to set the
viewport automatically.
The `handleNodesChanges` function is called every time the nodes change,
including when the dimensions have been computed.
Internally, Reactflow has a similar behavior to implement the `fitView`
feature:
f9971a8fad/packages/react/src/store/index.ts (L111).
## Example
This is more notable since I added optimistic rendering to workflow
runs.
https://github.com/user-attachments/assets/07232050-b808-4345-b82b-95acad72ab15
Workflow views and versions are seed being opened by default into record
page. Issue is that:
- new views are set by default to side panel. Updated by copying the
current opensIn value to the new view
- users can still select side panel into their options. Disabling the
button.
<img width="650" alt="Capture d’écran 2025-06-19 à 16 15 34"
src="https://github.com/user-attachments/assets/0ddc3284-0fed-404f-9c1d-225c65549fd1"
/>
# Introduction
This migration has been introduced in 0.54 we should determine how we
wanna handle retro-compatibility with this, might not wanna merge this
one latest main 🤔 but only a new 0.54 patch
related to
https://github.com/twentyhq/twenty/issues/12651#issuecomment-2988164122
## Concerns
If a workspace fails this migration that's not a good sign, the metadata
schema should be completely empty since 0.54 `metadata` merge into
`core` migration.
Please review you existing entries in the schema and verify they exists
in the dest `core` one
