Step operand will more or less be the same as view filter operand.
This PR:
- moves `ViewFilterOperand` to twenty-shared
- use it as step operand
- check what operand should be available based on the selected field
type in filter action
- rewrite the function that evaluates filters so it uses
ViewFilterOperand instead
ViewFilterOperand may be renamed in a future PR.
to resolve the issue #13047
It's my first contribution, I hope it's good enough!
When using the slash command (/) in the notes editor, a menu of commands
appears. When navigating this menu with the up and down arrow keys, the
selection changes, but the menu itself does not scroll. This means that
as the list of commands is long, items outside the visible area cannot
be seen when selected.
The issue was located in the [CustomSlashMenu.tsx] component. The menu
container didn't have vertical scrolling enabled, and there was no logic
to scroll the active item into the visible area.
The fix involved:
Adding overflow-y: auto to the menu's styled container in
[CustomSlashMenu.tsx].
Modifying the [DropdownMenuItemsContainer] component to accept and
forward a ref using React.forwardRef.
Implementing a useEffect hook in [CustomSlashMenu.tsx] that triggers on
selection change. This hook uses a ref to the items container to call
scrollIntoView({ block: 'nearest' }) on the currently selected menu
item.
---------
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
In the BE we throw custom errors with precise error codes (e.g.
"LABEL_ALREADY_EXISTS") before catching them in filters and rethrowing
BaseGraphQLErrors (standard errors such as NotFoundError, UserInputError
etc.).
In the FE we were grouping sentries based on the error codes but we were
actually grouping by very broad codes such as "NOT_FOUND" or
"BAD_USER_INPUT", extracted from the BaseGraphQLErrors.
To fix that, we update the BaseGraphQLError constructor api to allow to
pass on the CustomError directly and retrieve from it the original code
and store it in existing property `subCode` that we will use in the FE
to send errors to sentry.
This new api also eases usage of `userFriendlyMessage` that is passed on
to the api response and therefore to the FE when CustomError is passed
on directly to the BaseGraphQLError constructor.
Large PR, sorry for that. Don't hesitate to reach me to have full
context (env. 500lines for integration and unit tests)
- Add connect logic in Workspace Entity Manager
- Update QueryDeepPartialEntity type to enable dev to use connect
- Add integration test on createOne / createMany
- Add unit test to cover main utils
- Remove feature flag on connect
closes https://github.com/twentyhq/core-team-issues/issues/1148
closes https://github.com/twentyhq/core-team-issues/issues/1147
I rebuilt the advanced filters used in views and workflow search for a
specific filter step.
Components structure remains the same, using `stepFilterGroups` and
`stepFilters`. But those filters are directly sent to backend.
Also re-using the same kind of states we use for advanced filters to
share the current filters used. And a context to share what's coming
from workflow props (function to update step settings and readonly)
⚠️ this PR only focusses on the content of the step. There is still a
lot to do on the filter icon behavior in the workflow
https://github.com/user-attachments/assets/8a6a76f0-11fa-444a-82b9-71fc96b18af4
This PR fixes a bug that happened when adding a field to a table right
after a field creation in the data model settings.
This happened because the backend adds the newly created field to all
relevant views without telling the frontend (because we don't have web
sockets yet), so the frontend ended up in a stale state, and when the
user added the field manually to a view the backend rightly threw an
error telling that the view field it already existed.
So the fix is just to refetch all views after a field creation, sparing
us the difficult work of manually updating the Apollo cache.
Fixes https://github.com/twentyhq/twenty/issues/13071
In this PR
- introduction of fieldPermission entity
- addition of upsertFieldPermission in role resolver
- computing of permissions taking fieldPermission into account. In order
to limit what is stored in Redis we only store fields restrictions. For
instance for objectMetadata with id XXX with a restriction on field with
id YYY we store:
`"XXX":{"canRead":true,"canUpdate":false,"canSoftDelete":false,"canDestroy":false,"restrictedFields":{"YYY":{"canRead":false,"canUpdate":null}}}`
---------
Co-authored-by: Charles Bochet <charlesBochet@users.noreply.github.com>
## Expected behavior
Described behavior regarding: (update | create) x (custom | standard) x
(icon, label, name, isSynced)
**Custom:**
- Field RELATION create: name, label, isSynced, icon should be editable
- Field RELATION update: name should not, icon label, isSynced should
- For other fields, icon, label, name, isSynced should be editable at
field creation | update
To simplify: Field RELATION name should not be editable at update
**Standards**
- Field: create does not makes sense
- Field: name should not, icon label, isSynced should (this will end up
in overrides)
To simplify, no Field RELATION edge case, name should not be editable at
update
**Note:** the FE logic is quite different as the UI is hiding some
details behind the syncWithLabel. See my comments and TODO there
## What I've tested:
(update | create) x (custom | standard) x (icon, label, name, isSynced,
description)
This PR addresses feedback from
[PR-13061](https://github.com/twentyhq/twenty/pull/13061).
- Removed redundant type assertion from `apollo.factory.ts`.
- Removed redundant tests: Eliminated test cases that were specifically
added to boost coverage metrics rather than testing meaningful
functionality
This PR removes useDropdown barrel hook and refactors the legacy
useDropdown states to the last version of our recoil component state
management.
---------
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
This is not the prettiest fix but it's the 5th time I get the feedback
from a user that these fields should be readonly, let's have a special
case for them
---------
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
Pass the dropdownId into every closeDropdown() call so the instance ID
is always defined and the error no longer occurs.
---------
Co-authored-by: prastoin <paul@twenty.com>
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
resolve#11075
The issue was that when inline cells or table cells are in edit mode, a
click outside event listener is active, and its callback calls
event.stopImmediatePropagation(). This prevents the onClick of LinkChip
from firing, allowing the browser's default behavior to trigger the 'to'
link and cause a full page reload.
To fix this, I added event.preventDefault() inside each click outside
callback to stop the browser from reloading.
Another possible solution: check if currentTableCellInEditModePosition
or isInlineCellInEditMode is true, and if so:
Either convert the StyledLink in LinkChip into a div
Or set forceDisableClick = true, which falls back to AvatarChip.
Before:
https://github.com/user-attachments/assets/7ffd76fd-988e-484b-bad6-10e0147502c2
After:
https://github.com/user-attachments/assets/18cfbc0e-8af6-4ecc-862e-a2b8f02e2535
---------
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
This PR fixes a UI bug where the "Quote" item in the slash command menu
was displayed without an icon.
The root cause was that the IconBlockquote component, while available in
the icons library, was not being exported from the internal twenty-ui
package.
## Before / After
## Changes:
- Exported IconBlockquote from TablerIcons.ts in the twenty-ui package.
- Updated getSlashMenu.ts in the twenty-front package to import and use
the IconBlockquote for the "Quote" menu item.
This PR is raised to close the issue #13044
But there are some doubts that needs to be approved.
If the fields are not custom then we were saving the changes in
**standardOverrides** obj in which only three fields are
overridableFields **label, icon & description** can be updated for a
field.
You can see this in _before-update-one-field.hook.ts_ on line 85
```ts
const overridableFields = ['label', 'icon', 'description'];
```
If the field to be updated are from these three we are putting this in a
**standardOverrides** obj and passing it
However in our _field-metadata.service.ts_ file. We have **updateOne**
function inside it we have wrote a condition if **isCustom** is false
then the purpose was to build the updatableFields from the
**standardOverrides** obj that we got in **fieldMetadataInput** but
there was an error in it. As you can see below
```ts
const updatableFieldInput =
existingFieldMetadata.isCustom === false
? this.buildUpdatableStandardFieldInput(
fieldMetadataInput,
existingFieldMetadata,
)
: fieldMetadataInput;
```
However, the issue was that we were placing the entire
**standardOverrides** object inside **updatableFieldInput** again —
instead of merging its individual fields (label, icon, description)
directly into the update payload.
This PR fixes that by correctly applying the overrides into the
top-level object.
Please refer to the file changes for the full context.
But the thing i don't know.
[ ] - Is this the correct expected flow??
[ ]- Will this change break anything elsewhere?
I still have doubts on these two. Let me know if I missed something.
---------
Co-authored-by: Jagss24 <btwitsjagannat12@gmail.com>
Co-authored-by: Charles Bochet <charles@twenty.com>
Context :
- Phones import is a bit complex if not all subfields are provided.
- Phones subfield validation are absent or different from BE validation.
Solution :
- Normalize callingCode and countryCode validation (BE/FE)
- Ease phone import if only phoneNumber is provided
## Summary
- Fixes#12893 - Workspace switcher button now aligns properly with
record index headers when navigation drawer is collapsed
- Maintains consistent button height in both expanded and collapsed
states
- Simple CSS fix that improves visual consistency
## Fix Details
The issue was caused by the workspace switcher button changing height
from 20px (expanded) to 16px (collapsed). This created misalignment with
the page headers.
Changed in `MultiWorkspacesDropdownStyles.tsx`:
```tsx
// Before - height changed based on drawer state
height: ${({ theme, isNavigationDrawerExpanded }) =>
isNavigationDrawerExpanded ? theme.spacing(5) : theme.spacing(4)};
// After - consistent height
height: ${({ theme }) => theme.spacing(5)};
```
## Visual Alignment
- Workspace switcher button: 20px height (theme.spacing(5))
- Maintains alignment with record index headers in collapsed state
- Consistent with Figma design requirements
## Test Plan
- [x] Collapsed navigation drawer - workspace switcher aligns with
headers
- [x] Expanded navigation drawer - no visual regression
- [x] Button functionality remains unchanged
---
🤖 This fix was implemented using [Claude Code](https://claude.ai/code)
by Jez (Jeremy Dawes) and Claude working together\!
Thanks to the Twenty team for the great project\! 🚀
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: ehconitin <nitinkoche03@gmail.com>
Co-authored-by: nitin <142569587+ehconitin@users.noreply.github.com>
Co-authored-by: Charles Bochet <charles@twenty.com>
resolve#12662
This PR enables exporting deleted records by detecting when deleted view
mode is active and adding deletedAt: { is: 'NOT_NULL' } to
graphqlFilter.
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
This PR fixes a bug that forced all title cell to behave as if they were
in a show page, but we have workflow page breadcrumb that is not a show
page title.
Fixes https://github.com/twentyhq/twenty/issues/13041
This PR fixes a mismatch between the filter operation we have on NUMBER
and RATING field types, and the labels we use for those filters in the
application.
What is actually used is :
- Greater than or equal
- Less than or equal
But unfortunately, until now we display "less than" and "greater than"
everywhere.
This PR fixes that.
We would still have to change the value that is saved in viewFilter
table from `greaterThan` to `greaterThanOrEqual` and likewise for less
than, but it would require a careful migration, and for now just
changing the display labels is enough.
See follow-up issue for migration of the DB values :
https://github.com/twentyhq/core-team-issues/issues/1196
Fixes https://github.com/twentyhq/twenty/issues/13000
