Félix Malfait
f663cd3c68
Replaces the per-view "Open in" setting with a two-level model, following up on #23422 / #23424 and superseding the closed #23446 and #23457: - `objectMetadata.openRecordIn`: `SIDE_PANEL` | `RECORD_PAGE` | `USER_CHOICE` (default `USER_CHOICE`) - `workspaceMember.openRecordIn`: `SIDE_PANEL` | `RECORD_PAGE` (default `SIDE_PANEL`), editable in Settings > Experience The rule: records open where the member prefers, unless the object pins them, and never in a panel there is no room for (mobile always resolves to the record page). ## Why Having the setting on views, objects and members at once was heavy, and view-level resolution was fragile: a chip rendered outside a view (notes, front components, kanban cards pointing at another object) had no view to read from, which is the class of bug behind #23422. Resolution is now context-free: it needs only the object, the current member and the viewport, so chips behave identically everywhere by construction. ## Changes **Object level** - New `openRecordIn` enum column on `objectMetadata`, editable through `updateOneObject` and surfaced in Settings > Data model > Object > Layout ("Open records in": Member preference / Side Panel / Record Page) - Standard definitions pin `workflow`, `workflowVersion`, `dashboard` and `messageCampaign` to the record page (matching the previously hardcoded list) and `calendarEvent` to the side panel (it has no curated record page); everything else, including `workflowRun`, follows the member preference - Apps can set it in `defineObject()` via the object manifest **Member level** - New `openRecordIn` standard field on `workspaceMember`, persisted through the existing settings path (same as `colorScheme`) and exposed in Settings > Experience **View level (deprecated)** - `view.openRecordIn` is no longer read or written by the frontend; the "Open in" entry is gone from the view options dropdown - The column, DTO field and inputs are kept for one release for API compatibility: the output field carries a `deprecationReason`, the inputs keep accepting the value with a `Deprecated:` description (NestJS silently drops input fields that have a `deprecationReason`, which would have been a breaking change) **Upgrade (2.27)** - Fast instance command adds the `objectMetadata.openRecordIn` column defaulting to `USER_CHOICE` - Workspace command adds the `workspaceMember.openRecordIn` field - Workspace command seeds the object column from the standard definitions (any non-`USER_CHOICE` value), then lifts deliberate per-view record page choices onto objects the definitions don't pin **Debt removed** - `canOpenObjectInSidePanel` hardcoded object list and its test - `ObjectOptionsDropdownLayoutOpenInContent` and the `layoutOpenIn` dropdown wiring - `DefaultViewOpenRecordIn` - Context-store/view-based resolution in `useResolveOpenRecordIn` (now reads object metadata + member + viewport) - Front components no longer guess from the current view: an explicit side-panel call honours a pinned object and the viewport, nothing else ## Verification - Ran the three upgrade commands against a live database: column created, the pinned standard objects seeded per workspace (record page pins plus calendarEvent to side panel), member field backfilled to `SIDE_PANEL`; seed rerun is a no-op - Seed command verified on a simulated pre-upgrade workspace (index view set to record page on company): pins the standard objects plus company, idempotent on rerun - Both packages typecheck and lint clean; affected unit suites and the application sync, view creation and metadata cache integration specs pass --------- Co-authored-by: Thomas des Francs <tdesfrancs@gmail.com>
twenty-ui
Twenty's open-source React UI component library: components, icons, and design tokens built on a zero-runtime, CSS-variable styling layer.
Installation
npm install twenty-ui
react, react-dom, and monaco-editor are peer dependencies (install them in your app). monaco-editor is only required if you use the code editor components.
Usage
Import the base styles once, pick a theme stylesheet, and wrap your app in ThemeProvider:
import { ThemeProvider } from 'twenty-ui/theme-constants';
import { Button } from 'twenty-ui/input';
import 'twenty-ui/style.css';
import 'twenty-ui/theme-light.css';
export const App = () => (
<ThemeProvider colorScheme="light">
<Button title="Click me" />
</ThemeProvider>
);
Components are available from the root entry point or from a specific subpath for better tree-shaking:
import { Button } from 'twenty-ui';
import { Button } from 'twenty-ui/input';
Entry points
| Subpath | Contents |
|---|---|
twenty-ui |
All components, icons, theme tokens, and utilities |
twenty-ui/accessibility |
Accessibility helpers |
twenty-ui/assets |
Logos and static assets |
twenty-ui/data-display |
Avatars, chips, tags, and other display components |
twenty-ui/feedback |
Progress bars, loaders, and status feedback |
twenty-ui/icon |
Icon components and the icon provider |
twenty-ui/input |
Buttons, toggles, and form inputs |
twenty-ui/json-visualizer |
JSON tree viewer |
twenty-ui/layout |
Layout primitives |
twenty-ui/navigation |
Menus, links, and navigation components |
twenty-ui/surfaces |
Cards, tooltips, and surface components |
twenty-ui/testing |
Storybook and test decorators |
twenty-ui/theme |
Theme types and helpers |
twenty-ui/theme-constants |
Design tokens, ThemeProvider, and useTheme |
twenty-ui/typography |
Text and typography components |
twenty-ui/utilities |
Hooks and shared utilities |
Theming
twenty-ui/style.cssships the base reset and component styles. Import it once.twenty-ui/theme-light.cssandtwenty-ui/theme-dark.cssdefine the design-token CSS variables for each color scheme.ThemeProviderexposes the active theme throughuseTheme()and applies thelight/darkclass. PassapplyToRoot={false}withoverridesto scope a theme to a subtree instead of the document root.
Development
npx nx build twenty-ui # Build the library (dual ESM/CJS + types)
npx nx storybook:serve:dev twenty-ui # Run Storybook
npx nx test twenty-ui # Run unit tests
License
twenty-ui is released under the MIT license.