# Keyboard Navigation and Shortcuts Implementation on the board
This PR implements keyboard navigation and shortcuts for the Record
Board component, enabling users to navigate and interact with board
cards using keyboard inputs.
## Key changes
### Navigation Architecture
- Added `useBoardCardNavigation` hook for directional navigation (arrow
keys)
- Implemented scroll behavior to automatically focus visible cards
- Created card focus/active states with component-level management
### State Management
- Added new component states: `focusedBoardCardIndexesComponentState`,
`activeBoardCardIndexesComponentState`,
`isBoardCardActiveComponentFamilyState`
- Extended index tracking with column/row position indicators
- Create hooks to manage these states
### Hotkey Implementation
- Created new `RecordBoardHotkeyEffect` component for hotkey handling
- Added `BoardHotkeyScope`
- Implemented Escape key handling to clear selections
- Replaced table-specific `TableHotkeyScope` with more generic
`RecordIndexHotkeyScope`. This is because, before, the hotkey scope was
always set to Table inside the page change effect, and we used the table
hotkey scope for board shortcuts, which doesn't make a lot of sense.
Since we don't know upon navigation on which type of view we are
navigating, I introduced this generic hotkey scope which can be used on
the table and on the board.
### Page Navigation Integration
- Modified `PageChangeEffect` to handle both table and board view types
- Added cleanup for board state upon navigating away from record pages
### Component Updates
- Updated `RecordBoardColumn` to track indexes for position-based
navigation
- Added `RecordBoardScrollToFocusedCardEffect` for auto-scrolling to
focused cards
- Added `RecordBoardDeactivateBoardCardEffect` for cleanup
This implementation maintains feature parity with table row navigation
while accounting for the 2D navigation needs of the board view.
## New behaviors
### Arrow keys navigation
https://github.com/user-attachments/assets/929ee00d-2f82-43b9-8cde-f7bc8818052f
### Record selection with X
https://github.com/user-attachments/assets/0b534c4d-2865-43ac-8ba3-09cb8c121f06
### Command + Enter opens the record
https://github.com/user-attachments/assets/0df01d1c-0437-4444-beb1-ce74bcfb91a4
### Escape unselect the records and unfocus the card
https://github.com/user-attachments/assets/e2bb176b-b6f7-49ca-9549-803eb31bfc23
After reading the blocknote documentation :
- we decided to increase to 100% the lines width
- we decided to reduce as much as possible inner padding
- we decided it's on the parent to decide the padding of the richtext
The two last points are recommended in a discussion on the project
blocknote. This way clicking on padding won't trigger weird behaviour on
Chrome.
Fixes
https://github.com/twentyhq/core-team-issues/issues/827#issuecomment-2842350359
- Migrated all workflow Recoil states to component states to isolate
each workflow visualizer instance. The use case of having two workflow
visualizers displayed at the same time appeared recently and will grow
in the near future.
- We chose to use the `recordId` as the value for the `instanceId` of
the component states. Currently, there are a few cases where two
workflows or two workflow runs are rendered at the same time. As a
consequence, relying on the `recordId` is enough for the moment.
- However, there is one case where it's necessary to have a component
state scoped to a workflow visualizer instance: the
`workflowVisualizerStatusState`. This component is tightly coupled to
the `<Reactflow />` component instance rendered in the workflow
visualizer, and it must be set to its default value when the component
first renders. I achieved that by using another component instance
context whose instanceId is an identifier returned by the `useId()` hook
in the Workflow Run Card component.
Closes https://github.com/twentyhq/core-team-issues/issues/857
The issue was caused by the fact that the preview chip was accidentally
made clickable while not linked to any record id:
<img width="763" alt="Capture d’écran 2025-04-28 à 15 17 32"
src="https://github.com/user-attachments/assets/c1d9bf61-edcb-442f-a914-eccc627ee190"
/>
this was fixed by [this
PR](https://github.com/twentyhq/twenty/pull/11745) (@etiennejouan)
It was causing the side panel to open while the record id was empty,
while this recordId is used in query filters (as it should be to fetch
record data), leading the queries to fail.
Let's early return with an error instead as it does not make sense to
open the record page with an empty recordId.
---------
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
# Ability to navigate dropdown menus with keyboard
The aim of this PR is to improve accessibility by allowing the user to
navigate inside the dropdown menus with the keyboard.
This PR refactors the `SelectableList` and `SelectableListItem`
components to move the Enter event handling responsibility from
`SelectableList` to the individual `SelectableListItem` components.
Closes [512](https://github.com/twentyhq/core-team-issues/issues/512)
## Key Changes:
- All dropdowns are now navigable with arrow keys
## Technical Implementation:
- Each `SelectableListItem` now has direct access to its own `Enter` key
handler, improving component encapsulation
- Removed the central `Enter` key handler logic from `SelectableList`
- Added `SelectableList` and `SelectableListItem` to all `Dropdown`
components inside the app
- Updated all component implementations to adapt to the new pattern:
- Action menu components (`ActionDropdownItem`, `ActionListItem`)
- Command menu components
- Object filter, sort and options dropdowns
- Record picker components
- Select components
---------
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
This PR fixes a refactor that was done recently to avoid having
clickoutside listeners on the closed command menu.
The useScopedHotkey hook should have stayed in the command menu
container, because it should always listen.
This has been fixed.
> [!WARNING]
> I refactored a bunch of components into utility functions to make it
possible to display the `WorkflowStepHeader` component for **triggers**
in the `CommandMenuWorkflowRunViewStep` component. Previously, we were
asserting that we were displaying the header in `Output` and `Input`
tabs only for **actions**. Handling triggers too required a bunch of
changes. We can think of making a bigger refactor of this part.
In this PR:
- Only display the Flow for Workflow Runs; removed the Code Editor tab
- Allows users to see the Output of trigger nodes
- Prevent impossible states by manually setting the selected tab when
selecting a node
## Demo
### Success, Running and Not Executed steps
https://github.com/user-attachments/assets/c6bebd0f-5da2-4ccc-aef2-d9890eafa59a
### Failed step
https://github.com/user-attachments/assets/e1f4e13a-2f5e-4792-a089-928e4d6b1ac0
Closes https://github.com/twentyhq/core-team-issues/issues/709
This PR fixes many small bugs around the recent hotkey scope refactor.
- Removed unused ActionBar files
- Created components CommandMenuOpenContainer and
KeyboardShortcutMenuOpenContent to avoid mounting listeners when not
needed
- Added DEFAULT_CELL_SCOPE where missing in some field inputs
- Called setHotkeyScopeAndMemorizePreviousScope instead of
setHotkeyScope in new useOpenFieldInputEditMode hook
- Broke down RecordTableBodyUnselectEffect into multiple simpler effect
components that are mounted only when needed to avoid listening for
keyboard and clickoutside event
- Re-implemented recently deleted table cell soft focus component logic
into RecordTableCellDisplayMode
- Created component selector isAtLeastOneTableRowSelectedSelector
- Drill down hotkey scope when opening a dropdown
- Improved debug logs
# Description
Closes [#696](https://github.com/twentyhq/core-team-issues/issues/696)
- `useAction` hooks have been removed for all actions
- Every action can now declare a react component
- Some standard action components have been introduced: `Action`,
`ActionLink` and `ActionModal`
- The `ActionDisplay` component uses the new `displayType` prop of the
`ActionMenuContext` to render the right component for the action
according to its container: `ActionButton`, `ActionDropdownItem` or
`ActionListItem`
- The `ActionDisplayer` wraps the action component inside a context
which gives it all the information about the action
-`actionMenuEntriesComponenState` has been removed and now all actions
are computed directly using `useRegisteredAction`
- This computation is done inside `ActionMenuContextProvider` and the
actions are passed inside a context
- `actionMenuType` gives information about the container of the action,
so the action can know wether or not to close this container upon
execution
## What
- Deprecate overlayscrollbars as we decided to follow the native
behavior
- rework on performances (avoid calling recoil states too much at field
level which is quite expensive)
- Also implements:
https://github.com/twentyhq/core-team-issues/issues/569
---------
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
This PR fixes a bug that prevented to do the matching of an imported CSV
file that contains a SELECT type column.
Fixes https://github.com/twentyhq/twenty/issues/11220
## Stacking context improvement
During the development it was clear that we lacked a reliable way to
understand our own z indices for components like modal, portaled
dropdown, overlay background, etc.
So in this PR we introduce a new enum RootStackingContextZIndices, this
enum allows to keep track of our root stacking context component
z-index, and because it is an enum, it prevents any conflict.
See
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_positioned_layout/Stacking_context
for reference.
## Component cleaning
Components have been reorganized in a SubMatchingSelectRow component
The Dropdown component has been used to replace the SelectInput
component which doesn't fit this use case because we are not in a cell,
we just need a simple standalone dropdown, though it would be
interesting to extract the UI part of the SelectInput, to share it here,
the benefit is not obvious since we already have good shared components
like Tag and Dropdown to implement this specific use case.
---------
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
Co-authored-by: Félix Malfait <felix@twenty.com>
# Introduction
closes https://github.com/twentyhq/core-team-issues/issues/591
Same than for `twenty-shared` made in
https://github.com/twentyhq/twenty/pull/11083.
## TODO
- [x] Manual migrate twenty-website twenty-ui imports
## What's next:
- Generate barrel and migration script factorization within own package
+ tests
- Refactoring using preconstruct ? TimeBox
- Lint circular dependencies
- Lint import from barrel and forbid them
### Preconstruct
We need custom rollup plugins addition, but preconstruct does not expose
its rollup configuration. It might be possible to handle this using the
babel overrides. But was a big tunnel.
We could give it a try afterwards ! ( allowing cjs interop and stuff
like that )
Stuck to vite lib app
Closed related PRs:
- https://github.com/twentyhq/twenty/pull/11294
- https://github.com/twentyhq/twenty/pull/11203
Closes https://github.com/twentyhq/core-team-issues/issues/690
This PR is the first part of a refactoring on the actions system
https://github.com/twentyhq/core-team-issues/issues/683. It:
- Removes `shouldBeRegistered` from the useAction hook
- Instead `shouldBeRegistered` becomes a function to which we can pass
parameters which describe the context of the app (the object, the
selected record, information about favorites ...). It returns a boolean.
- `useShouldActionBeRegisteredParams` returns the parameters to pass to
the `shouldBeRegistered`
- Introduces a way to inherit actions from the default config and to
overwrite its properties, closing
https://github.com/twentyhq/core-team-issues/issues/72
Some tests testing if an action was registered correctly have been
removed, we should add them back at the end of the global refactoring.
# Description
I previously introduced the `RecordTitleCell` component, but it was
coupled with the field context, so it was only usable for record fields.
This PR:
- Introduces a new component `TitleInput` for side panel pages which
needed to have an editable title which wasn't a record field.
- Fixes the hotkey scope problem with the workflow step page title
- Introduces a new hook `useUpdateCommandMenuPageInfo`, to update the
side panel page title and icon.
- Fixes workflow side panel UI
- Adds jest tests and stories
# Video
https://github.com/user-attachments/assets/c501245c-4492-4351-b761-05b5abc4bd14
On default objects:
- Add see workflows
On workflows:
- Add see all runs (no selection)
On workflow runs:
- Add see workflows (no selection)
- Add see linked workflow (single record selection)
- Add see run version (single record selection)
On workflows versions
- Add see all runs (no selection)
- Add see workflows (no selection)
- Add see linked workflow (single record selection)
- Add see linked runs (single record selection)
- Wrap the content of Workflow View, Workflow Edit, and Workflow Run
side panels with a container making them take all the available height
- Remove the `StyledContainer` of code steps as it's redundant with the
global container
- Add the WorkflowStepHeader to the input and output tabs
- Make the JSON visualizer take all the available height in input and
output tabs
- Reuse the WorkflowStepBody component in the input and output tabs as
it applies proper background color
## Demo
Fixes
https://discord.com/channels/1130383047699738754/1351906809417568376
---------
Co-authored-by: Thomas Trompette <thomas.trompette@sfr.fr>
# Introduction
In this PR we've migrated `twenty-shared` from a `vite` app
[libary-mode](https://vite.dev/guide/build#library-mode) to a
[preconstruct](https://preconstruct.tools/) "atomic" application ( in
the future would like to introduce preconstruct to handle of all our
atomic dependencies such as `twenty-emails` `twenty-ui` etc it will be
integrated at the monorepo's root directly, would be to invasive in the
first, starting incremental via `twenty-shared`)
For more information regarding the motivations please refer to nor:
- https://github.com/twentyhq/core-team-issues/issues/587
-
https://github.com/twentyhq/core-team-issues/issues/281#issuecomment-2630949682
close https://github.com/twentyhq/core-team-issues/issues/589
close https://github.com/twentyhq/core-team-issues/issues/590
## How to test
In order to ease the review this PR will ship all the codegen at the
very end, the actual meaning full diff is `+2,411 −114`
In order to migrate existing dependent packages to `twenty-shared` multi
barrel new arch you need to run in local:
```sh
yarn tsx packages/twenty-shared/scripts/migrateFromSingleToMultiBarrelImport.ts && \
npx nx run-many -t lint --fix -p twenty-front twenty-ui twenty-server twenty-emails twenty-shared twenty-zapier
```
Note that `migrateFromSingleToMultiBarrelImport` is idempotent, it's atm
included in the PR but should not be merged. ( such as codegen will be
added before merging this script will be removed )
## Misc
- related opened issue preconstruct
https://github.com/preconstruct/preconstruct/issues/617
## Closed related PR
- https://github.com/twentyhq/twenty/pull/11028
- https://github.com/twentyhq/twenty/pull/10993
- https://github.com/twentyhq/twenty/pull/10960
## Upcoming enhancement: ( in others dedicated PRs )
- 1/ refactor generate barrel to export atomic module instead of `*`
- 2/ generate barrel own package with several files and tests
- 3/ Migration twenty-ui the same way
- 4/ Use `preconstruct` at monorepo global level
## Conclusion
As always any suggestions are welcomed !
- create a form filler component
- send the response on submit
- put back a field name. We need it for the step output
- validate a form is well set before activation
TODO:
- we need to refresh to see the form submitted. We need to discuss about
a strategy
- the response is not saved in the step settings. We need a new endpoint
to update workflow run step
https://github.com/user-attachments/assets/0f34a6cd-ed8c-4d9a-a1d4-51455cc83443
The old `useListenClickOutside` API allowed us to pass a hotkeyScope as
a parameter, the click outside was triggered only if the current hotkey
scope matched the parameter. We don't want this anymore. This fixes a
few bugs related to hotkey scopes inside the side panel.
Workflows step details in workflows and versions should be different
from the node tab in run. For most cases, it was using the same
component. But for forms, it will be a different one.
This PR:
- renames form action into formBuilder. formFiller is coming
- put code into a separated folder
- creates a new component for node details
Fixes#11038
# Fix useFindManyRecords withSoftDeleterFilter
The error came from a faulty implementation of the `withSoftDeleted`
parameter inside `useFindManyRecords` and from the fact that
`withSoftDeleted: true` was added to access deleted records actions.
However, this parameter was always set in
`useFindManyRecordsSelectedInContextStore` instead of considering
whether the filter was active or not.
```
const withSoftDeleterFilter = {
or: [{ deletedAt: { is: 'NULL' } }, { deletedAt: { is: 'NOT_NULL' } }],
};
```
The final filter was incorrectly doing an `or` operation between the
base filter and `withSoftDeleterFilter` when it should have been an
`and`:
```
filter: {
...filter,
...(withSoftDeleted ? withSoftDeleterFilter : {}),
}
```
The correct implementation should be:
```
filter:
filter || withSoftDeleted
? {
and: [
...(filter ? [filter] : []),
...(withSoftDeleted ? [withSoftDeleterFilter] : []),
],
}
: undefined,
```
# Fix useFindManyRecordsSelectedInContextStore
- Check if the soft deleted filter is active before using the
`withSoftDeleterFilter` parameter
Chores #6389
## Description
This PR addresses inconsistencies in the codebase where elements that
visually function as labels were implemented with custom-styled
components rather than the standardized Label component from the UI
library.
## Changes
I've replaced several custom-styled text elements with the standardized
Label component from twenty-ui to improve consistency and
maintainability across the application. These modifications maintain the
same visual appearance and functionality while standardizing the
implementation.
## Components Modified:
InputLabel: Converted from a styled label to use the Label component
InputHint: Replaced styled div with a styled Label component
TableSection: Introduced a StyledLabel using the Label component for
section headings
StyledDropdownMenuSubheader: Converted from a styled div to a styled
Label component
NavigationDrawerSectionTitle: Replaced internal text element with the
Label component
SettingsCard: Updated description element to use the Label component
SettingsListItemCardContent: Changed description span to use the Label
component
RecordDetailSectionHeader: Added a StyledLabelLink for link text using
the Label component
TaskList: Modified the task count display to use the Label component
CommandGroup: Updated group headings to use the Label component
WorkerMetricsGraph: Replaced no-data message with a Label-based
component
ViewPickerSelectContainer: Changed from a styled div to a styled Label
component
---------
Co-authored-by: Félix Malfait <felix@twenty.com>
