### Summary
This PR removes an unused `view` import from **framer-motion** in
`useUpdateView.ts`.
---
### Context
- The unused import was introduced in the recent commit to `main`.
- It causes ESLint to fail, which blocks all new PRs from passing CI.
### Changes
- Removed unused `view` import from `framer-motion`.
### Impact
- Lint and CI should now pass again.
- No runtime behavior is affected.
Fixes https://github.com/twentyhq/twenty/issues/14445
## What
In the current `MenuItemWithOptionDropdown` component (which is a
MenuItem with the 3 dots dropdown), we used to have a position: static
on the 3 dots hovered.
This enabled the dropdown to not move when we scroll the MenuItems.
However, this is not playing well with the dropdown autoplacement.
I'm removing it as I think the right solution would actually to prevent
the scroll when the dropdown is open but this is non straight forward
and not really a big issue. I'm fine with the dropdown being "fixed" to
the scrollable content, it also makes sense
Before:
https://github.com/user-attachments/assets/8efec8fa-430a-408e-b549-fd7433b7a38d
After:
https://github.com/user-attachments/assets/b8ee4375-0944-4008-9ab6-f7f9f1d67e9c
## Testing
I was considering adding a story here but this is hard to test: hover +
scroll behavior are not well supported, I don't think it worth the
investment especially as I think the vision is to block the scroll
This componenent is used in ViewPicker and MultiItemsInput (ex.
PhonesFieldInput). I have check that both were still working well
Until we tackle [Implement relations depth 2 for rest
api](https://github.com/twentyhq/twenty/issues/14452), let's remove the
depth 2 query parameter which is not working (times out all the time).
Following https://github.com/twentyhq/twenty/pull/14306 , working on the
deprecation of objectRecordsPermissions + renaming of objectPermissions
-> objectsPermissions
In this PR
- Removal of objectRecordsPermissions (was not used in the FE any
longer)
- Addition of objectsPermissions, same as objectPermission but renamed.
objectPermission is no longer used in the FE.
Next step
- Remove unused objectPermissions
This PR refactors table resize with the new layout using flex-wrap to
manage all the table with divs.
Due to flex-wrap, we have to manually compute some filling divs like the
last column filler div or the empty table container, otherwise the
header can wrap and display on two lines, which is the only real issue
with this implementation with wrap.
Remember that **using flex-wrap is necessary** to handle z-index as we
want for the scrolling and hovered portal cell interaction UX. Otherwise
we lose the capacity to have z-index fine-tuning on very specific edge
cases.
To handle the resize, the most performant solution was to create CSS
variables for each column width on the table, creating a class for each
column, then assigning each class to all divs that are in the same
column, using the index of the array or the fixed known position index
for that.
This PR also refactors a lot of small details around the resizing, the
naming of the component and the DX.
It notably introduces a new hook : `useHTMLElementByIdWhenAvailable`,
that is very relies on MutationObserver API to get a native HTML element
as soon as it is rendered.
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
## Introduction
### Twenty-sever
Standardizing resolver input and transpilation models + return type on
destroy and delete
~~Finally~~ Did plug everything under a feature flag and add coverage
Next will do same for the view resolver and service v2
### Twenty-front
Refactored view field service in order to use codegenerated strictly
typed mutations and adapt to new api contract
## Context
Adding a new service that provides an abstract caching system for
FlatEntityMaps.
This takes care of cache invalidation and storing local and remote cache
for the map with retrieval after a comparison with map hash between
local and remote (redis).
## Implementation
Remote (redis) keys
- Flat map data:
`engine:workspace:flat-maps:{flatMapKey}:{workspaceId}:flat-map`
- Content hash:
`engine:workspace:flat-maps:{flatMapKey}:{workspaceId}:hash`
**Local Cache Hit**: If local hash matches Redis hash, return local data
**Remote Cache Hit**: If Redis has data with different hash, update
local cache
**Remote Cache Miss**: Recompute from database, store in Remote and
locally
**Invalidation**: Remove from Remote, triggering recomputation on next
access
## Usage
```typescript
@WorkspaceFlatMapCache('view') // redis key
export class WorkspaceFlatViewMapCacheService extends WorkspaceFlatMapCacheService<FlatViewMaps> {
constructor(
@InjectCacheStorage(CacheStorageNamespace.EngineWorkspace)
cacheStorageService: CacheStorageService,
@InjectRepository(ViewEntity)
private readonly viewRepository: Repository<ViewEntity>,
) {
super(cacheStorageService);
}
// only method to implement
public async computeFlatMap(workspaceId: string): Promise<FlatViewMaps> {
const views = await this.viewRepository.find({
where: { workspaceId },
relations: ['viewFields'],
select: { viewFields: { id: true } },
});
return generateFlatViewMaps(views);
}
}
```
```typescript
// 2 public methods, getExistingOrRecomputeFlatMaps to fetch the map and invalidateCache after a mutation
await this.workspaceFlatViewMapCacheService.invalidateCache(
viewData.workspaceId,
);
const flatViewMaps =
await this.workspaceFlatViewMapCacheService.getExistingOrRecomputeFlatMaps(
workspaceId,
);
```
## Multi-Pod Synchronization
- Each pod maintains local cache for performance
- SHA256 hash of flatMap content used for version comparison
- `invalidateCache()` reset Redis data, forcing other pods to refresh
when calling getExistingOrRecomputeFlatMaps
---
<img width="1072" height="325" alt="Screenshot 2025-09-11 at 15 04 48"
src="https://github.com/user-attachments/assets/ed6ce82c-db35-4a1b-8a4e-247b694e2ddf"
/>
<img width="1030" height="328" alt="Screenshot 2025-09-11 at 15 04 40"
src="https://github.com/user-attachments/assets/43a15789-7f27-4104-a9bb-bef19908a5cd"
/>
Next step: Implement a locking mechanism by reusing existing WithLock
decorator
This PR fixes the main resize bugs in
https://github.com/twentyhq/core-team-issues/issues/1453
Changes :
- A new `RecordTableResizeEffect` has been created to modify the last
column width to compensate for the resize width dynamically, because of
flew-wrap on the table elements, we cannot use width: 100% everywhere
and we have to set the width of everything.
- CSS transitions have been removed because they were degrading both the
performance and the UX when resizing
- Created a common `RecordTableHeaderCellContainer`, this was needed to
factorize the various table header components
- Created a `RecordTableHeaderLabelIdentifierCellPlusButton` component
to ease the reading of `RecordTableHeaderLabelIdentifierCell`
- Put the CSS of the blue line while resizing in the
`RecordTableHeaderResizeHandler` component to avoid duplicating it
everywhere.
- Extracted `COLUMN_MIN_WIDTH` in a constant file
Fixes https://github.com/twentyhq/core-team-issues/issues/1453
Closes https://github.com/twentyhq/twenty/issues/13854
In this PR
- When evaluating whether there was a soft delete filter enabled, we
were only taking into account the filter that shows all deleted records,
that can be enabled from the side panel ("See deleted records"). Now we
are also taking into account any filter on deletedAt.
- We lacked some places where we should not offer to add a new record if
a soft delete filter is on, ex on the empty page + in the kanban headers
- I decided not to add a constraint on api-side because I think there
could be use cases when importing data where we would want to be able to
create soft deleted records
# Context
We have recently migrated from workspace.views to core.views. While
doing it, we've lost the optimistic rendering on views in frontend. This
is an issue for viewField and viewGroups that are persisted without
having an intermediate storing layer (viewFilters, viewSorts,
viewFilterGroups are not directly persisted when we do the changes,
therefore we have an underlying layer to keep them and the optimistic
was implemented there already).
ViewFields have been treated in a previous PR, this PR focus on
ViewGroups
## What
Optimistic on ViewGroups
## Other
+ fix a bug in the sequencing to persist viewFilter + viewFilterGroups
## Context
We recently migrated from workspaceSchema.views to core.views. While
doing it we've migrated views using 1-5-migrate-views-to-core command
but we forgot to migrate the subFieldName
Closes: https://github.com/twentyhq/twenty/issues/14369
This PR closes the first step of
https://github.com/twentyhq/core-team-issues/issues/1451, about z-index
fine-tuning on the table.
The core part was to succeed in having the hovered portal and the
surrounding cells switch their z-index to have the borders overlap
nicely in all scrolling cases.
See associated video for the new behavior.
This PR fixes two majors UX issues we had :
- The sticky column and row were sliding a bit on the beginning of the
scroll
- Too many components were re-rendering while we only needed to isolate
those who presented a complex use case
In the end, we isolated some very specific components like the cell 0-0
and the first scrollable header cell, which were giving the most
problems with the hovered portal.
This allows to leave the rest of the cells and header cells alone with
those concerns because they weren't involved at all in z-index update,
once we isolated those components.
## Demo
https://github.com/user-attachments/assets/cbe630ed-63c3-4e86-a22e-a11662c6082chttps://github.com/user-attachments/assets/36e6947d-9f89-4ed2-ba6c-cbb13016d7d1
We decided to send 4xx errors to sentry from the FE, except for
ForbiddenErrors.
In some cases, we also need not to send to sentry some 4xx errors, like
user input error, because the error stemming from the user input is
unpredictable (ex: duplicate entry for a record with unicity
constraints) and thus acceptable.
Let's add a isExpected extension on UserInputErrors to introduce a
specific behaviour for them (do not send to sentry).
## Context
View system used to rely on workspaceSchema views and was loaded in what
we called the "prefetch". We have recently migrated views to
core.coreViews and the states should now be named after coreViews
Fixes: https://github.com/twentyhq/twenty/issues/14349
Previous refacto was creating output schema V2 which has more specific
schemas based on the step type. Before we were using one common schema,
which was too complex when searching for variable informations.
This PR migrate the deprecated schemas and remove the old code:
- mark previous `BaseOutputSchema` as deprecated
- remove other previous schemas
- use V2 everywhere
- icon should not be stored in schema. Instead it should be generated
based on the fieldmetadata or the item type
