4b2a604ef08061ce28a34ab16ff959dd4783fc70
670
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
083a038f8a | Deprecate workspace datasoure (#16507) | ||
|
|
f06a5ccacd |
Remove sync metadata from upgrade (#16491)
# Introduction Related https://github.com/twentyhq/core-team-issues/issues/1910 From now on the upgrade won't integrate any sync metadata as it's going to be deprecated very soon Any updates to about to removes workspace-entity or standard flat entity will require a dedicated upgrade command, what we've already started doing during the 1.13 sprint, until we have totally migrated the v2 to be workspace agnostic |
||
|
|
b83dc3aaff |
TimelineActivity migration to morph (#15652)
# TimelineActivity migration to morph - Creates `timelineActivities2` relations on Company, Dashboard, Note, Opportunity, Person, Task, Workflow, WorkflowRun, and WorkflowVersion entities with proper metadata and cascade delete behavior. It was required to create standard fields as well since the mapObjectMetadataByUniqueIdentifier needs it. otherwise the fields won't be considered - Feature Flag `IS_TIMELINE_ACTIVITY_MIGRATED` necessary to have the two states in parallel. It is used as a stamp once the migration has been run - Migration is done using the coreDataSource. Why ? even though is unsafe to use, the first implementation of the migration took forever on each workspace. See [this commit](https://github.com/twentyhq/twenty/pull/15652/commits/477011e8d7d4c580f79ba7ec4a8fb002a3ec86b2) The plan for this complex migration is as follows :  Note: we will need to rename fields in the release 1.12 (there is no easy way to do all this in one release) |
||
|
|
9bd8f94b3a |
Refactor global datasource part 3 (#16447)
## Context Following https://github.com/twentyhq/twenty/pull/16399 Now using the new global orm manager everywhere and returning a GlobalDatasource/WorkspaceDatasource based on a feature flag. This means we now need to wrap all our ORM calls within executeInWorkspaceContext callback (at least for now) so the global datasource can dynamically hydrate its context via the new store (the global datasource does not store anything related to workspaces as it is now a unique singleton). If feature flag is off it still uses local data stored in the workspace datasource. |
||
|
|
1839f8e946 |
Fix: Persist hide empty groups setting on backend (BREAKING: deploy server first) (#16385)
Closes #13754 and [core team issue #414](https://github.com/twentyhq/core-team-issues/issues/414) |
||
|
|
20879c8147 |
Standard views tooling (#16436)
# Introduction In this PR we've introduced the type safe generation tooling for standard view, view fields, view filters and view groups. Also generated the ids before such as what was done for object and fields, it's still temporary as will be replaced by universalIdentifier mapping afterwards ## Task views In this PR only implemented the `task` views and view groups, filters and fields in order to battle test all the generation tools Will create a dedicated PR that will implement all the remaining views. |
||
|
|
7b98804ec1 |
Fix flat field metadata date type (#16445)
# Introduction Following https://github.com/twentyhq/twenty/pull/16420 |
||
|
|
e8d4f11d8e |
Standard index as code introduction + type refactor (#16426)
# Introduction Related https://github.com/twentyhq/core-team-issues/issues/1995 In this PR we're introducing the standard index tools for their declaration Also adding a common typing in order to have a simily consistency across standard builders Will implement remaining standard index builder in an other PR |
||
|
|
4996f3dd28 |
Finalize twenty standard app as workspace migration object and fields (#16353)
# Introduction Related to https://github.com/twentyhq/core-team-issues/issues/1995 In this PR we're fixing the remaining object/fields validation errors resulting from standard objects and fields now passing a validation that wasn't when using the sync metadata ## Key Changes - **Field naming**: Renamed `iCalUID` to `iCalUid` for consistent camelCase convention across calendar events - **Enum standardization**: Uppercased enum values for message channels (email→EMAIL), message participants (from→FROM, to→TO, cc→CC, bcc→BCC), and message direction (incoming→INCOMING, outgoing→OUTGOING) - **Label simplification**: Removed example values from workspace member number format labels for cleaner UI - **Migration infrastructure**: Added `isSystemBuild` flag throughout field metadata service pipeline to allow system-level updates of standard fields that bypass normal restrictions ## Migrating the existing data We've created an upgrade command that will identify using the existing object and field standard id field that needs to be updated, even though the sync metadata still in usage could have fix them ( and the goal is to deprecate it by the end of the sprint ) We will call the updateOneField for each of them, we're passing by the field service in order to battle test what are going to be the temporary way to handle standard migrations when we will start deprecating the sync metadata but haven't still refactored the v2 workspace migration to be workspace agnostic ## Twenty eng migration Tested the whole migration + upgrade on twenty eng Here are generated workspace migration Records are handled natively gracefully too ### ICalUid ```json { "status": "success", "workspaceMigration": { "relatedFlatEntityMapsKeys": [ "flatFieldMetadataMaps", "flatIndexMaps", "flatViewFilterMaps", "flatViewGroupMaps", "flatViewMaps", "flatViewFieldMaps", "flatObjectMetadataMaps" ], "actions": [ { "type": "update_field", "fieldMetadataId": "", "objectMetadataId": "", "updates": [ { "from": "iCalUID", "to": "iCalUid", "property": "name" } ] } ], "workspaceId": "" } } ``` ### Incoming Outgoing None as already caps in database somehow ```json { "status": "success", "workspaceMigration": { "relatedFlatEntityMapsKeys": [ "flatFieldMetadataMaps", "flatIndexMaps", "flatViewFilterMaps", "flatViewGroupMaps", "flatViewMaps", "flatViewFieldMaps", "flatObjectMetadataMaps" ], "actions": [], "workspaceId": "" } } ``` ### EMAIL ```json { "status": "success", "workspaceMigration": { "relatedFlatEntityMapsKeys": [ "flatFieldMetadataMaps", "flatIndexMaps", "flatViewFilterMaps", "flatViewGroupMaps", "flatViewMaps", "flatViewFieldMaps", "flatObjectMetadataMaps" ], "actions": [ { "type": "update_field", "fieldMetadataId": "", "objectMetadataId": "", "updates": [ { "from": "'email'", "to": "'EMAIL'", "property": "defaultValue" }, { "from": [ { "color": "green", "id": "", "label": "Email", "position": 0, "value": "email" }, { "color": "blue", "id": "", "label": "SMS", "position": 1, "value": "sms" } ], "to": [ { "color": "green", "id": "", "label": "Email", "position": 0, "value": "EMAIL" }, { "color": "blue", "id": "", "label": "SMS", "position": 1, "value": "SMS" } ], "property": "options" } ] } ], "workspaceId": "e" } } ``` ### MessageParticipantRole ```json { "status": "success", "workspaceMigration": { "relatedFlatEntityMapsKeys": [ "flatFieldMetadataMaps", "flatIndexMaps", "flatViewFilterMaps", "flatViewGroupMaps", "flatViewMaps", "flatViewFieldMaps", "flatObjectMetadataMaps" ], "actions": [ { "type": "update_field", "fieldMetadataId": "", "objectMetadataId": "", "updates": [ { "from": "'from'", "to": "'FROM'", "property": "defaultValue" }, { "from": [ { "color": "green", "id": "", "label": "From", "position": 0, "value": "from" }, { "color": "blue", "id": "", "label": "To", "position": 1, "value": "to" }, { "color": "orange", "id": "", "label": "Cc", "position": 2, "value": "cc" }, { "color": "red", "id": "", "label": "Bcc", "position": 3, "value": "bcc" } ], "to": [ { "color": "green", "id": "", "label": "From", "position": 0, "value": "FROM" }, { "color": "blue", "id": "", "label": "To", "position": 1, "value": "TO" }, { "color": "orange", "id": "", "label": "Cc", "position": 2, "value": "CC" }, { "color": "red", "id": "", "label": "Bcc", "position": 3, "value": "BCC" } ], "property": "options" } ] } ], "workspaceId": "" } } ``` ### Workspace member number format labels ```json { "status": "success", "workspaceMigration": { "relatedFlatEntityMapsKeys": [ "flatFieldMetadataMaps", "flatIndexMaps", "flatViewFilterMaps", "flatViewGroupMaps", "flatViewMaps", "flatViewFieldMaps", "flatObjectMetadataMaps" ], "actions": [ { "type": "update_field", "fieldMetadataId": "", "objectMetadataId": "", "updates": [ { "from": [ { "color": "turquoise", "id": "", "label": "System", "position": 0, "value": "SYSTEM" }, { "color": "blue", "id": "", "label": "Commas and dot (1,234.56)", "position": 1, "value": "COMMAS_AND_DOT" }, { "color": "green", "id": "", "label": "Spaces and comma (1 234,56)", "position": 2, "value": "SPACES_AND_COMMA" }, { "color": "orange", "id": "", "label": "Dots and comma (1.234,56)", "position": 3, "value": "DOTS_AND_COMMA" }, { "color": "purple", "id": "", "label": "Apostrophe and dot (1'234.56)", "position": 4, "value": "APOSTROPHE_AND_DOT" } ], "to": [ { "color": "turquoise", "id": "", "label": "System", "position": 0, "value": "SYSTEM" }, { "color": "blue", "id": "", "label": "Commas and dot", "position": 1, "value": "COMMAS_AND_DOT" }, { "color": "green", "id": "", "label": "Spaces and comma", "position": 2, "value": "SPACES_AND_COMMA" }, { "color": "orange", "id": "", "label": "Dots and comma", "position": 3, "value": "DOTS_AND_COMMA" }, { "color": "purple", "id": "", "label": "Apostrophe and dot", "position": 4, "value": "APOSTROPHE_AND_DOT" } ], "property": "options" } ] } ], "workspaceId": "" } } ``` |
||
|
|
be91d870f9 | Fix - revert standard sync logic on index + fix command (#16421) | ||
|
|
07cfaa78ef |
Fix unique standard field (#16371)
Fixes https://github.com/twentyhq/twenty/issues/15925 - update field metadata update logic - uniformize the way index are named - command to migrate v1-named unique index - add integration testing --------- Co-authored-by: prastoin <paul@twenty.com> |
||
|
|
5fb7e76005 | Migrate page layout to v2 (#16364) | ||
|
|
7f1e69740a |
1895 extensibility v1 application tokens (#16365)
First PR to implement application tokens - add new application role in twenty-server - move duplicated constants and types to twenty-shared - will add role configuration utils into twenty-sdk in another PR |
||
|
|
3e57aa14d3 |
Refactor page layout tab and widgets migration (#16367)
# Introduction Making columns nullable instead of required + metadata on the fly migration in typeorm migration that could affect other breaking change migrations to be run |
||
|
|
077be7644c | Migrate page layout widget to v2 of the API (#16323) | ||
|
|
28cdb02fbb |
Twenty standard application Objects and fields as allFlatEntityMaps ID non-agnostic (#16298)
# Introduction Related to https://github.com/twentyhq/core-team-issues/issues/1995 This PR introduces the basis of the `twentyStandard` application as code on demand, it's highly tied to `ids` where it will becomes workspace agnostic following the builder and runner `universalIdentifier` refactor later. The goal here to allow computing the `allFlatEntityMaps` `to` of the `twentyStandard` application on a empty workspace ( workspace creation ). Allowing installing the twenty standard app through a workspace migration instead of passing by the sync metadata Nothing done will be run in production for the moment if it's not the small validation refactor we've introduced Please note that everything introduced here will be replaced at some point by a twenty app instance when the twenty sdk is mature enough to handle of the edge cases we need here ## How we've proceeded We've been iterating over every workspace entity both objects and their fields, and transpiled them to flatEntity. Being sure we migrate the defaultValue, settings and so on accordingly. We've also compute all the ids in prior of the whole entities computation so we don't face any hoisting issue. ## Current state At the moment only handling all of the 29 standard objects and their fields Settings a unique universalIdentifier for all of them Will come views, agent role targets and so on later ## `workspace:compute-twenty-standard-migration` command This command allow generating a workspace migration that will result in installing the twenty standard app in an empty workspace It's temporary and aims to allow debugging for the moment we might not keep it in the future as it is right now It contains debug writeFileSync which is expected no worries greptile ## `LabelFieldMetadataIdentifierId` Small refactor allowing defining the label identifier field metadata id of a uuid field metadata type for system object, as some of our standard object don't have a name field and don't aim to Also please note that we might remove this build options later in the sake of the currently installed universal identifier application that we could compare with the deterministic twenty standard one ## `runFlatFieldMetadataValidators` Deprecated this pattern which was redundant and not v2 friendly pattern ## Current errors that will address in upcoming PR Current standard objects and fields metadata does not pass the validation that we have in place, as historically the sync metadata would directly consume the repositories and would just ignore the validation. This is about to change. Will handle the below errors in dedicated PRs as they will required upgrade commands in order to migrate the data, or will handle that from the sync metadata instead still to be determined but nothing critical here - camel case field metadata name - options label invalid format ```json { "status": "fail", "report": { "fieldMetadata": [ { "status": "fail", "errors": [ { "code": "INVALID_FIELD_INPUT", "message": "Name should be in camelCase", "userFriendlyMessage": { "id": "P+jdmX", "message": "Name should be in camelCase" }, "value": "iCalUID" } ], "flatEntityMinimalInformation": { "id": "68dd83cd-92c8-4233-bb28-47939bab6124", "name": "iCalUID", "objectMetadataId": "11c16ab6-9176-439e-a2db-a12c5a58a524" }, "type": "create_field" }, { "status": "fail", "errors": [ { "code": "INVALID_FIELD_INPUT", "message": "Value must be in UPPER_CASE and follow snake_case \"email\"", "userFriendlyMessage": { "id": "UBPzFQ", "message": "Value must be in UPPER_CASE and follow snake_case \"{sanitizedValue}\"", "values": { "sanitizedValue": "email" } }, "value": "email" }, { "code": "INVALID_FIELD_INPUT", "message": "Value must be in UPPER_CASE and follow snake_case \"sms\"", "userFriendlyMessage": { "id": "UBPzFQ", "message": "Value must be in UPPER_CASE and follow snake_case \"{sanitizedValue}\"", "values": { "sanitizedValue": "sms" } }, "value": "sms" } ], "flatEntityMinimalInformation": { "id": "e3caaf2a-e07d-4146-8dfc-9eef904e82c9", "name": "type", "objectMetadataId": "4b777de5-4c7b-4af4-9b92-655c0f87512b" }, "type": "create_field" }, { "status": "fail", "errors": [ { "code": "INVALID_FIELD_INPUT", "message": "Value must be in UPPER_CASE and follow snake_case \"incoming\"", "userFriendlyMessage": { "id": "UBPzFQ", "message": "Value must be in UPPER_CASE and follow snake_case \"{sanitizedValue}\"", "values": { "sanitizedValue": "incoming" } }, "value": "incoming" }, { "code": "INVALID_FIELD_INPUT", "message": "Value must be in UPPER_CASE and follow snake_case \"outgoing\"", "userFriendlyMessage": { "id": "UBPzFQ", "message": "Value must be in UPPER_CASE and follow snake_case \"{sanitizedValue}\"", "values": { "sanitizedValue": "outgoing" } }, "value": "outgoing" } ], "flatEntityMinimalInformation": { "id": "d96233a4-93be-45ea-9548-3b50f3c700cf", "name": "direction", "objectMetadataId": "480a648a-d2e5-482a-992f-ef053e1b4bb0" }, "type": "create_field" }, { "status": "fail", "errors": [ { "code": "INVALID_FIELD_INPUT", "message": "Value must be in UPPER_CASE and follow snake_case \"from\"", "userFriendlyMessage": { "id": "UBPzFQ", "message": "Value must be in UPPER_CASE and follow snake_case \"{sanitizedValue}\"", "values": { "sanitizedValue": "from" } }, "value": "from" }, { "code": "INVALID_FIELD_INPUT", "message": "Value must be in UPPER_CASE and follow snake_case \"to\"", "userFriendlyMessage": { "id": "UBPzFQ", "message": "Value must be in UPPER_CASE and follow snake_case \"{sanitizedValue}\"", "values": { "sanitizedValue": "to" } }, "value": "to" }, { "code": "INVALID_FIELD_INPUT", "message": "Value must be in UPPER_CASE and follow snake_case \"cc\"", "userFriendlyMessage": { "id": "UBPzFQ", "message": "Value must be in UPPER_CASE and follow snake_case \"{sanitizedValue}\"", "values": { "sanitizedValue": "cc" } }, "value": "cc" }, { "code": "INVALID_FIELD_INPUT", "message": "Value must be in UPPER_CASE and follow snake_case \"bcc\"", "userFriendlyMessage": { "id": "UBPzFQ", "message": "Value must be in UPPER_CASE and follow snake_case \"{sanitizedValue}\"", "values": { "sanitizedValue": "bcc" } }, "value": "bcc" } ], "flatEntityMinimalInformation": { "id": "961c598e-67c3-452d-8bb2-b92c0bc64404", "name": "role", "objectMetadataId": "8af8a13c-ff97-4cd3-b70d-52a7dc2924b4" }, "type": "create_field" }, { "status": "fail", "errors": [ { "code": "INVALID_FIELD_INPUT", "message": "Label must not contain a comma", "userFriendlyMessage": { "id": "k731jp", "message": "Label must not contain a comma" }, "value": "Commas and dot (1,234.56)" }, { "code": "INVALID_FIELD_INPUT", "message": "Label must not contain a comma", "userFriendlyMessage": { "id": "k731jp", "message": "Label must not contain a comma" }, "value": "Spaces and comma (1 234,56)" }, { "code": "INVALID_FIELD_INPUT", "message": "Label must not contain a comma", "userFriendlyMessage": { "id": "k731jp", "message": "Label must not contain a comma" }, "value": "Dots and comma (1.234,56)" } ], "flatEntityMinimalInformation": { "id": "7fa20caf-2597-42e3-84e5-15a91b125b9b", "name": "numberFormat", "objectMetadataId": "a6974302-9e72-461c-aa09-9390f4ff16fc" }, "type": "create_field" } ], "objectMetadata": [], "view": [], "viewField": [], "viewGroup": [], "index": [], "serverlessFunction": [], "cronTrigger": [], "databaseEventTrigger": [], "routeTrigger": [], "viewFilter": [], "role": [], "roleTarget": [], "agent": [] } } ``` |
||
|
|
b2d785de4b |
Page layout tab v2 (#16319)
# Introduction Migrating `pageLayoutTab` to the v2 engine - Types and constants - Builder and validate - Runner Introduced a new `StrictSyncableEntity` that enforces that `universalIdentifier` and `applicationId` are defined As these entities are brand new we could enforce this rule already This still requires a migration command to associate the existing entities to custom workspace application instance and define universalIdentifier Handled retro-comp of the migration through a migration as upgrade command fallback --------- Co-authored-by: bosiraphael <raphael.bosi@gmail.com> |
||
|
|
2f36c2e82e |
[Dashboards] Server: Rich Text Widget (#16296)
closes https://github.com/twentyhq/core-team-issues/issues/1893 sync in the transformation layer - with just the blocknote format - <img width="1532" height="1058" alt="CleanShot 2025-12-04 at 16 43 27" src="https://github.com/user-attachments/assets/081483fb-0bd0-4f14-81fc-8ea2261367a2" /> with just the mardown format - <img width="1534" height="1056" alt="CleanShot 2025-12-04 at 16 45 03" src="https://github.com/user-attachments/assets/4eae513b-423d-4597-b79c-97d1f33ab994" /> attaching response since in screen shot its getting cut - ``` { "id": "7189a10a-177c-4cc2-8946-950b8c125913", "pageLayoutTabId": "82ac56dd-4351-43ad-bf3d-49624c057e17", "workspaceId": "20202020-1c25-4d02-bf25-6aeccf7ea419", "title": "awdawd awdawdawd", "type": "STANDALONE_RICH_TEXT", "objectMetadataId": null, "gridPosition": { "row": 1, "column": 1, "rowSpan": 1, "columnSpan": 1 }, "configuration": { "body": { "markdown": "# Hello World", "blocknote": "[{\"id\":\"2e744f21-7c71-414d-b87f-fb48400c593c\",\"type\":\"heading\",\"props\":{\"textColor\":\"default\",\"backgroundColor\":\"default\",\"textAlignment\":\"left\",\"level\":1},\"content\":[{\"type\":\"text\",\"text\":\"Hello World\",\"styles\":{}}],\"children\":[]}]" } }, "createdAt": "2025-12-04T11:14:52.212Z", "updatedAt": "2025-12-04T11:14:52.212Z", "deletedAt": null } ``` |
||
|
|
3e75e39650 |
Upgrade command remove duplicated role target (#16281)
# Introduction
On production facing a migration error with
UpdateRoleTargetsUniqueConstraint1764329720503
```ts
Migration "UpdateRoleTargetsUniqueConstraint1764329720503" failed, error: could not create unique index "IDX_ROLE_TARGETS_UNIQUE_AGENT"
query: ROLLBACK
Error during migration run:
QueryFailedError: could not create unique index "IDX_ROLE_TARGETS_UNIQUE_AGENT"
at PostgresQueryRunner.query (/Users/paulrastoin/ws/twenty/node_modules/typeorm/driver/postgres/PostgresQueryRunner.js:219:19)
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
at async UpdateRoleTargetsUniqueConstraint1764329720503.up (/Users/paulrastoin/ws/twenty/packages/twenty-server/dist/database/typeorm/core/migrations/common/1764329720503-update-role-targets-unique-constraint.js:15:9)
at async MigrationExecutor.executePendingMigrations (/Users/paulrastoin/ws/twenty/node_modules/typeorm/migration/MigrationExecutor.js:225:17)
at async DataSource.runMigrations (/Users/paulrastoin/ws/twenty/node_modules/typeorm/data-source/DataSource.js:265:35)
at async Object.handler (/Users/paulrastoin/ws/twenty/node_modules/typeorm/commands/MigrationRunCommand.js:68:13) {
query: 'ALTER TABLE "core"."roleTargets" ADD CONSTRAINT "IDX_ROLE_TARGETS_UNIQUE_AGENT" UNIQUE ("workspaceId", "agentId")',
parameters: undefined,
driverError: error: could not create unique index "IDX_ROLE_TARGETS_UNIQUE_AGENT"
at /Users/paulrastoin/ws/twenty/node_modules/pg/lib/client.js:526:17
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
at async PostgresQueryRunner.query (/Users/paulrastoin/ws/twenty/node_modules/typeorm/driver/postgres/PostgresQueryRunner.js:184:25)
at async UpdateRoleTargetsUniqueConstraint1764329720503.up (/Users/paulrastoin/ws/twenty/packages/twenty-server/dist/database/typeorm/core/migrations/common/1764329720503-update-role-targets-unique-constraint.js:15:9)
at async MigrationExecutor.executePendingMigrations (/Users/paulrastoin/ws/twenty/node_modules/typeorm/migration/MigrationExecutor.js:225:17)
at async DataSource.runMigrations (/Users/paulrastoin/ws/twenty/node_modules/typeorm/data-source/DataSource.js:265:35)
at async Object.handler (/Users/paulrastoin/ws/twenty/node_modules/typeorm/commands/MigrationRunCommand.js:68:13) {
length: 314,
severity: 'ERROR',
code: '23505',
```
As several agent has duplicated role target in database
```sql
SELECT constraint_name, COUNT(*) AS duplicate_groups, SUM(duplicate_count - 1) AS rows_to_delete
FROM (
SELECT 'IDX_ROLE_TARGET_UNIQUE_API_KEY' AS constraint_name, COUNT(*) AS duplicate_count
FROM "core"."roleTargets" rt
WHERE rt."apiKeyId" IS NOT NULL
GROUP BY rt."workspaceId", rt."apiKeyId"
HAVING COUNT(*) > 1
UNION ALL
SELECT 'IDX_ROLE_TARGET_UNIQUE_AGENT', COUNT(*)
FROM "core"."roleTargets" rt
WHERE rt."agentId" IS NOT NULL
GROUP BY rt."workspaceId", rt."agentId"
HAVING COUNT(*) > 1
UNION ALL
SELECT 'IDX_ROLE_TARGET_UNIQUE_USER_WORKSPACE', COUNT(*)
FROM "core"."roleTargets" rt
WHERE rt."userWorkspaceId" IS NOT NULL
GROUP BY rt."workspaceId", rt."userWorkspaceId"
HAVING COUNT(*) > 1
) AS all_duplicates
GROUP BY constraint_name;
```
with constraint name, duplicated_groups, row_to_delete
`IDX_ROLE_TARGET_UNIQUE_AGENT 2507 7229`
Please note that only active or suspended workspaces contains duplicated
role target
## Fix
Introduced an upgrade command that will only keep the latest inserted
role target
Swallowing migration error on typeorm atomic migration ( still required
for self host new instances etc )
```ts
[Nest] 91886 - 12/03/2025, 2:56:28 PM LOG [DeduplicateRoleTargetsCommand] Running command on workspace SOME_WORKSPACE_ID 2587/2587
flatFieldMetadataMaps,flatIndexMaps,flatObjectMetadataMaps out of 298
query: SELECT version();
[Nest] 91886 - 12/03/2025, 2:56:29 PM LOG [DeduplicateRoleTargetsCommand] Command completed!
```
## Test
Tested through an extract in local, tested both the upgrade command and
the swallowed migration
test
|
||
|
|
59672e3e34 |
Migrate agent v2 (#16214)
# Introduction Closes https://github.com/twentyhq/core-team-issues/issues/1980 In this PR we migrate the agent from v1 to v2. ## New FlatRoleTargetByAgentIdMaps Derivated the `flatRoleTargetMaps` to be building a `flatRoleTargetByAgentIdMaps` to ease retrieving a roleId to associate to an agent ## Coverage Added strong coverage on both failing and successful CRU agents operations --------- Co-authored-by: Weiko <corentin@twenty.com> |
||
|
|
a0f196e871 |
Improve workflow throttling logic (#16260)
- if >5000 workflows per hour, new ones should failed - if >100 workflow per min, new ones should be set as not started. Except manual trigger - when enqueued, we check if there a not started workflows that may be queued. If yes, we call the associated job --------- Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com> |
||
|
|
77409b6eb2 |
[Requires "warm" cache flush (no immediate downtime before flush)] Migrate viewGroup.fieldMetadataId -> view.mainGroupByFieldMetadataId (1/3) (#16206)
In this PR (1/3) - introduce view.mainGroupByFieldMetadataId as the new reference determining which fieldMetadataId is used in a grouped view, in order to deprecate viewGroup.fieldMetadataId which creates inconsistencies. view.mainGroupByFieldMetadataId is now filled at every view creation, though not in use yet. - Introduce a command to backfill view.mainGroupByFieldMetadataId for existing views + delete all viewGroup.fieldMetadataId with a fieldMetadataId that is not view.mainGroupByFieldMetadataId. (It should concern 37 active workspaces) - Temporarily disable the option to change a grouped view's fieldMetadataId as for now it creates inconsistencies. This feature can be reintroduced when we have done the full migration. In a next PR - (2/3) use view.mainGroupByFieldMetadataId instead of viewGroup.fieldMetadataId. In FE we may keep viewGroup.fieldMetadataId as a state (TBD). View groups will now be created / deleted as a side effect of view's mainGroupByFieldMetadataId update. - (3/3) remove viewGroup.fieldMetadataId --------- Co-authored-by: Charles Bochet <charles@twenty.com> |
||
|
|
13e283fc3a | Rename roleTargets -> roleTarget (#16247) | ||
|
|
00e970bdf4 |
Null - Second command - Cleaning remaining empty values (#16241)
Because of [this code I forget to clean](https://github.com/twentyhq/twenty/pull/16217), - __workspace created between 1.12.0 and 1.12.2 (from friday 28 nov PM > monday 1 dec PM)__ have standard objects with empty string default value set on related TEXT type column (but default value null on field metadata) (ex: jobTitle on person) - __custom objects created between 1.12.0 and 1.12.2 (from friday 28 nov PM > monday 1 dec PM)__ have "name" TEXT field with empty string default value set + NOT NULL constraint on column Command cleans data and updates table structure |
||
|
|
68c429a54a | Null equivalence - remove feature flag (#16222) | ||
|
|
9f62188ba6 |
Field and object metadata naming does not refer to v2 (#16187)
Related https://github.com/twentyhq/core-team-issues/issues/1911 |
||
|
|
ea3c5d2d45 |
Migrate role and role target to v2 (#16009)
# Introduction close https://github.com/twentyhq/core-team-issues/issues/1930 close https://github.com/twentyhq/core-team-issues/issues/1929 Migrating role and roleTarget entities to the v2 core engine, allowing v2 caching leverage and allow migrating agent to v2 that needs role target in prior After agent we should be able to pass twenty standard app totally though workspace migration ## Role target assignation Please note that role target have 3 creation entrypoints: - Agent - User workspace - ApiKey Refactored all 3 of them to pass through a new role-target.service.ts that consumes the v2 under the hood. --------- Co-authored-by: Weiko <corentin@twenty.com> |
||
|
|
eb362c6d5f |
Update workspace entities to make all TEXT nullable (#16144)
Follow up on #15926 --------- Co-authored-by: Etienne <45695613+etiennejouan@users.noreply.github.com> Co-authored-by: guillim <guigloo@msn.com> |
||
|
|
ca5bd76c6a |
Null equivalence - migration command (#16018)
Awaiting https://github.com/twentyhq/twenty/pull/15926 approval, before un-drafting it --------- Co-authored-by: prastoin <paul@twenty.com> |
||
|
|
4f20fd35c5 |
feat: Add Agent Evaluation System and Refactor AI Modules (#16111)
## Summary This PR introduces a comprehensive agent evaluation system and refactors the AI module structure for better organization. ## Key Changes ### 🎯 Agent Evaluation System - Added **Agent Turn Evaluation** entities, DTOs, and database schema - New GraphQL mutations: `evaluateAgentTurn` and `runEvaluationInput` - Added `evaluationInputs` field to Agent entity for storing test inputs - New `AgentTurnGraderService` for automatic turn evaluation - Added evaluation UI with new **Evals** and **Logs** tabs in agent detail pages ### 🏗️ Entity & Module Refactoring - Renamed `AgentChatMessage` → `AgentMessage` for clarity - Consolidated chat entities: `AgentMessage`, `AgentTurn`, and `AgentChatThread` - Reorganized AI modules under `ai/` subdirectory structure - Updated imports across codebase to reflect new module paths ### 🤖 New Agents & Roles - Added **Dashboard Builder Agent** for dashboard creation and management - Added **Dashboard Manager Role** with appropriate permissions - Updated role permissions to be more granular (users vs agents vs API keys) ### 🔐 Permission System Updates - Added `HTTP_REQUEST_TOOL` permission flag - Updated Workflow Manager role permissions (restricted tool access) - Enhanced permission flag types to differentiate between user/agent/API key contexts - Added `isRelevantForAgents`, `isRelevantForApiKeys`, `isRelevantForUsers` to permission flags ### 📨 Message Role Enhancement - Added `system` role to `AgentMessageRole` enum (alongside user/assistant) - Updated message handling to support system prompts ### 🎨 UI/UX Improvements - New tabs in agent detail: **Evals** and **Logs** - Added turn detail page: `/ai/agents/:agentId/turns/:turnId` - Fixed text overflow in `SettingsListItemCardContent` - Updated role applicability labels ("Assignable to Workspace Members") ### 🛠️ Technical Improvements - Fixed Zod schema validation for UUID and Date fields (use string validators) - Updated `ToolRegistryService` to properly register HTTP tool with permission flag - Enhanced error handling in agent execution services - Updated database migrations for new entity schema ## Database Migrations - `1764210000000-add-system-role-to-agent-message.ts` - `1764220000000-add-evaluation-inputs-to-agent.ts` - `1764200000000-add-agent-turn-evaluation.ts` - `1764100000000-refactor-agent-chat-entities.ts` ## Testing - [ ] Agent evaluation flow tested - [ ] Dashboard Builder agent tested - [ ] Permission system validated - [ ] UI tabs and navigation tested - [ ] Database migrations run successfully ## Breaking Changes ⚠️ **Entity Rename**: `AgentChatMessage` renamed to `AgentMessage` - GraphQL queries need updating ## Related Issues <!-- Link any related issues here --> ## Screenshots <!-- Add screenshots if applicable --> |
||
|
|
74eab77539 |
Refactor upgrade devx to allow configuring workspaces status to pass over (#16066)
# Introduction We need to be able to create custom workspace application on all workspaces, even pending and ongoing etc Right now the upgrade devx only allows and expect active or suspended workspace to be passed to runOnWorkspace. ## WorkspacesMigrationRunner Created an intermediate class `WorkspacesMigrationRunner` that expect an array `WorkspaceStatus` to be fetched for the current command to be run on The `ActiveOrSuspendedCommandRunner` statically passes both `SUSPENDED` and `ACTIVE`, whereas the create workspace custom application passed all the enum values ## DataSource Workspace that are not fully init don't have a `workspace_schema` so they don't have `dataSource` Made a not very elegant check to see if current workspace we're about to create dataSource on has one historically Which means that dataSource is now optional, it had only one impact on an existing command and the desired devx will become consuming existing services that do not expect dataSource ( or at least yet ) |
||
|
|
b1c03b533f | Fix upgrade command messaging (#16067) | ||
|
|
8455ecc3e8 |
Add import scheduled status to messaging sync (#16058)
We have introduced to new syncStage statuses: `messageChannel.MESSAGES_IMPORT_SCHEDULED` and `calendarChannel.CALENDAR_EVENTS_IMPORT_SCHEDULED` We need to make sure all existing workspaces have it |
||
|
|
e7ebf51e50 |
Replace agent handoff system with planning-based router (#16003)
## Overview This PR replaces the dynamic agent handoff system with a more predictable planning-based router that decides upfront how to handle multi-agent coordination. ## Major Changes ### 🔄 Architecture Shift: Handoffs → Planning **Removed:** - `AgentHandoffEntity` and handoff tracking system - `AgentHandoffService` and `AgentHandoffExecutorService` - Dynamic agent-to-agent transfers during execution - Handoff tool generation and description templates **Added:** - `AiRouterService` with two strategies: `simple` (single agent) and `planned` (multi-agent) - `AgentPlanExecutorService` for executing multi-step plans - Plan validation (cycle detection, dependency resolution) - `UnifiedRouterResult` type with discriminated union ### 🤖 New Standard Agents Added two new specialized agents: - **Researcher Agent**: Web search, fact-finding, competitive intelligence - **Code Agent**: TypeScript function generation for serverless workflows ### 🏗️ Router Refactoring (Latest) Split router responsibilities into focused services: - `AiRouterStrategyDeciderService`: Decides simple vs planned strategy - `AiRouterPlanGeneratorService`: Generates and validates execution plans - `AiRouterService`: Coordinates between services (reduced from 426→275 lines) ### ⚙️ Configuration Improvements - Added `outputStrategy` to agent definitions (`direct` vs `synthesize`) - Removed hardcoded special cases for workflow-builder - Added `plannerModel` field to workspace entity - Increased `MAX_STEPS` from 10 to 25 for complex workflows ### 📝 Agent Prompt Refinements Significantly simplified prompts for better clarity: - Workflow Builder: 51→36 lines - Helper: 49→28 lines - Data Manipulator: Enhanced with sorting guidance ### 🔍 Enhanced Debugging - Plan reasoning and step count in data message parts - Router debug info with token usage tracking - Better logging throughout execution pipeline ## Benefits 1. **Simpler Mental Model**: Router decides upfront vs dynamic transfers 2. **Better Predictability**: Users see the plan before execution 3. **Cleaner Architecture**: SRP with focused services 4. **Configuration Over Code**: Agent behavior via config, not hardcoded logic 5. **Plan Validation**: Catches invalid dependencies and cycles ## Migration Notes - Database migration removes `agentHandoff` table - Adds `plannerModel` column to workspace table - No API breaking changes (agent endpoints unchanged) ## Testing - Integration tests updated to remove handoff dependencies - Agent tool test utilities simplified - Plan validation covered by new logic ## Next Steps (Future PRs) - Parallel execution of independent plan steps - Dynamic re-planning based on results - Plan caching for common routing patterns - Error recovery strategies in plan executor |
||
|
|
439adc6ac0 |
Restore transaction on WorkspaceCustomApplicationIdNonNullable1763977334519 failure (#16032)
# Introduction
When a transaction query fails it gets aborted, even if we catch the js
exception typeorm ack it and fails
By adding a save point we isolate the issue and restore the transaction
🥷
## Through database:migrate:prod
Tested but lost logs
## Upgrade
```ts
➜ twenty-server git:(fix-migration-runner) ✗ npx nx command twenty-server upgrade
✔ 3/3 dependent project tasks succeeded [3 read from cache]
Hint: you can run the command with --verbose to see the full dependent project outputs
———————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
> nx run twenty-server:build [existing outputs match the cache, left as is]
> rimraf dist
> nest build --path ./tsconfig.build.json
> SWC Running...
Successfully compiled: 3747 files with swc (65.82ms)
> nx run twenty-server:command upgrade
query: SELECT * FROM current_schema()
query: SELECT version();
[Nest] 82844 - 11/24/2025, 6:05:11 PM LOG [NestFactory] Starting Nest application...
[Nest] 82844 - 11/24/2025, 6:05:11 PM LOG [InstanceLoader] CommandRootModule dependencies initialized
[Nest] 82844 - 11/24/2025, 6:05:11 PM LOG [InstanceLoader] CommandModule dependencies initialized
// ...
[Nest] 82844 - 11/24/2025, 6:05:11 PM LOG [InstanceLoader] WorkflowApiModule dependencies initialized
[Nest] 82844 - 11/24/2025, 6:05:11 PM LOG [InstanceLoader] AuthModule dependencies initialized
[Nest] 82844 - 11/24/2025, 6:05:11 PM LOG [PgPoolSharedService] Pool sharing will use max 10 connections per pool with 600000ms idle timeout and allowExitOnIdle=true
[Nest] 82844 - 11/24/2025, 6:05:11 PM LOG [PgPoolSharedService] pg.Pool patched successfully by this service instance.
[Nest] 82844 - 11/24/2025, 6:05:11 PM LOG [PgPoolSharedService] Pg pool sharing initialized - pools will be shared across tenants
[Nest] 82844 - 11/24/2025, 6:05:11 PM DEBUG [PgPoolSharedService] No active pg pools to log stats for
[Nest] 82844 - 11/24/2025, 6:05:11 PM DEBUG [PgPoolSharedService] Pool statistics logging enabled (30s interval)
[Nest] 82844 - 11/24/2025, 6:05:11 PM LOG [PgPoolSharedService] Created new shared pg Pool for key "localhost|5432|postgres||no-ssl" with 10 max connections and 600000 ms idle timeout. Total pools: 1
[Nest] 82844 - 11/24/2025, 6:05:11 PM DEBUG [PgPoolSharedService] Pool[localhost|5432|postgres||no-ssl]: New connection established
[Nest] 82844 - 11/24/2025, 6:05:11 PM DEBUG [PgPoolSharedService] Pool[localhost|5432|postgres||no-ssl]: Client acquired from pool
[Nest] 82844 - 11/24/2025, 6:05:11 PM DEBUG [PgPoolSharedService] Pool[localhost|5432|postgres||no-ssl]: Client acquired from pool
[Nest] 82844 - 11/24/2025, 6:05:11 PM DEBUG [PgPoolSharedService] Pool[localhost|5432|postgres||no-ssl]: Client acquired from pool
[Nest] 82844 - 11/24/2025, 6:05:11 PM LOG [DatabaseConfigDriver] [INIT] Loading initial config variables from database
[Nest] 82844 - 11/24/2025, 6:05:11 PM LOG [DatabaseConfigDriver] [INIT] Config variables loaded: 0 values found in DB, 59 falling to env vars/defaults
[Nest] 82844 - 11/24/2025, 6:05:11 PM LOG [UpgradeCommand] Initialized upgrade context with:
- currentVersion (migrating to): 1.12.0
- fromWorkspaceVersion: 1.11.0
- 3 commands
[Nest] 82844 - 11/24/2025, 6:05:11 PM LOG [UpgradeCommand] Running global database migrations
[Nest] 82844 - 11/24/2025, 6:05:11 PM LOG [UpgradeCommand] Running core datasource migrations...
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [UpgradeCommand] query: SELECT * FROM current_schema()
query: CREATE EXTENSION IF NOT EXISTS "uuid-ossp"
query: SELECT version();
query: SELECT * FROM "information_schema"."tables" WHERE "table_schema" = 'core' AND "table_name" = '_typeorm_migrations'
query: SELECT * FROM "core"."_typeorm_migrations" "_typeorm_migrations" ORDER BY "id" DESC
46 migrations are already loaded in the database.
47 migrations were found in the source code.
AddCanBeUninstalledColumnToApplication1763731277403 is the last executed migration. It was executed on Fri Nov 21 2025 14:21:17 GMT+0100 (Central European Standard Time).
1 migrations are new migrations must be executed.
query: START TRANSACTION
query: SAVEPOINT sp_workspace_custom_application_id_non_nullable
query: ALTER TABLE "core"."workspace" DROP CONSTRAINT "FK_3b1acb13a5dac9956d1a4b32755"
query: ALTER TABLE "core"."workspace" ALTER COLUMN "workspaceCustomApplicationId" SET NOT NULL
query failed: ALTER TABLE "core"."workspace" ALTER COLUMN "workspaceCustomApplicationId" SET NOT NULL
error: error: column "workspaceCustomApplicationId" of relation "workspace" contains null values
query: ROLLBACK TO SAVEPOINT sp_workspace_custom_application_id_non_nullable
query: RELEASE SAVEPOINT sp_workspace_custom_application_id_non_nullable
query: INSERT INTO "core"."_typeorm_migrations"("timestamp", "name") VALUES ($1, $2) -- PARAMETERS: [1763977334519,"WorkspaceCustomApplicationIdNonNullable1763977334519"]
Migration WorkspaceCustomApplicationIdNonNullable1763977334519 has been executed successfully.
query: COMMIT
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [UpgradeCommand] Database migrations completed successfully
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [UpgradeCommand] Running command on workspace 20202020-1c25-4d02-bf25-6aeccf7ea419 1/2
Computing new Datasource for cacheKey: 20202020-1c25-4d02-bf25-6aeccf7ea419-10 out of 0
[Nest] 82844 - 11/24/2025, 6:05:12 PM DEBUG [PgPoolSharedService] Reusing existing pg Pool for key "localhost|5432|postgres||no-ssl"
[Nest] 82844 - 11/24/2025, 6:05:12 PM DEBUG [PgPoolSharedService] Pool[localhost|5432|postgres||no-ssl]: Client acquired from pool
[Nest] 82844 - 11/24/2025, 6:05:12 PM DEBUG [PgPoolSharedService] Pool[localhost|5432|postgres||no-ssl]: Client acquired from pool
query: SELECT * FROM current_schema()
[Nest] 82844 - 11/24/2025, 6:05:12 PM DEBUG [PgPoolSharedService] Pool[localhost|5432|postgres||no-ssl]: Client acquired from pool
query: SELECT version();
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [UpgradeCommand] Upgrading workspace 20202020-1c25-4d02-bf25-6aeccf7ea419 from=1.11.0 to=1.12.0 1/2
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [CreateWorkspaceCustomApplicationCommand] Checking standard applications for workspace 20202020-1c25-4d02-bf25-6aeccf7ea419
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [CreateWorkspaceCustomApplicationCommand] 20202020-1c25-4d02-bf25-6aeccf7ea419 skipping custom workspace application creation as already exists
query failed: ALTER TABLE "core"."workspace" ALTER COLUMN "workspaceCustomApplicationId" SET NOT NULL
error: error: column "workspaceCustomApplicationId" of relation "workspace" contains null values
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [WorkspaceCustomApplicationIdNonNullableCommand] Rollbacking WorkspaceCustomApplicationIdNonNullableCommand: column "workspaceCustomApplicationId" of relation "workspace" contains null values
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [SyncWorkspaceMetadataCommand] Running workspace sync for workspace: 20202020-1c25-4d02-bf25-6aeccf7ea419 (0 out of 2)
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [WorkspaceSyncMetadataService] Syncing standard objects and fields metadata
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [WorkspaceSyncMetadataService] Syncing standard objects and fields metadata
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [WorkspaceSyncObjectMetadataService] Comparing standard objects and fields metadata
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [WorkspaceSyncObjectMetadataService] Updating workspace metadata
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [WorkspaceSyncObjectMetadataService] Generating migrations
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [WorkspaceSyncObjectMetadataService] Saving migrations
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [WorkspaceSyncMetadataService] Workspace object migrations took 50.206083000000035ms
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [WorkspaceSyncFieldMetadataService] Updating workspace metadata
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [WorkspaceSyncFieldMetadataService] Generating migrations
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [WorkspaceSyncFieldMetadataService] Saving migrations
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [WorkspaceSyncMetadataService] Workspace field migrations took 79.43987500000003ms
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [WorkspaceSyncFieldMetadataRelationService] Updating workspace metadata
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [WorkspaceSyncFieldMetadataRelationService] Generating migrations
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [WorkspaceSyncFieldMetadataRelationService] Saving migrations
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [WorkspaceSyncMetadataService] Workspace relation migrations took 91.85295899999983ms
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [WorkspaceSyncIndexMetadataService] Syncing index metadata
[Nest] 82844 - 11/24/2025, 6:05:12 PM LOG [WorkspaceSyncMetadataService] Workspace index migrations took 153.78104199999962ms
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncMetadataService] Workspace object metadata identifiers took 130.9623330000004ms
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncRoleService] Syncing standard role metadata
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncMetadataService] Workspace role migrations took 2.154790999999932ms
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncAgentService] Syncing standard agent.
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncMetadataService] Workspace agent migrations took 2.3623329999991256ms
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncMetadataService] Workspace migrations save took 5.95837500000016ms
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncMetadataService] Executing pending migrations
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncMetadataService] Execute migrations took 66.94295799999963ms
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [SyncWorkspaceMetadataCommand] Finished synchronizing workspace.
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [SetStandardApplicationNotUninstallableCommand] Checking workspace applications for workspace 20202020-1c25-4d02-bf25-6aeccf7ea419
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [SetStandardApplicationNotUninstallableCommand] Successfully updated workspace application
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [UpgradeCommand] Upgrade for workspace 20202020-1c25-4d02-bf25-6aeccf7ea419 completed.
PromiseMemoizer Event: A WorkspaceDataSource for workspace 20202020-1c25-4d02-bf25-6aeccf7ea419 is being cleared. Actual pool closure managed by PgPoolSharedService. Not calling dataSource.destroy().
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [UpgradeCommand] Running command on workspace 3b8e6458-5fc1-4e63-8563-008ccddaa6db 2/2
Computing new Datasource for cacheKey: 3b8e6458-5fc1-4e63-8563-008ccddaa6db-6 out of 0
[Nest] 82844 - 11/24/2025, 6:05:13 PM DEBUG [PgPoolSharedService] Reusing existing pg Pool for key "localhost|5432|postgres||no-ssl"
[Nest] 82844 - 11/24/2025, 6:05:13 PM DEBUG [PgPoolSharedService] Pool[localhost|5432|postgres||no-ssl]: Client acquired from pool
[Nest] 82844 - 11/24/2025, 6:05:13 PM DEBUG [PgPoolSharedService] Pool[localhost|5432|postgres||no-ssl]: Client acquired from pool
query: SELECT * FROM current_schema()
[Nest] 82844 - 11/24/2025, 6:05:13 PM DEBUG [PgPoolSharedService] Pool[localhost|5432|postgres||no-ssl]: Client acquired from pool
query: SELECT version();
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [UpgradeCommand] Upgrading workspace 3b8e6458-5fc1-4e63-8563-008ccddaa6db from=1.11.0 to=1.12.0 2/2
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [CreateWorkspaceCustomApplicationCommand] Checking standard applications for workspace 3b8e6458-5fc1-4e63-8563-008ccddaa6db
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [CreateWorkspaceCustomApplicationCommand] Successfully create workspace custom application
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceCustomApplicationIdNonNullableCommand] Successfully run WorkspaceCustomApplicationIdNonNullableCommand
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [SyncWorkspaceMetadataCommand] Running workspace sync for workspace: 3b8e6458-5fc1-4e63-8563-008ccddaa6db (1 out of 2)
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncMetadataService] Syncing standard objects and fields metadata
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncMetadataService] Syncing standard objects and fields metadata
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncObjectMetadataService] Comparing standard objects and fields metadata
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncObjectMetadataService] Updating workspace metadata
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncObjectMetadataService] Generating migrations
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncObjectMetadataService] Saving migrations
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncMetadataService] Workspace object migrations took 19.26008400000046ms
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncFieldMetadataService] Updating workspace metadata
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncFieldMetadataService] Generating migrations
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncFieldMetadataService] Saving migrations
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncMetadataService] Workspace field migrations took 31.371917000000394ms
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncFieldMetadataRelationService] Updating workspace metadata
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncFieldMetadataRelationService] Generating migrations
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncFieldMetadataRelationService] Saving migrations
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncMetadataService] Workspace relation migrations took 36.84983300000022ms
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncIndexMetadataService] Syncing index metadata
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncMetadataService] Workspace index migrations took 43.85666599999968ms
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncMetadataService] Workspace object metadata identifiers took 74.27345799999966ms
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncRoleService] Syncing standard role metadata
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncMetadataService] Workspace role migrations took 1.3081249999995634ms
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncAgentService] Syncing standard agent.
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncMetadataService] Workspace agent migrations took 0.7992909999993572ms
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncMetadataService] Workspace migrations save took 2.1899590000002718ms
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncMetadataService] Executing pending migrations
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [WorkspaceSyncMetadataService] Execute migrations took 33.817165999999816ms
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [SyncWorkspaceMetadataCommand] Finished synchronizing workspace.
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [SetStandardApplicationNotUninstallableCommand] Checking workspace applications for workspace 3b8e6458-5fc1-4e63-8563-008ccddaa6db
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [SetStandardApplicationNotUninstallableCommand] Successfully updated workspace application
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [UpgradeCommand] Upgrade for workspace 3b8e6458-5fc1-4e63-8563-008ccddaa6db completed.
PromiseMemoizer Event: A WorkspaceDataSource for workspace 3b8e6458-5fc1-4e63-8563-008ccddaa6db is being cleared. Actual pool closure managed by PgPoolSharedService. Not calling dataSource.destroy().
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [UpgradeCommand] Command completed!
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [PgPoolSharedService] pg Pool for key "localhost|5432|postgres||no-ssl" has been closed. Remaining pools: 0
[Nest] 82844 - 11/24/2025, 6:05:13 PM DEBUG [PgPoolSharedService] Pool[localhost|5432|postgres||no-ssl]: Connection removed from pool
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [PgPoolSharedService] onApplicationShutdown called in PgPoolSharedService
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [PgPoolSharedModule] Shutting down PgPoolSharedModule
[Nest] 82844 - 11/24/2025, 6:05:13 PM LOG [PgPoolSharedService] onApplicationShutdown called in PgPoolSharedService
———————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
NX Successfully ran target command for project twenty-server and 4 tasks it depends on (7s)
With additional flags:
upgrade
```
|
||
|
|
8299488f21 |
Fix front data model edition + non nullable workspaceCustom application migration (#16016)
# Introduction Two things: - Enforcing non nullable workspace custom application Id for any workspace - Fixing front non editable data models following https://github.com/twentyhq/twenty/pull/15911 that associate any custom entities to an applicationId. The front was putting everything as readonly when under an app ( we will have to handle the twenty standard application in the future too ) ## Fallback ### Migration The non nullable migration will fail when released, that's why it's being swallowed and re-run in an upgrade command post workspace custom application creation for those that miss one. Allowing the migration to pass in the end The typeorm migration still need to exists for any new workspaces ### GetCurrentUser In order to dynamically display isReadOnly in data model settings we're fetching the workspaceCustomApplicationId through the `getCurrentUser` If not fallback this endpoint would throw until we're handling existing workspaces that do not have a custom workspace application The fallback should be removed post release |
||
|
|
f9ab09c404 |
Metadata api create entity in workspace custom app (#15911)
# Introduction Cleaner and fewer scope version of https://github.com/twentyhq/twenty/pull/15745 ( removed sync-metadata hack through, too ambitious migration and upgrade ) Please note that this PR won't have any interaction with the existing sync-metadata Which mean that the sync metadata does not update the standard entities applicationId and universalIdentifier, and it won't we will deprecate it on favor of a workspace migration aka twenty-standard app installation ## API Metadata Any operation going through the api metadata nows automatically scope the related entity to the workspace custom application instance. ( optionally passing an applicationId to allow current hacky implem of app sync service ) We need to either ignore the tests or remove the cli status check from the blocking status badges for a PR to be merged ## New workspace Already handled in previous https://github.com/twentyhq/twenty/pull/15625, when a workspace is created it gets created a twenty standard and custom workspace instance All his views and permissions will be prefilled to the its twenty standard app instance with a specific universalIdentifier ## New universalIdentifier At the contrary as before with standardIds, universalIdentifier are unique for a given workspace This means that createdAt field of both object company and opportunity will have a unique universalIdentifier whereas they share the same standardId ## FlatApplication Introduced the flatApplication and cache. Will migrate existing `MetadataName` to be `SyncableMetadataName` in a following PR ## What's next Next we will describe a twenty standard app configuration as json that will be used to generate a workspace migration that will be run instead of the sync metadata, in a nutshell we aim to deprecated the sync metadata So we can standardize any entity to have a non nullable applicationId and universalIdentifier ## Upgrade command Introduced an upgrade command that will create a custom workspace instance for any workspace that do not have one in order to align with the new behavior when creating a new workspace |
||
|
|
445b76fa26 |
Add uninstall button to application setting (#15988)
As title <img width="878" height="668" alt="image" src="https://github.com/user-attachments/assets/b0c9ae1e-036f-4bdd-9bd2-a2a37c2e3b99" /> |
||
|
|
a281f2a773 |
feat: add configurable response format for AI agents (text/JSON) (#15953)
## Summary
This PR adds configurable response format support for AI agents,
allowing them to return either plain text or structured JSON data based
on a defined schema.
## Key Features
### 1. Agent Response Format Configuration
- Added `AgentResponseFormat` type supporting:
- `text`: Returns plain text responses (default)
- `json`: Returns structured JSON based on defined schema
- New `AgentResponseSchema` type moved to `twenty-shared/ai` for sharing
between frontend/backend
### 2. Settings UI
- New `SettingsAgentResponseFormat` component for configuring response
format
- Visual schema builder for defining JSON output structure
- Real-time validation and preview
- Integrated into agent settings tab
### 3. Workflow Integration
- AI Agent workflow action automatically uses agent's configured
response format
- Output schema dynamically generated from agent's response format
- Workflow variable picker shows structured fields for JSON responses
- Backward compatible with existing text-only agents
### 4. Backend Implementation
- Added `convertAgentSchemaToZod` utility to validate JSON responses
- Agent executor service handles both text and JSON generation
- Automatic agent creation/cloning when adding AI agent steps to
workflows
- Unique agent naming with conflict resolution
### 5. Database Migration
- Migration `1763622159656-update-agent-response-format.ts`
- Sets default `responseFormat` to `{"type":"text"}` for existing agents
- Updated all standard agents with proper response format
## Changes by Module
### Frontend (`twenty-front`)
- 🆕 `AgentResponseFormat` type
- 🆕 `SettingsAgentResponseFormat` component
- ✏️ Updated `WorkflowEditActionAiAgent` to support response format
configuration
- 🗑️ Removed deprecated `useAiAgentOutputSchema` hook and
`AiAgentOutputSchema` type
### Backend (`twenty-server`)
- 🆕 `AgentResponseFormat` type in agent entity
- 🆕 `convertAgentSchemaToZod` utility for schema validation
- ✏️ Updated `AiAgentExecutorService` to handle both text and JSON
generation
- ✏️ Updated `WorkflowSchemaWorkspaceService` to generate output schema
from agent config
- ✏️ Enhanced `WorkflowVersionStepOperationsWorkspaceService` with agent
creation/cloning
- 🆕 Agent naming constants for conflict resolution
### Shared (`twenty-shared`)
- 🆕 `AgentResponseSchema` type
- 🆕 `ModelConfiguration` type moved to shared package
- Updated exports in `ai/index.ts`
## Code Quality
- Removed useless comments following code style guidelines
- All linter checks passed
- Type-safe implementation with proper TypeScript types
## Testing
- ✅ Database migration tested
- ✅ Agent creation/cloning in workflows verified
- ✅ Response format switching (text ↔ JSON) validated
- ✅ Backward compatibility with existing agents confirmed
## Migration Notes
- Existing agents will have `responseFormat: {type: 'text'}` set
automatically
- No breaking changes - all existing functionality preserved
- Agents can be updated to use JSON format through settings UI
|
||
|
|
3190ca5b9e |
1858 extensibility create relation metadata decorator in thwenty sdkapplications (#15907)
as title First PR I will update the twenty-cli in another PR |
||
|
|
a39efeb1ab |
[BREAKING_CHANGE/GRAPHQL/OBJECT_METADATA_CREATE_ONE] Remove object/fields/view-fields v1 implementation (#15823)
# Introduction Remove the v2 feature flag for view-field field-metadata and object-metadata metadata entities ## Some details - Disabled nestjs-query for object metadata creation and explicitly calling it - removed all v1 integration tests files ## Remarks Not remove v2 referencing in both filenaming right now will handle that globally later ## Breaking change Due to object metadata resolver createOne standardization had to rename the input from `CreateObjectInput` to `CreateOneObjectInput` |
||
|
|
5dfb66917c |
Upgrade NestJS from 10.x to 11.x (#15836)
## Overview
This PR upgrades all NestJS dependencies from version 10.x to 11.x,
following the [official migration
guide](https://docs.nestjs.com/migration-guide). This builds on top of
the v9 to v10 upgrade completed in PR #15835.
## Changes
### Dependencies Updated
**Core packages (10.x → 11.x):**
- `@nestjs/common`: 10.4.16 → 11.0.8
- `@nestjs/core`: 10.4.16 → 11.0.8
- `@nestjs/platform-express`: 10.4.16 → 11.0.8
- `@nestjs/config`: 3.2.3 → 3.3.0
- `@nestjs/passport`: 10.0.3 → 11.0.0
- `@nestjs/axios`: 3.0.2 → 3.1.2
- `@nestjs/schedule`: ^3.0.0 → ^4.1.1
- `@nestjs/serve-static`: 4.0.2 → 5.0.1
- `@nestjs/cache-manager`: ^2.2.1 → ^2.3.0
- `@nestjs/jwt`: 10.2.0 → 11.0.0
- `@nestjs/typeorm`: 10.0.2 → 11.0.0
- `@nestjs/terminus`: 11.0.0 (already on v11)
- `@nestjs/event-emitter`: 2.1.0 (compatible)
**DevDependencies:**
- `@nestjs/testing`: ^10.4.16 → ^11.0.8
- `@nestjs/schematics`: ^10.1.0 → ^11.0.2
- `@nestjs/cli`: 10.3.0 → 11.0.0
### Code Changes
**Fixed: TwentyConfigModule conditional imports**
- Updated `TwentyConfigModule.forRoot()` to use spread operator for
conditional imports
- Fixes TypeScript error with NestJS 11's stricter DynamicModule type
checking
**Cleanup: Removed unused package**
- Removed `@revertdotdev/revert-react` (not being used anywhere in the
codebase)
## Breaking Changes Addressed
### 1. ✅ Reflector Type Inference
- **Impact**: None - codebase only uses `reflector.get()` method
- **Analysis**: Does not use `getAllAndMerge()` or `getAllAndOverride()`
(the methods with breaking changes)
- **Files reviewed**: feature-flag.guard.ts,
message-queue-metadata.accessor.ts,
workspace-query-hook-metadata.accessor.ts
### 2. ✅ Lifecycle Hooks Execution Order
- **Change**: Termination hooks (`OnModuleDestroy`,
`BeforeApplicationShutdown`, `OnApplicationShutdown`) now execute in
REVERSE order
- **Analysis**: Reviewed all lifecycle hook implementations
- Redis client cleanup
- Database connection cleanup (GlobalWorkspaceDataSource)
- BullMQ queue/worker cleanup
- Cache storage cleanup
- **Result**: Dependency order is safe - services using connections
clean up before the connections themselves
### 3. ✅ Middleware Registration Order
- **Change**: Global middleware now executes first regardless of import
order
- **Analysis**: Middleware is not registered as global, so execution
order remains consistent
- **Files reviewed**: app.module.ts, middleware.module.ts
## Testing
All tests passing and build successful:
**Unit Tests (283+ tests):**
- ✅ Health module: 38 tests passed
- ✅ Auth module: 115 tests passed (passport v11 integration)
- ✅ REST API: 90 tests passed (middleware and express platform)
- ✅ Feature flags: 17 tests passed (Reflector usage)
- ✅ Workspace: 23 tests passed
**Build & Quality:**
- ✅ Type checking: Passed
- ✅ Linting: Passed
- ✅ Build: 3,683 files compiled successfully
## Verification
Tested critical NestJS functionality:
- ✅ Authentication & Security (JWT, OAuth, guards)
- ✅ HTTP Platform (Express integration, REST endpoints)
- ✅ Dependency Injection (Services, factories, providers)
- ✅ Cache Management (Redis with @nestjs/cache-manager)
- ✅ GraphQL (Query runners, resolvers)
- ✅ Configuration (Environment config)
- ✅ Scheduling (Cron jobs with @nestjs/schedule v4)
- ✅ Lifecycle Hooks (Module initialization and cleanup)
- ✅ Reflector (Metadata reflection in guards)
## Related PRs
- #15835 - Upgrade NestJS from 9.x to 10.x (completed)
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> Upgrades NestJS to v11 and updates routing patterns, auth strategies,
GraphQL schema options, and build/dist paths (scripts, Docker, Nx,
migrations, assets), plus enables Devtools in development.
>
> - **Backend (NestJS 11 upgrade)**:
> - Bump `@nestjs/*` packages (core, platform-express, jwt, passport,
typeorm, serve-static, schedule, cli/testing/schematics) to v11.
> - Update REST/route-trigger/file controllers to new wildcard syntax
(`*path`).
> - Refactor OAuth (Google/Microsoft) and SAML strategies (abstract base
+ explicit `validate`); minor typings.
> - Enable `DevtoolsModule` in development.
> - **GraphQL**:
> - Add `buildSchemaOptions.orphanedTypes` for client-config types; keep
Yoga/Sentry setup.
> - **Build/Runtime & Config**:
> - Standardize dist layout (remove `src` in paths): update scripts,
Docker `CMD`, Nx `project.json`, render scripts, TypeORM migration
paths, asset resolution.
> - Adjust `nest-cli.json` (watchOptions, asset globs, migrations
outDir, monorepo/root).
> - Improve config module imports (spread conditional); tsconfig
excludes `node_modules`.
> - Minor Nx default: `start` target caching disabled.
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
|
||
|
|
df58f4102e |
Fix typo in command (#15818)
as title |
||
|
|
0cab2b49fc |
(breaking change) Allow users with a single workspace to update their email. (#15736)
- Users with a single workspace are allowed to update their email across `core.user` and `workspace_xyz.workspaceMember`. - The latter happens asynchronously (built it like this for non-blocking with multiple workspaces), but since we restrict the email update functionality to a single user, we can also update the email in workspaceMember synchronously - I left asynchronous there to receive feedback on whether we should move to synchronous or not. - Merged main and resolved conflicts to ensure we use the `SettingsPermissionGuard` and the updated `workspace.service.ts` code. One edge-case that I was trying to communicate on Discord: Say that an admin is a member of multiple workspaces. Therefore, they can allow roles with PROFILE_INFORMATION permission to update their email. <p align="center"> <img width="553" height="115" alt="image" src="https://github.com/user-attachments/assets/80382b1f-a9e3-4dac-b606-c2defeb2c330" /> </p> However, since the admin is part of multiple workspaces, he/she cannot even update own email - the field stays disabled, leading to some confusion. <p align="center"> <img width="545" height="255" alt="image" src="https://github.com/user-attachments/assets/5e6d27db-c9a8-4d5e-9ab6-65c77beae5b4" /> </p> However, the workspace can have another member with admin role or some other role that has PROFILE_INFORMATION permission flag. That user will be and should be allowed to update email, so we cannot hide `email` from dropdown options. <p align="center"> <img width="585" height="283" alt="image" src="https://github.com/user-attachments/assets/a670d3ac-cf48-4865-a425-b909093d8420" /> </p> The behavior is fine imo, just a little confusing for members with more than one workspace. I have also tested the flow by signing up to YC workspace with my org google account (twenty.com), then changing email to my personal address. - After changing, I need to login using Google with my personal account to access YC workspace again. - If I login using Google with org google account (twenty.com), a new user account is created. This behavior is consistent with Notion and Linear. Finally, as for the verification of email, the user is asked to verify email while they're logged in, but just in case they logout without verifying, the next login would force them to verify their email in the email/password flow. However, for Social/SSO, they must verify before they logout or else they'd have to contact support for assistance. I have not looked into how to show verification screen while logging in via Social/SSO yet, but if that's something critical for completeness here, I shall revisit it. --------- Co-authored-by: Félix Malfait <felix@twenty.com> |
||
|
|
de978960d0 |
[FIx] shouldBypassPermissionChecks for workspaceMember repository (#15706)
<!-- CURSOR_SUMMARY -->
> [!NOTE]
> Pass `shouldBypassPermissionChecks: true` to
`getRepositoryForWorkspace('workspaceMember')` in
`1-11-clean-orphaned-user-workspaces.command.ts` to ensure member lookup
during orphan cleanup ignores permissions.
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
|
||
|
|
9880f192a5 | Move composite types to twenty-shared (#15741) | ||
|
|
7a1e699fc8 |
Twenty standard and workspace custom applications 1/3 (#15625)
# Introduction related to https://github.com/twentyhq/core-team-issues/issues/1833 In this PR we're starting the sync-metadata and standardIds deprecation by introducing `twenty-standard` application that will regroup every standard object such as company and opportunities. But also the `custom-workspace-application` which is an app created at the same time as a workspace and that will regroup everything configure within the workspace ( custom objects fields etc ) ## What's done On both new workspace and seeded workspace creation: - Creating a custom workspace app - Creating a twenty standard app - Refactored the seed core schema and workspace creation to be run within a transaction in order to handle circular dependency foreignkey requirements ( which is deferred for app toward workspace ) - Updated workspace entity to have a custom workspace relation ( nullable for the moment until we implem an upgrade command to handle retro comp ) - Integration testing on user, workspace creation deletion and expected default apps creation - ~~Soft deleted user on `deleteUser`~~ Done by marie and rebased on it ## What's next - Update seeder to propagate the `twenty-standard` workspace `applicationId` to every standard synchronized entities ( cheap and fast iteration through the about to be deprecated sync-metadata as an easy way to synchronize standards metadata entities ). - Update seeder to propagate the `custom-workspace-application` workspace `applicationId` to anything custom ( `pets` and `rockets` ) - Prepend `custom-workspace-application` `applicationId` to every metadata API operations ( create a specific cache etc ) - Upgrade command on all existing workspace to create a custom app and associate its applicationId to any existing custom entities - Make `universalIdentifier` and `applicationId` required for any syncable entity |
||
|
|
cff17db6cb |
Enhance role-check system with stricter checks (#15392)
## Overview This PR strengthens our permission system by introducing more granular role-based access control across the platform. ## Changes ### New Permissions Added - **Applications** - Control who can install and manage applications - **Layouts** - Control who can customize page layouts and UI structure - **AI** - Control access to AI features and agents - **Upload File** - Separate permission for file uploads - **Download File** - Separate permission for file downloads (frontend visibility) ### Security Enhancements - Implemented whitelist-based validation for workspace field updates - Added explicit permission guards to core entity resolvers - Enhanced ESLint rule to enforce permission checks on all mutations - Created `CustomPermissionGuard` and `NoPermissionGuard` for better code documentation ### Affected Components - Core entity resolvers: webhooks, files, domains, applications, layouts, postgres credentials - Workspace update mutations now use whitelist validation - Settings UI updated with new permission controls ### Developer Experience - ESLint now catches missing permission guards during development - Explicit guard markers make permission requirements clear in code review - Comprehensive test coverage for new permission logic ## Testing - ✅ All TypeScript type checks pass - ✅ ESLint validation passes - ✅ New permission guards properly enforced - ✅ Frontend UI displays new permissions correctly ## Migration Notes Existing workspaces will need to assign the new permissions to roles as needed. By default, all new permissions are set to `false` for non-admin roles. |
||
|
|
0992d8031b | [Fix] fix command dry run (#15697) | ||
|
|
4ce93aee52 |
Fix user deletion flows (#15614)
**Before** - any user with workpace_members permission was able to remove a user from their workspace. This triggered the deletion of workspaceMember + of userWorkspace, but did not delete the user (even if they had no workspace left) nor the roleTarget (acts as junction between role and userWorkspace) which was left with a userWorkspaceId pointing to nothing. This is because roleTarget points to userWorkspaceId but the foreign key constraint was not implemented - any user could delete their own account. This triggered the deletion of all their workspaceMembers, but not of their userWorkspace nor their user nor the roleTarget --> we have orphaned userWorkspace, not technically but product wise - a userWorkspace without a workspaceMember does not make sense So the problems are - we have some roleTargets pointing to non-existing userWorkspaceId (which caused https://github.com/twentyhq/twenty/issues/14608 ) - we have userWorkspaces that should not exist and that have no workspaceMember counterpart - it is not possible for a user to leave a workspace by themselves, they can only leave all workspaces at once, except if they are being removed from the workspace by another user **Now** - if a user has multiple workspaces, they are given the possibility to leave one workspace while remaining in the others (we show two buttons: Leave workspace and Delete account buttons). if a user has just one workspace, they only see Delete account - when a user leaves a workspace, we delete their workspaceMember, userWorkspace and roleTarget. If they don't belong to any other workspace we also soft-delete their user - soft-deleted users get hard deleted after 30 days thanks to a cron - we have two commands to clean the orphans roleTarget and userWorkspace (TODO: query db to see how many must be run) **Next** - once the commands have been run, we can implement and introduce the foreign key constraint on roleTarget Fixes https://github.com/twentyhq/twenty/issues/14608 |