## Problem
When accessing file URLs like `/files/attachment/{token}/{filename}`,
the server was returning 500 errors with no logs. The issue was that the
route pattern `*path/:filename` was not properly extracting parameters,
causing `request.params[0]` to be undefined.
## Solution
- Changed route from `@Get('*path/:filename')` to
`@Get(':folder/:token/:filename')` for explicit parameter extraction
- Simplified `extractFileInfoFromRequest` to use named route parameters
directly instead of complex path parsing
- Removed unnecessary logging that was added during debugging
- Added test to verify route parameters are correctly extracted and
passed to FileService
## Testing
- Added unit test that verifies folder, token, and filename parameters
are correctly passed to the service
- Test will catch any future regressions where route parameters are not
properly extracted
## 🐛 Issues Fixed
### 1. Role Editing Not Working for New Agents
When creating a new agent and then creating a role for it, the role
permissions appeared as non-editable. This was caused by:
- In create mode, `agentId = ''` (empty string from `useParams`)
- Empty string is **falsy** but `isDefined('')` returns **true**
- This caused incorrect behavior in role exclusivity checks and API
calls
### 2. Missing Role Data Loading
The agent form wasn't loading role data needed for permission editing
because it was missing the `SettingsRolesQueryEffect` component.
### 3. Navigation Conflicts
The `useSaveDraftRoleToDB` hook contained navigation logic that caused
conflicts when used from different contexts (role detail page vs agent
form).
### 4. Linting Errors
Unused `useIcons` import in `SettingsAgentRoleTab.tsx`.
---
## 🔧 Changes Made
### Agent Role Tab (`SettingsAgentRoleTab.tsx`)
- ✅ Use `isNonEmptyString(agentId)` to validate agentId (follows
codebase patterns)
- ✅ Improved role exclusivity logic to handle both create and edit
modes:
- **Edit mode**: Role must be assigned exclusively to this agent
- **Create mode**: Role must not be assigned to anyone yet
- ✅ Only call `assignRoleToAgent` when a valid agentId exists
- ✅ Pass `undefined` instead of empty string for `fromAgentId` prop
### Role Hook (`useSaveDraftRoleToDB.ts`)
- ✅ Removed navigation logic from the hook (better separation of
concerns)
- ✅ Removed `useNavigateSettings` and `SettingsPath` dependencies
- ✅ Hook now only handles data persistence, not navigation
### Role Component (`SettingsRole.tsx`)
- ✅ Added navigation after successful role creation in create mode
- ✅ Navigation now handled by the component using the hook
### Agent Form (`SettingsAgentForm.tsx`)
- ✅ Added `SettingsRolesQueryEffect` to ensure role data is loaded
- ✅ Agent form handles its own navigation after save
---
## ✅ Testing Scenarios
All these scenarios now work correctly:
1. ✅ Create new agent → Create role → Edit permissions → Save agent
2. ✅ Edit existing agent → Create role → Edit permissions → Save
3. ✅ Edit existing agent → Try to edit shared role (shows warning
message)
4. ✅ Navigate to object-level permissions from agent form with proper
breadcrumbs
---
## 📝 Technical Details
### Root Cause Analysis
The main issue was that empty string was being treated differently in
different checks:
- `agentId &&` → evaluates to `false` (empty string is falsy)
- `isDefined(agentId)` → returns `true` (empty string is defined)
This inconsistency caused the role to appear as non-editable and
attempted invalid API calls.
### Solution
Used `isNonEmptyString()` from `@sniptt/guards` which properly checks
both that the value is defined AND not empty, following codebase
conventions.
---
## 🎯 Impact
- Fixes critical bug preventing role permission configuration for new
agents
- Improves code quality with better separation of concerns
- Makes navigation logic more predictable and maintainable
- Follows codebase patterns and guidelines
Previously, single-item fields `maxItemCount: 1` didn’t show updated
values after pressing `Enter` the UI only refreshed on click outside.
This happened because the items list was hidden while
`shouldAutoEditSingleItem` remained true.
This PR updates the render condition to also check `!isInputDisplayed`,
ensuring the items list re-renders immediately after editing.
**Result:** Instant UI updates on Enter with no impact on multi-item
fields.
Fixes#15792
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
I know you did this change in order to make the frontend faster and less
resource eating. However it broke this optimistic rendering part
@lucasbordeau.
I suggest this quick fix, but I am open to a sharper one as well
Fixes https://github.com/twentyhq/twenty/issues/15838
---------
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
Co-authored-by: Charles Bochet <charles@twenty.com>
## Overview
This PR refactors the `CalendarEventDetails` component to dynamically
display both standard and custom fields added via the metadata API,
instead of using a hardcoded field list.
## Changes
- Replaced hardcoded `fieldsToDisplay` array with dynamic field fetching
using `useFieldListFieldMetadataItems` hook
- Split fields into `standardFields` (maintaining original order) and
`customFields`
- Introduced `renderField` helper function to eliminate code duplication
- Custom fields now automatically appear at the bottom of the detail
panel after standard fields
- Maintained exact field order and all existing functionality including
participant response status display
## Technical Details
- Uses existing `useFieldListFieldMetadataItems` pattern already
established in the codebase
- Standard field order explicitly defined: startsAt, endsAt,
conferenceLink, location, description
- Participant response status (Yes/Maybe/No) correctly positioned
between first 2 and last 3 standard fields
- All fields respect permissions and visibility settings from metadata
## Testing
- ✅ Verified all standard fields display in correct order
- ✅ Added custom field `mycustomfieldtest` via metadata API - displays
correctly at bottom
- ✅ Participant responses (Yes/Maybe/No) render correctly with avatars
- ✅ Event title, creation date, and event chip display properly
- ✅ Canceled event styling (strikethrough) works
- ✅ No console errors or regressions detected
- ✅ Read-only behavior maintained (calendar events sync from external
sources)
## Screenshots
<img width="1401" height="746" alt="CleanShot 2025-11-17 at 11 23 57"
src="https://github.com/user-attachments/assets/3d967ec5-6d31-4fc3-b971-c73ea521c87d"
/>
## Related
This enables users to extend calendar events with custom metadata fields
that will automatically display in the UI without code changes.
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
There was an extra definition of @nx/js inside twenty-server, which was
not recognized during upgrade by the CLI. This caused two versions of
@nx/js in the repo - 22.0.3 from root and 21.3.11 from the twenty-server
package.
Removed the one inside twenty-server to maintain a single source of
truth.
Closes https://github.com/twentyhq/core-team-issues/issues/1600.
Two remarks
- This `limit` variable does not reduce postgre's work at it still needs
to scan the whole table. It did not seem possible to me to optimize this
as we cannot foresee which dimensions will be used by the user, and an
optimization could only result from an index on the dimension(s) (e.g.:
group companies by addressCity limit 50 can be optimized if we have an
index on companies.addressCity + we had a default orderBy on
adressCity). But this will still optimize the FE which at the moment
receives all groups and truncates the result.
- I have not done the work on the FE as the addition of limit is a
breaking change, and will break until the workspaces' schema is rebuilt,
so we need to flush the cache. I think this could be acceptable as the
feature is in the lab but I preferred not doing it yet as it would have
no impact since in the BE I added a default limit to 50 groups, and I
expect more FE work will be done to allow the user to choose their own
limit
## Background
Team Comfortably Summed had submitted Activity Summary for Twenty's
Hacktoberfest. This is a follow-up PR post-Hacktoberfest.
## Changes
### Purpose
>_What is the objective?_
To improve the code based on human and bot comments from the initial
Hacktoberfest PR, and to improve the robustness of task completion
calculation.
>_Are we solving a problem or making necessary changes to support an
existing and / or a new feature?_
Making changes to improve existing features.
### Summary
> _Are there files we can ignore?_
None.
> _Please provide a high-level summary of the changes._
- Corrects `README.md` by removing irrelevant commands and unnecessary
configuration notes
- Updates `people-creation-summariser.ts`
- Replaces requesting of company for each person by including `depth=1`
as query parameter in GET /people request as suggested by Martin Muller
– link to comment:
[link](https://github.com/twentyhq/twenty/pull/15510#discussion_r2486019035)
- Updates `senders.ts`
- Renames `formattedMesage` to `formattedMessage`
- Updates `task-creation-summariser.ts`
- Improves calculation of completed task percentage by relying only on
list of completed tasks and total list of tasks
- The initial implementation includes relying on pending tasks and
pending overdue tasks which can result in undesired calculation outcome
Some Glob CLI related alerts were generated last night. I believe
they're safe to dismiss since I do not expect us to use the Glob CLI in
production environment, and those alerts do not impact the API, but
still updating the dependency version just in case.
Not sure if this would resolve all/any of the alerts since glob is a
dependency for many other dependencies, so a good number of dependency
variants are pulled in.
The alert that confirms it's just a CLI related vulnerability:
[Dependabot Alert
307](https://github.com/twentyhq/twenty/security/dependabot/307)
Resolves [Dependabot Alert
309](https://github.com/twentyhq/twenty/security/dependabot/309) and
maybe also a few others.
Bumped up the version for js-yaml to 4.1.1 and 3.14.2 across transitive
dependencies using `yarn up js-yaml --recursive`.
Context -
- refactoring v1 and v2 seeds to test v2 dashboard flag both on and off
Right now, the db reset command fails if the feature flag is off
- whenever there is a groupBy field -- we should add a default groupMode
- we already do that on the front -- but implementing the same on server
so that api users get the same response
This is also the reason why the second seed on dashboards lags a lot --
because on that particular dashboard's widget -- we set groupBy but no
groupMode (in seeding util) -- and the effect of limiting the bars to
fifty runs depending on the groupMode
## Summary
- add a regression test that reproduces the workflow "Search Records →
ID is <UUID>" failure (issue #15067 / #15746)
- adjust `turnRecordFilterIntoRecordGqlOperationFilter` so UUID filters
fall back to the literal value when no `recordIdsForUuid` context is
provided, always emitting an `in` clause
## Testing
- npx nx test twenty-shared --
--testPathPattern=computeRecordGqlOperationFilter.test.ts
--coverage=false
- Manual: workflow "Search Records" with filter "ID is <UUID>" now
returns the correct record
Fixes#15067Fixes#15746
---------
Co-authored-by: remi <remi@labox-apps.com>
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
- Allow widgets to be hidden based on device's type conditions: desktop
or mobile
- Create two widgets for rich text fields on tasks and notes. One widget
is displayed below fields on mobile (and in the right drawer); the other
is displayed on a separate tab on desktop
- In read mode, hide tabs if they contain no visible widgets. If there
is no tab left to display, display at least the first one with no
widgets.
- In edit mode, display all tabs and all widgets.
## Demo
https://github.com/user-attachments/assets/65ef1261-3902-4432-a420-48983b763b2c
Closes https://github.com/twentyhq/core-team-issues/issues/1811
## Summary
This PR replaces the Active/Inactive accordion sections with a modern
filter dropdown button and enables full access to system objects in
advanced mode.
## Changes
### UI Improvements
- ✅ Replaced accordion sections with a filter button dropdown (matching
the design pattern from the Group filter)
- ✅ Added 'Deactivated' toggle filter (hidden by default, uses
IconArchive)
- ✅ Added 'System objects' toggle filter (only visible in advanced mode,
uses IconSettings)
- ✅ Fixed search input width to properly fill available space
- ✅ Proper button sizing and alignment
### System Objects Support
- ✅ Made system objects visible when 'System objects' filter is toggled
on
- ✅ System objects are now fully clickable and accessible
- ✅ Updated object detail page to support system objects
- ✅ Updated field creation/edit pages to support system objects
- ✅ System objects can now have custom fields added
### Architecture
- ✅ Implemented scalable filter architecture using a single filtered
list
- ✅ Easy to add more filters in the future (e.g., show remote objects)
- ✅ All filters work independently and can be combined
## Testing
- [x] Tested deactivated objects toggle
- [x] Tested system objects toggle (only shows in advanced mode)
- [x] Tested clicking on system objects
- [x] Tested adding custom fields to system objects
- [x] No linter errors
## Screenshots
See attached screenshots in the conversation for the new filter UI.
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> Adds a filter dropdown to the Settings Objects table (incl.
deactivated/system toggles), enables system objects across
settings/field flows, seeds core views (workspace members, messages,
threads, calendar events), and adds actions for Workspace Members.
>
> - **Settings UI**
> - **Objects Table**: Replaces Active/Inactive sections with a single
filterable list and dropdown (`Deactivated`, `System objects` in
advanced mode); updates props to `objectMetadataItems` and removes
accordion sections.
> - **Search/UX**: Search input fills available space; inactive rows
show activation/delete menu; active rows remain navigable.
> - **Pages Updated**: `SettingsObjects`,
`SettingsApplicationDetailContentTab` switch to new table API; object
detail and new-field flows use `findObjectMetadataItemByNamePlural`
(works with system objects).
> - **Action Menu**
> - **Workspace Members**: Adds `WORKSPACE_MEMBERS_ACTIONS_CONFIG` with
"Manage members in settings" action; wired into `getActionConfig` for
`WorkspaceMember`.
> - **Server (Core Views Seed)**
> - Adds default views: `workspaceMembersAllView`, `messagesAllView`,
`messageThreadsAllView`, `calendarEventsAllView`; included in
`prefillCoreViews`.
> - Marks workflow entities as system (`WorkflowRun`,
`WorkflowVersion`).
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
6a2856df85. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
Resolves [Dependabot Alert
301](https://github.com/twentyhq/twenty/security/dependabot/301).
Locked the version of "ai" at 5.0.52 in order to stop it from bumping to
5.0.93 directly when the ^ is introduced since it breaks the code across
multiple files.
Fixes#14723
### Summary
Fixes a UI while creating a custom CRON
### Changes Made
- updated `WorkflowEditTriggerCronForm.tsx` to use the predefined
`FormSelectFieldInput.tsx` instead of using `Select.tsx`
- added `hint` prop to `FormSelectFieldInput.tsx`
- updated styling for showing `Upcoming execution time`
- added conditional render for `Schedule` and `Upcoming Execution Time`
- `Schedule` section is not rendered in Custom Cron
### Steps to Reproduce (Before Fix)
1. Navigate to - /object/workflow/xxxx
2. Try adding a new Trigger
3. Set Trigger Interval to Cron (Custom)
### Before
### After
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
# Introduction
Important note: for the moment testing this locally will require some
hack due to latest twenty-sdk not being published.
You will need to build twenty-cli and `cd packages/twenty-cli && yarn
link`
To finally sync the app in your app folder as `cd app-folder && twenty
app sync`
close https://github.com/twentyhq/core-team-issues/issues/1863
In this PR is introduced the generate sdk programmatic call to
[genql](https://genql.dev/) exposed in a `client` barrel of `twenty-sdk`
located in this package as there's high chances that will add a codegen
layer above it at some point ?
The cli calls this method after a sync application and writes a client
in a generated folder. It will make a graql introspection query on the
whole workspace. We should later improve that and only filter by current
applicationId and its dependencies ( when twenty-standard application is
introduced )
Fully typesafe ( input, output, filters etc ) auto-completed client
## Hello-world app serverless refactor
<img width="2480" height="1326" alt="image"
src="https://github.com/user-attachments/assets/b18ea372-b21d-4560-8fbc-1dc348427a95"
/>
---------
Co-authored-by: martmull <martmull@hotmail.fr>
# 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`
Resolves [Dependabot Alert
143](https://github.com/twentyhq/twenty/security/dependabot/143).
Used `yarn up @bundled-es-modules/cookie --recursive` to move from
version `2.0.0` to `2.0.1` so that the underlying cookie dependency
version moves from `0.5.0` to `0.7.2`.
Resolves [Dependabot Alert
293](https://github.com/twentyhq/twenty/security/dependabot/293).
Updates the playwright version used to `1.56.1`. The alert could have
also been ignored since the playwright download only happens in CI and
local environments, not the production environment. However, it's an
easy fix instead of just ignoring the alert.
# Introduction
While removing the v1 https://github.com/twentyhq/twenty/pull/15823 I've
encountered the method `objectMetadataService.deleteObjectsMetadata`
that I didn't wanted to migrate as it is and if it's not challenging its
existence legitimacy.
## Motivations
In a nutshell on a workspace deletion object metadata and field metadata
cascading deletion is correclty handled
But that's not the case for all of a workspaces entities ( roles,
workspaceMigrations ) I suspect that we did not defined the foreignKey
explicitly through `typeorm`
## Battle testing v2
I still decided to give a try to a complex operation in the v2 such as a
workspace all object metadata deletion.
Spoiler it failed due to object being interdependent between them and
not being topologically sorted ( morph relation can introduce circular
dep anw ).
Note: Even after removing the delete field on delete object aggregator
we end up with an equivalent circular dep error which an object and its
field metadata identifier connection.
## Elegant `DEFERRED` and `DEFERRABLE` foreign keys
The most safe, low level solution would be to make all field relations
deferrable and start the runner transaction as deferred. But this
requires a quite invasive migration of existing FK
## On cascade solution
I've opted for the quick fix, on object or field deletion spread
cacasde.
It's pretty safe as the builder priorly validates the deletion and and
its related entities integrity
Only for both field and object deletion action types in v2 runner
## Integration coverage
Added a test that will scan a new workspace database core schema tables
and expect now result after workspace deletion through its only user
deletion
