We must separate the concept of hydratation which happens at the request
level (take the token and pass auth/user context), from the concept of
authorization which happens at the query/endpoint/mutation level.
Previously, hydratation exemption happened at the operation name level
which is not correct because the operation name is meaningless and
optional. Still this gave an impression of security by enforcing a
blacklist. So in this PR we introduce linting rule that aim to achieve a
similar behavior, now every api method has to have a guard. That way if
and endpoint is not protected by AuthUserGuard or AuthWorspaceGuard,
then it has to be stated explicitly next to its code.
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
BlocknoteJS requires an ESM module where our server is CJS, this forced
us to pin the server-util version, which led us to force the resolution
of several packages, leading to bugs downstream.
From Node 22.12 Node supports requiring ESM modules (available from Node
22.0 with a flag). So I upgrade the module.
I picked Node 22 and not Node 23 or Node 24 because 22 is the LTS and we
don't plan to change node versions frequently.
If you remain on Node 18, things should still mostly work, except if you
edit a Rich Text field.
I also starting changing the default runtime for Serverless Functions
which isn't directly related. This means new serverless functions will
be created on Node 22, but we will still need another PR to migrate
existing serverless functions before September (end of support by AWS).
(In this PR I also remove the upgrade commands from 0.43 since they rely
on Blocknote and I didn't want to have to deal with this)
---------
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
First PR to add filters to send records. Lot of work left, but I want to
split. I mainly want to validate the architecture there.
https://github.com/user-attachments/assets/63375a75-ba88-49df-8c12-5e3e58de5342
TODO in next PRs:
- fix design
- make filters reliable. Some composite fields are not implemented and
some fields like datetime do not work well
- improve typing
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>
# Indexes
### TLDR:
Putting indexes back, except relation ones
### Details:
- Added index synchronization logic back (it was removed previously in
45d4845b26)
in the sync-metadata service.
- for unique inedexes, a command will create unicity again by handling
duplicates that were cretated since the
45d4845b26
was triggered
# Integration test failing
- fix the local run by renaming folder in the jest configuration.
Otherwise "clickhouse" tests were failing
- falsy test introduced 2 days ago in
https://github.com/twentyhq/twenty/pull/12271/files
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
# Improved participant matching with additional emails support
Closes#8991
This PR extends the participant matching system to support additional
emails in addition to primary emails for both calendar events and
messages. Previously, the system only matched participants based on
primary emails, missing matches with secondary email addresses.
- Contact creation now consider both primary and additional emails when
checking for existing contacts
- Calendar and message participant listeners now handle both primary and
additional email changes
- Added tests
## To test this PR:
Check that:
- Primary emails take precedence over additional emails in matching
- Case-insensitive email comparisons work correctly
- A contact is not created if a person already exists with the email as
its additional email
- Event listeners handle both creation and update scenarios
- Matching and unmatching logic works for complex email change scenarios
- When unmatching after a change in a primary or secondary email, events
and messages should be rematched if another person has this email as its
primary or secondary email.
---------
Co-authored-by: guillim <guigloo@msn.com>
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.
I believe that some emails with invalid characters are breaking the sync
process.
this PR attempts to create a "safeParseAddress" function. Hopefully this
will change current behavior of a single email breaking the entire sync
process to the sync process "skipping" an invalid email address and
continuing on.
I opened this because of issues explained in #12336
---------
Co-authored-by: guillim <guigloo@msn.com>
- 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
In the frame of https://github.com/twentyhq/core-team-issues/issues/924
- Rename dataSource -> workspaceDataSource when relevant to ease
understandability
- override workspaceDataSource.createQueryBuilder, because we don't want
developers to use it directly since it does not run permission checks at
this level. Indeed, we cannot do so because 1) datasources are shared
between roles so we would need to re-think its implementation to make
that possible, while for now we never call
workspaceDatasource.createQueryBuilder in our codebase 2)
workspaceEntityManager.createQueryBuilder, that we have overriden with
permission checks, then performs a call to
workspaceDataSource.createQueryBuilder so that would make two permission
checks.
