Commit Graph

7 Commits

Author SHA1 Message Date
6a14b1c6d6 Fix tasks (#5199)
## Query depth deprecation

I'm deprecating depth parameter in our graphql query / cache tooling.
They were obsolete since we introduce the possibility to provide
RecordGqlFields

## Refactor combinedFindManyRecordHook

The hook can now take an array of operationSignatures

## Fix tasks issues

Fix optimistic rendering issue. Note that we still haven't handle
optimisticEffect on creation properly
2024-04-29 23:33:23 +02:00
7211730570 New field type: DATE (#4876)
### Description
New field type: DATE

### Refs
https://github.com/twentyhq/twenty/issues/4377

### Demo

https://jam.dev/c/d0b59883-593c-4ca3-966b-c12d5d2e1c32

Fixes #4377

---------

Co-authored-by: gitstart-twenty <gitstart-twenty@users.noreply.github.com>
Co-authored-by: v1b3m <vibenjamin6@gmail.com>
Co-authored-by: Toledodev <rafael.toledo@engenharia.ufjf.br>
Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
2024-04-11 17:29:29 +02:00
a7fcc5d47e 4778 multi select field front implement multi select type (#4887) 2024-04-11 12:57:08 +02:00
02673a82af Feat/put target object identifier on use activities (#4682)
When writing to the normalized cache (record), it's crucial to use _refs
for relationships to avoid many problems. Essentially, we only deal with
level 0 and generate all fields to be comfortable with their defaults.

When writing in queries (which should be very rare, the only cases are
prefetch and the case of activities due to the nested query; I've
reduced this to a single file for activities
usePrepareFindManyActivitiesQuery 🙂), it's important to use queryFields
to avoid bugs. I've implemented them on the side of query generation and
record generation.

When doing an updateOne / createOne, etc., it's necessary to distinguish
between optimistic writing (which we actually want to do with _refs) and
the server response without refs. This allows for a clean write in the
optimistic cache without worrying about nesting (as the first point).

To simplify the whole activities part, write to the normalized cache
first. Then, base queries on it in an idempotent manner. This way,
there's no need to worry about the current page or action. The
normalized cache is up-to-date, so I update the queries. Same idea as
for optimisticEffects, actually.

Finally, I've triggered optimisticEffects rather than the manual update
of many queries.

---------

Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
2024-04-01 13:12:37 +02:00
3171d0c87b feat: address composite field (#4492)
Added new Address field input type.

---------

Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
2024-03-28 16:50:38 +01:00
d876b40056 Logs show page (#4611)
* Being implementing events on the frontend

* Rename JSON to RAW JSON

* Fix handling of json field on frontend

* Log user id

* Add frontend tests

* Update packages/twenty-server/src/engine/api/graphql/workspace-query-runner/jobs/save-event-to-db.job.ts

Co-authored-by: Weiko <corentin@twenty.com>

* Move db calls to a dedicated repository

* Add server-side tests

---------

Co-authored-by: Weiko <corentin@twenty.com>
2024-03-22 14:01:16 +01:00
ec384cc791 Implement eager load relations on graphqlQueries (#4391)
* Implement eager load relations on graphqlQueries

* Fix tests

* Fixes

* Fixes
2024-03-10 23:42:23 +01:00