ressolve #12205
This PR fixes the issue where the record in the command menu was
reopening when clicking the same field again.
https://github.com/user-attachments/assets/52da7b3f-4704-4a9c-8fc4-29534568b0c0
- Added recordId to cells so it can be accessed when
useListenClickOutside is triggered, and compared the previous recordId
with the new one to prevent closing the command menu for the same
record.
- When the field is clicked, we compare the lastRecordId with the new
recordId inside the openRecordInCommandMenu function to avoid reopening
the menu unnecessarily.
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
Fixes an infinite loop introduced by #12371
An infinite loop was triggered when there was an error when fetching the
client config.
Cause of the bug: `isLoadedOnce` wasn't set to true when catching an
error in `useClientConfig`.
This effect then created an infinite loop inside
`ClientConfigProviderEffect` because `fetchClientConfig` updated
`clientConfigApiStatus.isLoading` but not `isLoadedOnce`.
```typescript
useEffect(() => {
if (
!clientConfigApiStatus.isLoadedOnce &&
!clientConfigApiStatus.isLoading
) {
fetchClientConfig();
}
}, [
clientConfigApiStatus.isLoadedOnce,
clientConfigApiStatus.isLoading,
fetchClientConfig,
]);
```
If you tried to add a delay in `refreshObjectMetadataItems` like this`
await new Promise((resolve) => setTimeout(resolve, 5000))`, then this
caused an issue where the user was redirected to his workspace because
the metadata was not loaded.
This happened because I had removed the call to fetch metadata
explicitly in useAuth (instead relying on the effect to fetch it because
it was done twice). I had removed it because this was causing issues in
the onboarding process where /metadata was called too early and then
cached with the wrong reply.
The correct fix is instead to change the fetch policy to `network only`
to stop hiding re-renders to the object metadata effect with Apollo's
cache mechanism. Now the [] reply isn't cached in the onboarding, the
metadata effect is only triggered during initial page load and refresh
should be called explicitely.
I also noticed a bug on the server side where sometimes the frontend was
passing a token for public requests (login token exchange request,
public domain data request). I removed the check so that the backend
completely ignores the token when it's passed on public request. The
downside is that we're losing information for logs (who did that request
to a public endpoint), but it doesn't make much sense to throw
authentication errors on that endpoint imo. Probably a better root-cause
fix would be to understand why a token is still passed on the frontend,
but that would require more investigation — the bug happened when I was
signing up and redirected from the app.xxx domain to the workspace
domain
Fixes#10177
Modified `usePersistField` to check for deep equality between the value
to persist and the current record store value before sending an update
query.
- Fix: AvatarURL signedPath for workspace members were not consistent
when queried multiple times and it was causing the frontend to wrongly
interpret this as a change in the deepEqual condition
- Use SaveAndCancel button to be consistent with data model page
- When applying all object permission changes, a "smarter" logic applies
and removes all permissions if read is unchecked for example
- Hide settings permissions when Settings All Access is toggled
## Quick Overview
This PR addresses the issue of reordering the action menu items to
improve user experience. The changes ensure that the "Import records"
and "Export view" actions are placed next to each other, with "Import
records" appearing before "Export view". This sequence is more intuitive
and aligns with common user expectations.
## Changes Made:
Adjusted the position of "Import records" to be before "Export view".
Ensured the sequence is now: 1. Import, 2. Export, 3. Delete.
## Impact:
Improved user experience by providing a more logical order of actions.
Aligned with user expectations for common data operations.
**Before:**
**After:**
<img width="438" alt="Screenshot 2025-06-02 at 2 03 01 PM"
src="https://github.com/user-attachments/assets/d38d95f0-1ae4-4b78-976b-837ee5df0c9e"
/>
Ensured no regressions in existing functionality.
The auth modal is a particular modal because it is the only one that is
opened in an effect (because its opening depends on the location).
After the hotkey scopes and the modal refactoring, we are now force to
call `openModal` and `closeModal` to open and close the modals. Here,
the `closeModal` wasn't called, but the modal was simply unmounted. The
global hotkeys were then disabled because the modal was still in the
focus stack.
Fixes
[#1052](https://github.com/twentyhq/core-team-issues/issues/1052#event-17916955590)
Creating manual chunk was a bad idea, we should always solve lazy
loading problem at the source instance.
Setting a 4.5MB for the index bundle size, CI will fail if we go above.
There is still a lot of room for optimizations!
- More agressive lazy loading (e.g. xyflow and tiptap are still loaded
in index!)
- Add a prefetch mechanism
- Add stronger CI checks to make sure libraries we've set asides are not
added back
- Fix AllIcons component with does not work as intended (loaded on
initial load)
This PR fixes a edge case where the user tries to create a non-advanced
filter that already exists in advanced filters, from the table header
drodpown.
This was because the hook that handles the creation was checking for
duplicate filters but without discerning between advanced and
non-advanced, and we want to be able to create non-advanced filters no
matter what we have in advanced filters.
Fixes https://github.com/twentyhq/twenty/issues/12316
Changes the default behavior for settings navigation items to stay
active when navigating to sub-pages.
**Problem:**
- Navigation items like "Data Model" and "Webhooks" were not staying
highlighted when navigating to detail pages
- This was because `matchSubPages` defaulted to requiring exact path
matches
**Solution:**
- Updated logic to make sub-page matching the default behavior (`end:
item.matchSubPages === false`)
- Only "Accounts" explicitly sets `matchSubPages: false` for its custom
sub-item navigation
- Removed redundant `matchSubPages: true` declarations throughout the
codebase
**URL Changes:** -- checked with @Bonapara
- `/settings/workspace` → `/settings/general`
- `/settings/workspace-members` → `/settings/members`
- `/settings/api-keys` → `/settings/apis`
- `/settings/developers/webhooks` → `/settings/webhooks`
before:
https://github.com/user-attachments/assets/56b94a49-9c31-4bb5-9875-ec24f4bc4d1e
after:
https://github.com/user-attachments/assets/38742599-c045-44d1-8020-56f3eacca779
---------
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
This PR fixes an edge case where we couldn't apply a filter on the field
metadata item that is used by a kanban.
As this has already been fixed for tables with groups, this PR just uses
the same technique.
Fixes https://github.com/twentyhq/twenty/issues/12311
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
Context :
Plan choice [on pricing page on website](https://twenty.com/pricing)
should redirect you the right plan on app /plan-required page (after
sign in), thanks to query parameters and BillingCheckoutSessionState
sync.
With email verification, an other session starts at CTA click in
verification email. Initial BillingCheckoutSessionState is lost and user
can't submit to the plan he choose.
Solution :
Pass a nextPath query parameter in email verification link
To test :
- Modify .env to add IS_BILLING_ENABLED (+ reset db + sync billing) +
IS_EMAIL_VERIFICATION_REQUIRED
- Start test from this page
http://app.localhost:3001/welcome?billingCheckoutSession={%22plan%22:%22ENTERPRISE%22,%22interval%22:%22Year%22,%22requirePaymentMethod%22:true}
- After verification, check you arrive on /plan-required page with
Enterprise plan on a yearly interval (default is Pro/monthly).
closes https://github.com/twentyhq/twenty/issues/12288
