This PR fixes many bugs on advanced filters, the goal here was to have
CRUD working with other simple filters and sorts.
In order to test this PR you'll have to run a sync metadata.
Fixes https://github.com/twentyhq/core-team-issues/issues/560
## Changed positionInViewFilterGroup field metadata type
This PR changes the type of positionInViewFilterGroup to NUMERIC instead
of POSITION, there certainly was a confusion during the initial
development, where POSITION type seemed relevant but it is not for this
particular feature because the position in a view filter group is not
the position of a record, which is used for displaying and re-ordering
purpose in table and kanban views.
Here the positionInViewFilterGroup is a specific position concept tied
to a custom feature, and it is handled by the specific logic of this
advanced filter dropdown layout.
## Create new ids when duplicating a view
When we use create view from an existing view, the logic in
useCreateViewFromCurrentView will copy over filters, filter groups and
sorts. The problem is that it copies it with the same ids, and that if
the backend manages somehow to create new ids, the ids that are put in
parentViewFilterGroupId are corresponding to the old filter groups not
the duplicated new ones.
So we had to create a map of old id => new id so that everything that
has to be sent to the backend for creation already has the same mapping
of parent id but with new ids generated by the frontend.
## Bug with creating a simple filter
We couldn't create a simple filter when advanced filters were set, this
was because of findDuplicateRecordFilterInNonAdvancedRecordFilters which
wasn't doing what it's naming tells, it wasn't filtering on simple
filters only before looking for duplicates.
## Clean code
- Use lastChildPosition directly from
useChildRecordFiltersAndRecordFilterGroups instead of drilling it down
- Refactored AdvancedFilterDropdownButton to extract the code lower
where it is really needed in AdvancedFilterChip
- Renamed a few View to Record naming where relevant
This PR fixes hotkey escape on advanced filter dropdown, which wasn't
working.
It adds a parameters to openDropdown, because in this particular case,
the dropdown is not opened from its clickable component but from an
openDropdown, in that case it wasn't possible for openDropdown to know
which hotkey scope to take, because the hotkey scope is generally passed
in the Dropdown component props.
We might want to find a more robust solution, where a dropdown knows its
hotkey scope without having to be mounted.
---------
Co-authored-by: Raphaël Bosi <71827178+bosiraphael@users.noreply.github.com>
This PR is a follow-up of https://github.com/twentyhq/twenty/pull/10612
where the method of computation of total count was only taking records
fetched on the front end.
In this PR we use `totalCount` returned by `useFindManyRecords` instead,
which returns the total count in DB for the given filters.
We also set `shouldMatchRootQueryFilter` on board card create mutation
to avoid optimistic rendering issues.
Fixes https://github.com/twentyhq/twenty/issues/10598
This PR improves advanced filter code and fixes the bug that prevented
the creation of a filter group.
On the debugging side :
- Adding an advanced filter rule to create a group now works
On the refactoring side :
- We now use AdvancedFilterRecordFilterGroupChildOptionsDropdown to
clarify the code that show the option dropdown of a group.
- Refacatored useCurrentViewViewFilterGroup to
useChildRecordFiltersAndRecordFilterGroups. It is now using only
RecordFilter and RecordFilterGroup type instead of view types. It also
exports recordFilters and recordFilterGroups alone, when they are
children of a group, so we don't have to extract them from the merged
array that is typed RecordFilter | RecordFilterGroup, which is necessary
for displaying a group.
- Two typeguards have been introduced to help discern RecordFilter from
RecordFilterGroup : isRecordFilterGroupChildARecordFilterGroup and
isRecordFilterGroupChildARecordFilter, this allows to remove any typing
on child processing.
- Renaming from view to record (but there are still some left)
This PR removes the legacy useGetCurrentView hook that still returned
view with combined filters and sorts, which we don't use anymore.
This allows to remove a bug where we couldn't select the "open in"
settings of a view.
This PR partially fixes advanced filters that were not working even with
feature flag activated.
Bugs fixed here :
- Advanced filters are not applied
- Root advanced filters cannot be created
- Cannot close advanced filters dropdown
- Can create multiple times the same non-advanced filter (reserved for
advanced filters)
upsertRecordFilter and removeRecordFilter have been refactored to take
record filter id instead of field metadata id, because the user should
be allowed to apply multiple filters for the same field.
We now base view filter CRUD directly on id, otherwise it could lead to
inconsistencies between advanced filters and simple filters.
This PR also refactors an important hook :
computeRecordGqlOperationFilter, so that it takes an object instead of
multiple params.
There are still bugs left, they will be taken in other PRs.
This PR implements CRUD for view filter groups with the new logic as
already done for view filters and view sorts.
It also completely removes the old combined view filter group states and
usage.
This PR is quite big but the impact is limited since it only changes
advanced filters module, which is under feature flag at the moment, and
it is already in a broken state so unusable, even if someone activates
the feature flag.
This PR implements hooks and utils logic for handling CRUD and view
filter group comparison.
The main hook is useAreViewFilterGroupsDifferentFromRecordFilterGroups,
like view filters and view sorts.
Inside this hook we implement getViewFilterGroupsToCreate,
getViewFilterGroupsToDelete and getViewFilterGroupsToUpdate.
All of those come with their unit tests.
In this PR we also introduce a new util to prevent nasty bugs happening
when we compare undefined === null,
This util is called compareStrictlyExceptForNullAndUndefined and it
should replace every strict equality comparison between values that can
be null or undefined (which we have a lot)
This could be enforced by a custom ESLint rule, the autofix may also be
implemented (maybe the util should be put in twenty-shared ?)
This PR fixed ViewBar chips that were using margin instead of padding
and gaps.
This SortOrFilter chip was using margin left to space itself where it
was the role of the view bar to handle gap between chips and
padding-left at the beginning.
This PR implements the initialization of current record filter groups
state from view.
It also implements mapRecordFilterGroupToViewFilterGroup,
mapRecordFilterGroupLogicalOperatorToViewFilterGroupLogicalOperator and
mapViewFilterGroupLogicalOperatorToRecordFilterGroupLogicalOperator with
their corresponding unit tests.
Some unused states not caught by ESLint are also removed.
This PR fixes a leftover from the removal of combined filters and sorts.
Board request hook was still relying on combinedViewSorts, here we just
use currentRecordSorts instead and it works well.
This PR implements a parallel code path to upsert and remove record
filter groups.
Those record filter groups aren't keeping track of the view id but since
they are in a view context, it's implicit that the advanced filter
feature can keep track of view for record filter groups.
We'll need record filter group for an upcoming feature without views, so
we need to abstract record filter group from view.
We have viewFilterGroup.id === recordFilterGroup.id, so it's easy to map
each other.
This PR simply implements record filter group states and context, as we
did for record filter and record sort.
We use a separate context for record filter and record filter group,
we'll see later if it can be merged in practice, but better be cautious
for now.
This PR removes what's left from record filter and record sort previous
logic to handle CRUD and state management with view.
So everything that is named combinedFilter and combinedSort is removed
here.
We implement currentRecordFilters and currentRecordSorts everywhere.
We also remove the event in a state onSortSelectComponentState. (a
pattern we want to avoid)
This PR implements new record sorts CRUD as already done on record
filters, which is based on record sorts state instead of combined view
sorts.
It implements a new useSaveRecordSortsToViewSorts with its underlying
utils, to compute diff between two view sorts array.
The associated unit tests have also been written.
This PR also fixes the bug where the view bar disappeared when deleting
the already saved record sort of a view.
This PR adds the same synchronization utils and hooks from view to
record sorts, as we did with view and record filters.
The goal is to apply what's in the view sorts only when needed.
Also added tests for those utils and hooks.
We also add useRemoveRecordSorts.
This PR implements a parallel code path to set record sorts without
impacting the actual sort, like we did on record filter.
We add a ViewBarRecordSortEffect which mirrors
ViewBarRecordFilterEffect.
It also adds availableFieldMetadataItemsForSortFamilySelector to replace
sortDefinitions progressively.
This PR is simple, it creates states for record sort, mirroring record
filter states.
It also implements RecordSortsComponentInstanceContext everywhere
RecordFiltersComponentInstanceContext is used.
This could be later merged into a common RecordContext concept but we
first need to decide how to handle the existing ContextStore and
RecordIndexContext and ideally end up with a unique context (or a
context provider component that wraps in all those contexts at once).
Some bugs are already present on main when trying to delete a sort, they
will be fixed in the next PRs.
This PR fixes sorts on table and board.
The sorts were not taken into account due to the recent view refactor
that had the side effect of removing the synchronization between
recordSortsState and changing the state.
The fix was to use combined view sorts instead, which are currently the
source of truth for sorts.
Also added a confirmation modal for manual sorting on board.
This PR fixes a bug that happens when switching from an object to
another.
It is a temporary fix because it fixes a problem downstream, that
shouldn't happen, but it is tied to the new implementation of the main
context store.
We should find a way to have context store states defined earlier
because it might impact logic that was developed during the previous
months that didn't anticipated the state of current view id taking more
re-renders to be correctly set between page change / table change.
This PR enforces objectMetadataItem to be passed to hook
useColumnDefinitionsFromFieldMetadata, which was never used without an
objectMetadataItem passed in parameters (and probably shouldn't anyway)
Removed the associated test that tested for an undefined
objectMetadataItem parameter in useColumnDefinitionsFromFieldMetadata.
This allows to remove the need to rely on recordIndexContext to retrieve
the filterableFieldMetadataItems.
This PR essentially removes the usage of filterDefinition.type, by
replacing it with fieldMetadataItem.type derivation. Thus allowing to
completely remove filterDefinition later on.
In computeFilterRecordGqlOperationFilter, emptyOperationFilter is now
returned before going into the big switch case. This avoids repeating
the same exact call to getEmptyRecordGqlOperationFilter for each type.
Fixed some tests that need
getJestMetadataAndApolloMocksAndActionMenuWrapper to have record filters
properly working with the new implementation. We'll probably want to
refactor the record context store, record index context, etc.
Co-authored-by: Charles Bochet <charlesBochet@users.noreply.github.com>
This PR fixes a bug where setting an aggregate in the footer of a record
table makes the currentRecordFilters state being overwritten by the
view, which we don't want.
This PR fixes a bug that happened when we open the command menu with
multiple records selected.
The problem was that the new useCheckIsSoftDeleteFilter hook depended on
RecordIndexContext which can be undefined in the command menu context.
Because our direction right now is not completely clear with
RecordIndexContext and ContextStore, in this PR I just removed the
dependency and used objectMetadataItems state directly so that the hook
has no dependency anymore.
Also renamed useFilterableFieldMetadataItems to
useFilterableFieldMetadataItemsInRecordIndexContext.
This PR adds a useCheckIsSoftDeleteFilter hook instead of the
undocumented in-place logic to retrieve the soft delete filter.
Also took the opportunity to refactor a recent change of @prastoin with
it.
Split VariantFilterChip into SoftDeleteFilterChip and RecordFilterChip
to separate concerns about this soft delete filtering.
This PR progressively introduces fieldMetadataItemUsedInDropdown instead
of filterDefinitionUsedInDropdown where most easy to replace.
This allows to use `fieldMetadataItemUsedInDropdown.id` instead of
`filterDefinition.fieldMetadataId`, which is one easy dependency to
remove on filter definition.
We still derive filterDefinition instead of fully replacing it, because
it will be easier to remove RecordFilterDefinition usage in a bottom-up
approach instead.
In multiple components of the filter dropdown, we try to replace
filterDefinition by fieldMetadataItem derivation : Icon, label, id,
type, etc.
We also introduce the usage of subFieldNameUsedInDropdown instead of
storing it dynamically on filterDefinition, for handling filtering on
composite sub fields.
The method `formatFieldMetadataItemAsFilterDefinition()` that is used to
derive filterDefinition from fieldMetadataItem is what was being used
originally to create the availableFilterDefinition state. (That is
already removed)
Fixed associated unit tests accordingly.
Implements filtering, ordering and cursor filtering for the hook
useCombinedFindManyRecords, because it was not implemented, which was
misleading because variables could be passed to it.
The difficult part was to make sure that the cursor filtering was
working, both before and after a cursor, because it was only hard coded
for last cursor (equivalent to after).
The duplicate limit parameter in the type RecordGqlOperationVariables
was merged into one limit parameter, because it was making the developer
guess how both could be handled.
This single limit parameter can be used for either : general limit
without cursor, first records from after cursor, last records until
before cursor. Since those cases are exclusive it's better to have only
one limit parameter and have an internal logic handling those cases.
Tests were added on the relevant parts, especially
useCombinedFindManyRecordsQueryVariables which requires its own unit
test to handle this cursor + limit logic.
Record show page pagination was tested to make sure removing the
duplicate limit parameter had no impact.
With the introduction of dropdown focus id, the table header cell filter
dropdown wasn't taken into account by this new system that prevents
multiple dropdowns from conflicting.
The fix was to just add a dropdown focus id when opening the dropdown.
There was also a bug with the hotkey scope which was staying on table
hotkey scope, thus triggering table hotkeys, this PR also fixes that.
The global record filter refactor will derive everything at runtime from
objectMetadataItemsState, thus removing the need for a filter definition
concept.
Here we don't yet remove available filter definition usage but we
replace the available filter definitions states, we now derive the same
value from objectMetadataItemsState.
This will allow us to progressively remove the usage of the concept of
filter definition, at the end it will then be easy to just remove from
the codebase because nothing will use it anymore.
This PR doesn't remove or change the current behavior of the filter
definition used in filter dropdown, but adds a parallel code path where
we set the field metadata item used in filter dropdown, which is enough
to replace the filter definition.
The goal at the end is to compute dynamically the equivalent of filter
definition where needed, by deriving from objectMetadataItems global
state + fieldMetadataItemId used in dropdown, that way we don't create
any other source of truth for the concept of filter definition and
everything is easier to work with, especially with advanced filters.
The general spirit is that it's always better to derive everywhere from
a unique state as much as possible, and only create the equivalent of
selectors where needed that will only take the relevant chunk of state
for the small zone of the code operating some reading/writing.
- Added utils and hooks to get a FieldMetadataItem more easily
- Removed some properties from RecordFilterDefinition (the easiest to
remove) and replaced them with a dynamic logic, deriving what's needed
where it is needed
- Added a new fieldMetadataItemIdUsedInDropdownComponentState that is
set in parallel of filterDefinitionUsedInDropdown (to prepare the
removal of filter definition used in dropdown)
- Fixed some stories
---------
Co-authored-by: Raphaël Bosi <71827178+bosiraphael@users.noreply.github.com>
This PR refactors the record filter saving to view filters.
Before we used states to track the change of view filters, now we just
check if there's a difference between the current record filters and the
current view filters before saving.
We also use this check to show the reset and save buttons.
CRUD operations to perform on view filters are computed by utils , and .
Also added unit tests on those utils.
This PR implements a first real use case, now currentRecordFilters
component state acts as the global record filter reference.
It is set by the view initially and can be reset to view filters state
at any point.
This new state is also modified by two new upsertRecordFilter /
removeRecordFilter hooks that will be drop-in replacement of the actual
upsertCombinedViewFilter and removeCombinediewFilter hooks.
This PR implements the logic to manipulate record filters but only reads
it to make the table find many request, all other features are still
relying on the old view filter implementation.
Advanced filters are ignored because they are hidden and because this
effort is made precisely to allow the completion of the advanced filters
feature.
This PR fixes a problem with how TypeORM handles date without time.
A date without time that is stored in PostgreSQL database as `date` type
gets returned as an ISO string date with a timezone that can shift its
date part in an unwanted way.
In short DB stores `2025-01-01`, TypeORM query builder returns
`2024-12-31T23:00:00Z` which gets parsed as `2024-12-31` on the front
end field.
We don't want to handle timezone here because we are manipulating a date
without its time part, so this PR adds a step that counteracts what
TypeORM does and returns `2025-01-01T00:00:00.000Z` so that the front
can parse it correctly.
@Weiko We might want to check other places of the backend where date
types are returned by TypeORM, we might have the same problem, this PR
only fixes it for updateOne resolver return.
- Fixed date persist on frontend which was shifting the date to a
different day due to timezone issue
- Fixed date returned by the backend update logic, which was shifting
the date by the timezone offset (so this PR adds back the offset so that
it stays at 00:00:00Z time)
This PR is only moving and renaming types, hooks and utils to
record-filter module folder.
- Moved and renamed types from object filter modules to record filter…-
Moved and renamed types from object filter modules to record filter
module
- Moved useApplyRecordFilter to record filter module
- Renamed util getOperandsForFilterDefinition to
getRecordFilterOperandsForRecordFilterDefinition
Removed useFilterDropdown hook and its many calls which were only
exporting states.
The test has been removed because it was used to do the equivalent of
testing Recoil states, so it wasn't useful anymore.
This PR extracts reset filter logic from useFilterDropdown hook.
The goal is to remove useFilterDropdown hook by incrementally removing
each sub hook one by one.
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
This PR extracts the logic to manage filter and filter definition
setting.
Previously it was ambiguous, we had the same "selectFilter" naming used
for setting filter definition in filter dropdown and for setting the
actual filter value and saving to view filter states.
This is another incremental refactor, which will allow to remove
useFilterDropdown hook.
Refactored object filter dropdown states while keeping the existing
structure to avoid creating a big PR.
The goal is to extract each sub hook returned by the useFilterDropdown
hook and create a PR for each function and the associated refactor for
the dependent zones in the code, so that we proceed by small increments.
There is a problem of hotkey scope not being passed to the relation
picker used for single record select fields.
Fixed it where we open a single record select.
- Fixed click outside for kanban not working (changed strategy)
- Tried a different approach for setting the context menu position
- Fixes https://github.com/twentyhq/twenty/issues/9336
Fixes https://github.com/twentyhq/twenty/issues/8970
The context menu wasn't working because of wrong architecture with the
Dropdown component, as it's a unique behavior (no clickable component
and portal) it also required refactoring a bit the Dropdown component.
- Context menu now uses a portal
- Fixed dropdown offset without clickable component (now using a
fallback anchor component)
- Fixed React array key props
- Added all usable composite field types on pet custom object
- Fixed missing createdBy on people and company seeds
- DEFAULT_SUBDOMAIN is now used for login (could be improved for multi
workspace)
- Refactored ObjectMetadataStandardIdToIdMap to disambiguate from
ObjectMetadataMap
- Refactored seedCustomObjects
- Added a new Seeder service to help with custom object seeds
- Added RichTextFieldInput to edit a rich text field directly on the
table, but deactivated it for now.
Created a resizable container tied to dragging state to create suitable
droppable zone when there's no orphan favorites.
Co-authored-by: Weiko <corentin@twenty.com>
Fixes total count bug that was -1 the total count
Fixes a bug when trying to go from first to last or the other way around
Fixes a React array key bug
Follow-up issue (non critical) :
https://github.com/twentyhq/twenty/issues/9197
There was an unecessary dropdown menu container div that was conflicting
with the recent refactor of dropdowns. The OverlayContainer component is
now at the root of the tree of a cell.
- Removed disableBlur property from dropdown because it is no longer
needed since there's only one OverlayContainer component so there can be
only one blur at a time.
- Removed blur CSS properties from every component that used it because
one standalone OverlayContainer is able to handle all cases if placed
properly.
- Also removed disableBackgroundBlur property from SingleRecordSelect
- Removed FieldInputOverlay and FieldTextAreaOverlay components that
were a first attempt to create something like an OverlayContainer
- Used new unified OverlayContainer in RecordInlineCell and
RecordTableCell
- Fixed ScrollWrapper so that it works well both for dropdown with non
overflowing content and dropdown with overflowing content.
- Removed export default value on SearchVariablesDropdown as it is not
used in this codebase
- Refactored SearchVariablesDropdown function as component anti-pattern
- Refactored SearchVariablesDropdownFieldItems UI problems with
separator and missing ScrollWrapper behavior
- Refactored SearchVariablesDropdownObjectItems with UI problems with
separator and missing ScrollWrapper behavior
- Fixed blur bug on Firefox due to wrong placement of the element that
had the CSS property. Blur works on Firefox it it's on the container
that has the highest level in the tree.
- Fixed bug in ActivityTargetInlineCell by removing an unnecessary
container component StyledSelectContainer
- Unified problems of field height with a new common component
FieldInputContainer, instead of putting width and height at the wrong
abstraction level, width and height are a field's concern not a
dropdown, overlay or low-level input concern.
- Fixed block editor dropdown with new OverlayContainer
- Aligning field dropdown with their anchor on inline and table cells,
there are still many small pixel misalignments that give a low quality
impression.
- Fixed FormDateFieldInput that was missing OverlayContainer
- New task dropdown wasn't using the proper dropdown id
- Action menu triggered by context menu (right click) on table cell was
listening in edit mode.
The `QueryResultGettersFactory` that is called on every query return to
was called only on the first level of relations because recursivity
wasn't implemented.
In this PR I implement recursivity and add some typing for the possible
forms a GraphQL query field can take.
This PR will fix any issue we have with pictures that were losing their
token (here for person.avatarUrl)
Fixes https://github.com/twentyhq/twenty/issues/8425
Fixes https://github.com/twentyhq/twenty/issues/8498
---------
Co-authored-by: Weiko <corentin@twenty.com>
Many dropdown bugs have been fixed, more refactoring is needed.
Dropdown fixed :
- Filter select
- Sort select
- Visible field select
- Hidden field select
- Multi item picker (phones, links, emails, etc.)
- Phone country select
- Fixed CSS for SortOrFilter chips
- Fixed bug when refreshing with an actor source filter set
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
This PR refactors the view module to implement utils that avoid having
to create hooks to inject the scope id in the states, like
`useViewStates`, each componentState will know its unique related
InstanceContext (which holds the instanceId), and thus will be able to
retrieve it itself.
We keep the naming componentState as it reflects the fact that those
states are tied to instances of a component (or its children).
We introduce the instance word where it is needed, in place of scopeId
for example, to precise the fact that we handle instances of component
state, one for each instance of a component.
For example, the currentViewId is a state that is tied to an instance of
the ViewBar, but as we can switch between views, we want currentViewId
to be a componentState tied to an instance of the ViewBar component.
This PR also refactors view filter and sort states to fix this issue :
https://github.com/twentyhq/twenty/issues/6837 and other problems
involving resetting those states between page navigation.
Fixes https://github.com/twentyhq/twenty/issues/6837
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
Fixed bug that was appearing with records without any activity target
The problem may come from the new TwentyORM that doesn't understand the
filter like before.
Open table cell was triggered by a click on a field input.
This is a temporary solution.
I fixed it for DoubleTextInput but it might be problematic for other
field types as well, we should implement a kind of bubbling shield to
make sure that no click event can bubble up to trigger things like open
table cell in the above components that shouldn't listen.
See https://github.com/twentyhq/twenty/issues/6909
Fixes#6833
The view states for unsaved changes were not reseted on view change.
The fix was to just add a call to the existing resetCurrentView when the
viewId changes in the related effect.
In this PR:
- revert de-optimization of icons bundle for storybook. This was forcing
the browser to load ~3k files while running stories
- adding lazy loading on Settings route to improve developer experience
(some files will be loaded later)
- fix FE tests: unit, modules stories, pages stories
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
Fetch more on the record table was causing a strange bug where it was
auto scrolling to the bottom of the newly loaded chunk of rows.
This was confusing because we lost our previous position in the record
table.
With this fix the table doesn't scroll when more rows are loaded.
The fetch more row has been moved in the same tbody as the rest of the
rows.
We now only hide it when there is no more record to fetch.
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
The update of all fields was caused by `useContextSelector` not being
properly implemented.
As it is a memoization library the `useRecordFieldValue` hook wasn't
giving to the library the required things to allow memoization.
I just added recordId + fieldName to the memoization function so that
`useContextSelector` doesn't recompute itself whenever any record
changes.
Activity creation was duplicating the new activity on already visited
records of the same type.
The fix was to activate `shouldMatchRootQueryFilter` on createOne for
activity.
Modal clickoutside was modified recently.
It was considering portaled component like dropdown outside, so
comparePixel mode for click outside is needed here.
Closes https://github.com/twentyhq/twenty/issues/5741
Filtering was already working.
I just added the required logic in the frontend to allow sorting by
primary link url (because label can be empty)
Fixes https://github.com/twentyhq/twenty/issues/5762
The problem was only happening with a sort on a select type field, also
appears with currency type and maybe other types.
This was because NULL values were sorted in a random order because the
sort function was comparing two NULL values as not equal, so I just
added a case for when A === B === NULL.
Implement date formatting per workspace member settings
We'll need another round to maybe initialize all workspaces on the
default settings.
For now the default behavior is to take system settings if nothing is
found in DB.
---------
Co-authored-by: Weiko <corentin@twenty.com>
- Removed enabled props from useScopedHotkeys becayse it doesn't work
- Moved enter useScopedHotkeys in a handler that we drill down to the
text inputs on the settings form
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
- Fixed activity creation in cache
- Fixed activity creation in DB, where the relation target was
disappearing after creation
- Added an option to match root query filter in creation optimistic
effect to avoid adding the newly created record in every mounted query
in Apollo cache on the same object (which was causing notes to be
duplicated on every object in the cache)
- Fixed tab list scope id
- Fixed various browser console warnings
- Refactored components in table
- Added a isTableRecordScrolledLeftState and
isTableRecordScrolledTopState to subscribe to table scroll
- Added a zIndex logic that subscribes to those new states in new tinier
components
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
CSS modules were used as a first test for performance optimization.
We later found out that Linaria was a better tradeoff.
This PR removes what was implemented in CSS modules and also the CSS
theme file that was created that was overlapping with the TS theme
files.
Lucas Bordeau