# Introduction
Encountering a blocking issue due to legacy upgrade history in staging
due to relation refactor
For the moment ( release 0.53 ) swallowing
@charlesBochet
## How to test
```ts
checkout v0.52.11
yarn
database:reset
checkout 0.53
yarn
build server
migrate
upgrade
```
# Display "Soft-Deleted Workspace Members" in Actor Field Display
Reminder of the issue :
<img width="154" alt="Screenshot 2025-05-07 at 12 11 59"
src="https://github.com/user-attachments/assets/168f8743-2684-4d9a-b1a4-e86bb335f7a4"
/>
- `ActorFieldDisplay` component : display soft-deleted members
- `UserService` includes soft-deleted records when fetching workspace
members. This is the tricky part : do we want that for all workspace
members or maybe i could create another property dedicated to workspace
members and softdeleted ones. To be discussed
Result looks like this (we loose the source and the context in this
impleentation)
<img width="114" alt="Screenshot 2025-05-07 at 12 05 28"
src="https://github.com/user-attachments/assets/3cdddd91-454f-4e96-8d6d-6fe671658945"
/>
Fixes https://github.com/twentyhq/twenty/issues/11870
Another way we could also get into :
We could also, when a workspace user is softDeleted, change the current
implementation : we could avoid to delete the ActorMetadata like
CreatedByName (and context and source) in the "Person" table.
It would look more like this
<img width="111" alt="Screenshot 2025-05-07 at 12 06 16"
src="https://github.com/user-attachments/assets/daa4ece2-200a-41f0-ba24-177375c72983"
/>
However, this implementation is requires more work, and IMO harder to
maintain since is decouples completely the record from the workspace
member. This could be an issue in case we want tohard delete a user, or
decide another logic to display the Actor name.
Since the usecase should be pretty rare, I chose the first one but
willing to discuss it
---------
Co-authored-by: prastoin <paul@twenty.com>
# TLDR
fix bug due to some event properties coming from the google calendar API
containing weird characters like this
"\u0000�4\u000b\u00042��K\u0001�z,\u001cm�",
it made the Postgres select and insert operator fail
## Details
We can have event properties (like cal UID below) encoded in a strange
way. From my research, the character \u0000 comes from `C` language to
signal end of line. It is wrongly interpreted by Postgres so must be
escaped. I decided to remove all possibility of failure with this regex
`[^\x20-\x7E]` basically "any character that is not a printable ASCII
character"
```
[
"5foijj28qb8smqiafjablo17vd@google.com",
"\u0011�\"�f�\\\u0019G_=��\u0005]x",
"?}|��\f}l��+�弴�",
"%���?t\u0007��n\u001e\u000eY�T<",
".\u0011�\u0016�!�\u000eIǹ� ��\u001f",
"!h\u0004��DŽ�6���h�]E",
"(�CX]�Q�7�^��n\u0006�",
"_040000008200E00074C5B7101A82E0080000000070105B958DEFD801000000000000000010000000EA30DB22E888B943A8EE0AD483F8DB35",
"\t�N�#�D��Ic�h",
"+�)�H���jJ|Ժ�'�",
"_040000008200E00074C5B7101A82E0080000000070A54736C6EED8010000000000000000100000006502334AFE61904595C2831FA4391034",
"_040000008200E00074C5B7101A82E0080000000072C80C3590EFD8010000000000000000100000001BA9FD5B330C1A4D85462AC9D70B9D9D",
"sg�fvUa:St>-<�d\u0006",
"\u0017ڦ��_\u001e\u001fGm-1����",
"_040000008200E00074C5B7101A82E00800000000F0F4F01F4EF0D8010000000000000000100000004C11CE0950C85549B79C456C13987AB8",
"$�����\u0007V\u0007��\u001e�OLN",
"_040000008200E00074C5B7101A82E00800000000341DA81151EDD8010000000000000000100000007453CEFB19AA2D4899B17F0BDB000493",
"_01C756CA-98DC-4799-9F06-883A540A065C",
"_040000008200E00074C5B7101A82E00800000000919548BBF1EDD80100000000000000001000000050AE1E41F3CD314CA9215F193EBE1D39",
"_040000008200E00074C5B7101A82E0080000000039CF64D718EDD801000000000000000010000000B3824EF0711436488CB5459BE83733B1",
"_040000008200E00074C5B7101A82E00800000000C50BDADCB5E4D8010000000000000000100000005B95FE762B2EF84B9C5AC53907B7E5E8",
"�Spx�\u0003ve��ss�X��",
"\b���>\u0013̈�ыh��0�",
"_040000008200E00074C5B7101A82E008000000005BCD492230E8D801000000000000000010000000B243A9CE99E94C4DAD201129A8F2A2F7",
"_040000008200E00074C5B7101A82E008000000009B540B82D1DCD801000000000000000010000000B4AFC9825D94994AA6C528C953BD3D96",
"_040000008200E00074C5B7101A82E008000000000D39EABDB7E4D801000000000000000010000000CD07BA2D05E61B47A597EE538ECE8CA5",
"\u0016���\u0003inv�=O����",
"4?b�-���\u001c\u0013ת�E�p",
">\u0000\u0015-;_�^�W&�p\u001f�",
"_040000008200E00074C5B7101A82E008000000006258818C85D9D80100000000000000001000000003346C625768FE43AF3F8D09917CA3C9",
"+K��ٔ�\u0006�\u0018G\u000b\u0000�s\u000e",
"/\f�\rj�IOD�g脅��",
"_68d820f9-e2c1-4d9a-bf61-83e4957c8261",
"xĠ�W4>���t�\u001d���",
"_040000008200E00074C5B7101A82E008000000003F1F314328E3D8010000000000000000100000002C8DC60F5369F44DA2B066441F882B35",
"_040000008200E00074C5B7101A82E008000000006DFCC204FDDED80100000000000000001000000046ECD444737D2E4992C349B2EA05637F",
"_1FF7C1BB-4E1A-485F-ADD0-5C4768601179",
"_040000008200E00074C5B7101A82E00800000000A0AA1223EFD3D801000000000000000010000000C83B72C2B424944199F3353D1442B27E",
"_040000008200E00074C5B7101A82E0080000000063D101EB06E4D801000000000000000010000000E489F61C89B8914BA6F8C8A2606405FE",
"\u0011��f�\"�b���rB�[�",
";t��\u001d\u001euDY+T\u001d��v",
]
```
Fixes https://github.com/twentyhq/core-team-issues/issues/946
Fixes
https://twenty-v7.sentry.io/issues/6568530279/?environment=prod&project=4507072499810304&query=is%3Aunresolved%20issue.priority%3A%5Bhigh%2C%20medium%5D%20b09d7a84-e6bc-45cf-b3ca-1e6047dddeed&referrer=issue-stream&stream_index=0
### Edit :
Changed the regex to match the chars to remove from
`[^\x20-\x7E]` to `replace('\u0000', '');`
## Context
While deploying the IS_NEW_RELATION_ENABLED (we don't compute relation
based on relationMetadata anymore) to existing workspace, I've tested to
run a sync-metadata post feature flag activation. This has raised two
issues:
- the workspaceMigration generator (which is over-complex and should be
refactored later) for fieldMetadata of type RELATION was not handling
settings update properly ;
- we need to delete existing fieldMetadata corresponding to the UUID
foreignKey as they are not needed anymore. This is handled as a 0.53
upgrade command as 0.53 will also come with the full removal of the old
relation system
---------
Co-authored-by: Etienne <45695613+etiennejouan@users.noreply.github.com>
Co-authored-by: prastoin <paul@twenty.com>
This PR adds what's needed to filter on the ADDRESS sub-fields, notably
the country sub-field, that requires a country multi select component,
which was created in this PR (ObjectFilterDropdownCountrySelect)
This PR refactors the common logic between advanced filter dropdown
field selection logic and view bar filter dropdown field selection
logic, notably in useFilterDropdownSelectableFieldMetadataItems.
There are now new components to identify clearly what's tied to view bar
or advanced filter, it could be further simplified or factorized, but as
it is right now, it's simple enough to be maintained easily even if a
little bit too verbose, which is often the best trade-off we should aim
for.
Improvements :
- Added the CompositeFieldSubFieldName where needed
- Fixes bug in advanced filter dropdown input
- Fixes dropdown content width bug in advanced filter dropdown input
- Fixes a bug when inputing a Currency filter without a sub-field in
view bar filter dropdown
- Used DropdownMenuSearchInput instead of a custom StyledInput which was
doing exactly the same thing
- Factorized the state setting logic in
useSetAdvancedFilterDropdownStates in an anonymous function
setAdvancedFilterDropdownStates
- Created useSelectFilterFromViewBarFilterDropdown hook to have a more
meaningful and clear logic to abstract what happens when we select a
field to filter in the view bard field select dropdown
- Fixes a bug with advanced filter operand dropdown select which wasn't
modifying the current record filter and creating a stale state.
Fixes https://github.com/twentyhq/core-team-issues/issues/612
## Architecture Detail
The goal is to merge the two TypeORM schemas.
Having two schemas prevent doing things like fieldMetadata.workspace in
TypeORM, and create useless debates since there is no clear line (is a
serverlessFunction core or metadata? What about events? etc.)
### Before
```
┌───────────────────┐ ┌───────────────────┐
│ core schema │ │ metadata schema │
├───────────────────┤ ├───────────────────┤
│- User │ │- ObjectMetadata │
│- Workspace │ │- FieldMetadata │
│- UserWorkspace │ │- RelationMetadata │
│- etc. │ │- etc. │
└───────────────────┘ └───────────────────┘
```
### After the Migration
```
┌───────────────────────────────────────────┐
│ engine schema │
├───────────────────────────────────────────┤
│- User - ObjectMetadata │
│- Workspace - FieldMetadata │
│- UserWorkspace - RelationMetadata │
│- etc. - etc. │
└───────────────────────────────────────────┘
```
## Strategy
1. During 0.53 we backfill the *_typeorm_migrations* table of the core
schema with all metadata migrations
2. That way in 0.54 we can move the metadata migrations from the
metadata folder to the core folder. We will also edit the migration
files to reference "core" instead of "metadata". For people doing a
fresh install this will run smoothly and create the tables in Core
directly. For people on an existing install, this migrations will not
run because they were added to the *_typeorm_migrations* in 0.53
3. In 0.55 we will rename "core" to something else (for example
"engine")
Note: if someone jumps version, for example skips to 0.54 directly
without having run 0.53 then this could cause issue. In 0.54 we should
consider gating the "migrate:prod" in the docker file so that it's
controlled and run by the upgrade command (and not run if the command
wasn't executed properly)
# Introduction
From my understand we're kinda hacking through the options parser by
defining class properties within them whereas we should be consuming the
return type value ? Have no time for this right now
Anw for some reason nestjs-commander enters several time the option
parse which result in duplicating the given workspaceId in the array
Added a Set to fix
close https://github.com/twentyhq/twenty/issues/11707
# Introduction
This PR refactors the way we previously manually handled the upgrade
command `versionTo` and `versionFrom` values to be replaced by a
programmatic inferring using the `APP_VERSION` env variable. It raises
new invariant edge cases that are covered by new tests and so on
Please keep in mind that an upgrade will run agnostically of any `patch`
semver value as it should be done only when releasing a `major/minor`
version update
[Related discord
thread](https://discord.com/channels/1130383047699738754/1368953221921505280)
## Testing in local
In order to test in local we have to define an `APP_VERSION` value in
`packages/twenty-server/.env` following semver ( or not 🙃 )
## Logs example
```ts
Computing new Datasource for cacheKey: 20202020-1c25-4d02-bf25-6aeccf7ea419-8 out of 0
query: SELECT * FROM current_schema()
query: SELECT version();
[Nest] 37872 - 05/06/2025, 4:07:21 PM LOG [UpgradeCommand] Initialized upgrade context with:
- currentVersion (migrating to): 0.53.0
- fromWorkspaceVersion: 0.52.0
- 2 commands
[Nest] 37872 - 05/06/2025, 4:07:21 PM LOG [UpgradeCommand] Upgrading workspace 20202020-1c25-4d02-bf25-6aeccf7ea419 from=0.52.0 to=0.53.0 1/2
[Nest] 37872 - 05/06/2025, 4:07:21 PM LOG [UpgradeCommand] Upgrade for workspace 20202020-1c25-4d02-bf25-6aeccf7ea419 ignored as is already at a higher version.
[Nest] 37872 - 05/06/2025, 4:07:21 PM LOG [UpgradeCommand] Running command on workspace 3b8e6458-5fc1-4e63-8563-008ccddaa6db 2/2
Computing new Datasource for cacheKey: 3b8e6458-5fc1-4e63-8563-008ccddaa6db-8 out of 0
query: SELECT * FROM current_schema()
query: SELECT version();
[Nest] 37872 - 05/06/2025, 4:07:21 PM LOG [UpgradeCommand] Upgrading workspace 3b8e6458-5fc1-4e63-8563-008ccddaa6db from=0.52.0 to=0.53.0 2/2
[Nest] 37872 - 05/06/2025, 4:07:21 PM LOG [UpgradeCommand] Upgrade for workspace 3b8e6458-5fc1-4e63-8563-008ccddaa6db ignored as is already at a higher version.
[Nest] 37872 - 05/06/2025, 4:07:21 PM LOG [UpgradeCommand] Command completed!
```
## Misc
Related to https://github.com/twentyhq/twenty/issues/11780
In this PR we are
1. cleaning typeORM service by removing connectToDataSource method
2. using workspaceDataSource instead of mainDataSource when possible,
and replacing raw SQL with workspaceRepository methods to use
First and main step of
https://github.com/twentyhq/core-team-issues/issues/747
We are implementing a permission check layer in our custom
WorkspaceEntityManager by overriding all the db-executing methods (this
PR only overrides some as a POC, the rest will be done in the next PR).
Our custom repositories call entity managers under the hood to interact
with the db so this solves the repositories case too.
This is still behind the feature flag IsPermissionsV2Enabled.
In the next PR
- finish overriding all the methods required in WorkspaceEntityManager
- add tests
- enrich response so the record is available in the step output. Today
this is available in the schema but only the id is set
- make the full record picker clickable instead of the arrow only
<img width="467" alt="Capture d’écran 2025-04-30 à 16 08 04"
src="https://github.com/user-attachments/assets/db74b9a6-7f1d-4e54-bf06-9be3d67ee398"
/>
Preview :
<img width="501" alt="Screenshot 2025-05-02 at 16 24 34"
src="https://github.com/user-attachments/assets/0c649df1-0e26-4ddc-8e13-ebd78af7ec09"
/>
Done :
- Fix getCalendarEventsFromPersonIds and getCalendarEventsFromCompanyId
(include accountOwner check)
- Fix permission check on pre-hook - Pre-hook seems useless, calendar
events are always on METADATA or SHARE_EVERYTHING visibility, else post
hook always has the responsibility of returning the data user can
access. >> To delete or to keep in case other visibility options are
added ?
- Add post hook to secure finOne / findMany calendarEvents resolver
- Update design
To do :
- same on messages (PR to arrive)
closes : https://github.com/twentyhq/twenty/issues/9826
No need to audit log workflow runs as it's already a form of audit log.
Add more audit log for other objects
Rename MessagingTelemetry to MessagingMonitoring
Merge Analytics and Audit in one (Audit)
---------
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
isEmailVerified was set to false which was annoying in the staging
environment
Also updated password for tim@apple.dev from AppleCar2025 to just
tim@apple.dev since the joke is outdated
# Introduction
Followup of https://github.com/twentyhq/twenty/pull/11784
Again some propaganda for the
[noUncheckedIndexedAccess](https://www.typescriptlang.org/tsconfig/#noUncheckedIndexedAccess)
that involved this @charlesBochet 👀
That's very risky to have this setup to false especially in the backend
regarding the twenty-server metadata nature
Also suggested that we do some integration testing ( e2e nestsJs tests )
on a related endpoint that could related we always retrieve the same
form result output
We could also do some unit testing of the method but like the idea to
ship it through the api itself
Twenty prod DB has been exported for testing.
Main updates:
- do not process workflow runs with less than 2 steps. Nothing to do.
- update runs by batches of 500. Will avoid java heap space issue
- add more logs
parseBatchResponse:
we need more logs to understand why we have some empty repsonse in the
body.
For anothe PR:
~~UNKNOWN_NETWORK_ERROR : moving from handleUnknownException to
handleTemporaryException. This is important since in the logs I saw "The
service is currently unavailable" which makes me think we should handle
this type of error with as temporary~~
In this PR:
- this should fix the sync metadata for new relation system
This goes with the recent PR:
https://github.com/twentyhq/twenty/pull/11725
What we want:
- ONE_TO_MANY relations should have no joinColumn and no onDelete
- MANY_TO_ONE should have both
