Fixing:
- Export as PDF on empty note
- Command O (sub commands) not using the right contextStore
- BelongsToOne Field input triggering an error on open if no existing
relation record is pre-selected
Closes https://github.com/twentyhq/core-team-issues/issues/271
This PR
- Removes the feature flag IS_COMMAND_MENU_V2_ENABLED
- Removes all old Right drawer components
- Removes the Action menu bar
- Removes unused Copilot page
Closes https://github.com/twentyhq/core-team-issues/issues/491
This PR:
- Duplicates the right drawer pages for the command menu and replace all
the states used in these pages by component states (The right drawer
pages will be deleted when we deprecate the command menu v1)
- Wraps those pages into a component instance provider
- We store the component instance id upon navigation to restore the
states when we navigate back to a page
The only pages which are not updated for now are the pages related to
the workflow objects, this will be done in another PR.
In another PR, to improve the navigation experience I will replace the
icons and titles of the chips by the label identifier and the avatar if
the page is a record page.
https://github.com/user-attachments/assets/a76d3345-01f3-4db9-8a55-331cca8b87e0
---------
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
Closes https://github.com/twentyhq/core-team-issues/issues/63
This PR:
- Creates an **Import csv** action
- Allows the import of notes and tasks
- Removes the import action from the index option menu
- Adds export action when only one record is selected
- Adds see deleted record action to workflow objects
## Introduction
Added coverage on the `useDeleteOneRecord` hooks, especially its
optimistic behavior feature.
Introduced a new testing tool `InMemoryTestingCacheInstance` that has
builtin very basic expectors in order to avoid future duplication when
covering others record hooks `update, create, destroy` etc etc
## Notes
Added few comments in this PR regarding some builtin functions I've
created around companies and people mocked object model and that I think
could be cool to spread and centralize within a dedicated "class
template"
Also put in light that unless I'm mistaken some tests are running on
`RecordNode` and not `RecordObject`
Took few directions on my own that as I always I would suggestion nor
remarks on them !
Let me know
## Misc
- Should we refactor `useDeleteOneRecord` tests to follow `eachTesting`
pattern ? => I feel like this is inappropriate as this hooks is already
high level, the only plus value would be less tests code despite
readability IMO
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.
In the action menu dropdown, we only want to display the actions for the
selected records, so we need to filter available actions according to
their type and scope.
Note: the `Search record` action was appearing twice because one is a
standard action and one is a fallback action and both are registered in
the available actions. We don't want to display this action because it
isn't related to the selected records, it is a global action.
Before:
<img width="226" alt="Capture d’écran 2025-02-21 à 12 12 53"
src="https://github.com/user-attachments/assets/0a4f9b8c-4e30-4697-9861-559e76dc288f"
/>
After:
<img width="241" alt="Capture d’écran 2025-02-21 à 12 10 34"
src="https://github.com/user-attachments/assets/0a98c9d5-432d-4018-a4d3-bf3a6d0c49be"
/>
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.
In this huge (sorry!) PR:
- introducing objectMetadataItem in contextStore instead of
objectMetadataId which is more convenient
- splitting some big hooks into smaller parts to avoid re-renders
- removing Effects to avoid re-renders (especially onViewChange)
- making the view prefetch separate from favorites to avoid re-renders
- making the view prefetch load a state and add selectors on top of it
to avoir re-renders
As a result, the performance is WAY better (I suspect the favorite
implementation to trigger a lot of re-renders unfortunately).
However, we are still facing a random app freeze on view creation. I
could not investigate the root cause. As this seems to be already there
in the precedent release, we can move forward but this seems a urgent
follow up to me ==> EDIT: I've found the root cause after a few ours of
deep dive... an infinite loop in RecordTableNoRecordGroupBodyEffect...
prastoin edit: close https://github.com/twentyhq/twenty/issues/10253
---------
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
Co-authored-by: prastoin <paul@twenty.com>
The command menu search bar was reset after clicking on the `Search
records` fallback action, but it shouldn't.
This PR:
- Introduces a new type of action: `Fallback` actions
- Reset the search bar only if the action key differs from
'record-search-fallback'
# Introduction
At the moment when updating any record cache occurence, we will build a
fragment that will expect all of the object metadata item fields to be
provided.
Which result in the following traces: ( in the video companies aren't
fetch with companyId and other missing fields )
https://github.com/user-attachments/assets/56eab7c1-8f01-45ff-8f5d-78737b788b92
By definition as we're using graphql we might not request every record's
fields each time we wanna consume them.
In this way we will now dynamically compute or expect depending on the
CRUD operation specific fields to be written in the cache, and not all
of them
Tested all optimistic and failure management use cases
## Covering cache
Added coverage only for the `deleteOne` and `deleteMany` hooks, it cover
only the record record cache and not its relations hydratation ( for the
moment )
## Why not closing #9927
Unless I'm mistaken everything done here have fixed the same logs/traces
issue for updates and deletion but not creation.
Which means we still need to investigate the mass upload from import and
prefillRecord behavior
In a nutshell: went over each `updateRecordFromCache` calls, still need
to do all `createRecordInCache` calls
related to #9927
## Conlusion
Sorry for the big PR should have ejected into a specific one for the
`MinimalRecord` refactor
Will also continue covering others hooks later in my week as for the
`deleteOne`
As always any suggestions are welcomed !
Close
https://discord.com/channels/1130383047699738754/1334441759484149793
Using refetch queries was not working for certain use cases.
To find manual active workflows in cmd+k, we use a query with specific
filters that was complicated to refetch.
Finally I will update the cache manually. It was not properly updated
before because the json value of the version trigger was stringified
without spaces. So the entity was not found in apollo cache.
- Update discard draft icon
- Pin `Remove from favorites` action
- Update workflow action labels to add clarity
Note: this is a small PR, the number of modified lines is due to the
translations
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.
Fixes#10004
- Fixed `useListenClickOutside` which wasn't working with
`excludeClassNames` for `comparePixels` mode
- Added `emitCloseEvent` parameter to the `closeRightDrawer` function
because closing the right drawer after deleting a note or a task was
triggering an update after the deletion.
This bug was only for the old version of the command menu.
# Introduction Nitpick
Action's record has two entries with `position: 0`
Unless I'm mistaken I could not find any place where the `position`
property is consumed
So this is just for sake of the +1 suite
# Introduction
Added destroy many records to the `WorkflowActionConfig`
## Repro:
- Filter by deleted workflow
- Select mulitple rows
- Click on destroy
# Pinned action standardization
After discussion with @Bonapara and @bosiraphael we landed on a
standardization of the pinned actions between `DefaultActionsConfigV2`
and `WorkflowActionConfig` which means that now are pinned the `DELETE`
and `DESTROY` for both `single/multiple` modes for both features
Related to https://github.com/twentyhq/twenty/pull/9991
# Introduction
Added the `RecordAction` destroy multiple record
## Repro
Select multiples `deletedRecords`, you should be able to see the
`Destroy` pinned CTA ( iso short label with the destroy one ), open
control panel and fin new CTA `Permanently delete records`
https://github.com/user-attachments/assets/31ee8738-9d61-4dec-9a1f-41bb6785e018
## TODO
- [ ] Gain granularity within tests to assert the action should be
registered only when filtering by deleted
## Conclusion
Closes https://github.com/twentyhq/core-team-issues/issues/110
Refresh of `objectmetadataitems` was not happening fast enough. Page was
breaking when enabling the feature flag. Instead of not storing worklow
objects in state, we will use the feature flag to block on read. This
way we avoid race conditions
<img width="1511" alt="Capture d’écran 2025-02-04 à 14 11 56"
src="https://github.com/user-attachments/assets/912cc59a-f422-48ab-84b7-7fdd7bbc35c1"
/>
# Introduction
Avoid having multiple `isDefined` definition across our pacakges
Also avoid importing `isDefined` from `twenty-ui` which exposes a huge
barrel for a such little util function
## In a nutshell
Removed own `isDefined.ts` definition from `twenty-ui` `twenty-front`
and `twenty-server` to move it to `twenty-shared`.
Updated imports for each packages, and added explicit dependencies to
`twenty-shared` if not already in place
Related PR https://github.com/twentyhq/twenty/pull/9941
- remove asynchronous serverless function build
- build serverless function synchronously instead on activate workflow
or execute
- add a loader on workflow code step test tab test button
- add a new `ServerlessFunctionSyncStatus` `BUILDING`
- add a new route to build a serverless function draft version
- delay artificially execution to avoid UI flashing
https://github.com/user-attachments/assets/8d958d9a-ef41-4261-999e-6ea374191e33
# Introduction
This PR is highly related to previous optimistic cache refactor:
https://github.com/twentyhq/twenty/pull/9881
Here we've added some logic within the
`triggerUpdateRelationsOptimisticEffect` which will now run if given
recordInput `deletedAt` field is defined.
If deletion, we will iterate over all the fields searching for
`RELATION` for which deletion might implies necessity to detach the
relation
## Known troubleshooting ( also on main )
We might have to refactor the `prefillRecord` to spread and
overrides`inputValue` over defaultOne as inputValue could be a partial
one for more info please a look to
# Conclusion
Any suggestions are welcomed !
fixes https://github.com/twentyhq/twenty/issues/9580
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
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.
In this PR:
- removing rootDir / baseUrl from any tsconfig.json
- we need to keep it in tsconfig.spec.json and also specify rootDir in
jest.config.ts moduleMapper because of the way nx jest executor works
(automatically moving back to root)
- we need to explictly specify the depencies to twenty-shared /
twenty-emails (built packages) in packages package.json to help nx
understand dependencies
