Closes https://github.com/twentyhq/core-team-issues/issues/1276
We now need to take fields permissions into account when determining if
a cell is editable or not.
a record field (= a cell) is read only if one of the condition is met:
- the object of the record is read-only (can be determined at table
level) by permission setting
- the field of the object is read-only (can be determined at column
level) - either by permission settings or by system (some workflows
fields for intance)
- the record is deleted (can be determined at row level)
we reorganized the code to avoid re-computing known information as much
as possible.
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
In our Graphql schema, ids are typed as UUID.
Our FE codegen is typing it as 'any', unless we say otherwise. Fixing it
and fixing the impacts in the codebase
In this PR:
- adding a try / catch around all ORM internal methods save, insert,
upsert, findOne, ...
- leveraging this error to prevent messageChannels to get FAILED
- optimizing messaging BATCH_SIZE and THROTTLE threshold according to
local tests
-
<img width="1510" height="851" alt="image"
src="https://github.com/user-attachments/assets/802fd933-caac-4291-9cde-34a1ddf59c06"
/>
Fixing two issues I introduced in #13583 and #13573
- Overflow visible is not needed, I missed that as I was switching
between different implementations
- Button within button not allowed (not the prettiest fix but I din't
think it's worth digging deeper)
# Introduction
- deferrable constraint on foreignKey definition
- fix relation creation input transpilation to flat field metadata
- fix validation to allow contextual validation on not already created
field metadata ( usefull for relation, and will be necessary for the
import )
- handle missing composite fields
- refacto filter action to be more reliable
Remaining improvements:
- filter out some field types
- improve relations
This PR aims to improve performances as we are making A LOT of queries
after having added events emission to the ORM layer. While investigating
issues, I've come across multiple problems I will describe below
## Add index on workspace.activationStatus as we are querying it a lot
As per title
## Add logs on core datasource destroy
It seems that we have postgres connection pool destruction in
production. I cannot reproduce locally but I suspect the Query Timeouts
to be the root cause. I'm fixing most of the Query Timeouts cause in
this PR but I'm adding the logs so we have more information in case in
keeps happening in production.
## GraphQL query runner createMany
It was using a for loop on each record. This is as issue has we will
emit an event separately for each record => we should always try to
batch events.
Replacing by a save on all records. Note that this is not perfect as we
should avoid using save (bad performances), and use insert + updateMany
instead. As I have follow up discussions regarding permissions, I
haven't replaced it by insert and updateMany yet. Using save instead of
a for loop makes the problem less worrying.
## Introduce updateMany in ORM @Weiko @ijreilly FYI
.save(manyRecords) is bad as it's querying the data for no good reason
(and doing a select for each record...).
We already have .insert(), i'm introducing .updateMany()
I think our ORM layer should be simplified a lot but I'm not starting
the refacto yet
## Fixing ORM @Weiko @ijreilly FYI
- Fixing events emission in delete function
- Fixing events emission in insert function
- make sure everything is batched
## Events performance @Weiko @ijreilly FYI
Do not emit timelineActivity db events as this does not seem useful and
is quite heavy
## Messaging and Calendar performance @bosiraphael FYI
Rework many functions to make sure they are batched. This does not touch
the driver layer and I have heavily tested it. (multiple account, with
multiple channels, common thread, common messages, etc...)
## Workflow Trigger relation Fetch performance @martmull FYI
Improved performance by batching
Fixes#13250
This PR fixes the breadcrumb display issue where API names were shown
instead of friendly object names when navigating to related objects in
the detail view.
---------
Co-authored-by: Félix Malfait <felix@twenty.com>
Removed the Variable FeildMetaDataType.UUID at line 52
from
twenty\packages\twenty-front\src\modules\settings\data-model\constants\SettingsNonCompositeFieldTypeConfigs.ts
---------
Co-authored-by: Félix Malfait <felix@twenty.com>
# Introduction
The cache is not accurately typed regarding the `fieldMetadataMaps` they
do not contain relations
In this way we:
- Created dedicated transpilation tools for cache manipulation
- Avoided recursivity in transpilation tools
- Fix and finalized the createMany fields metadata service v2
- Refactor the validator to handle validation :)
## What's next:
- Implem integration tests to make things run 🙃
- migrate existing settings valdiation
- Finish the create object metadata service
- Handle update input transpilation and validation
fixes 1-2px scroll restoration issue
- browser reports 1-2px instead of exact 0 when at top
- old logic kept saving these tiny values
- now clears storage when <= 3px (essentially at top)
- prevents weird micro-scroll when returning to pages
re: [greptile infinite polling
concern](https://github.com/twentyhq/twenty/pull/13363#discussion_r2247232974)
- not valid in practice:
- restoration only runs if position was previously saved
- no scroll = no save = no restore = no polling
- tested across all page types, zero infinite loops
tested: works perfectly, no side effects
Fixes https://github.com/twentyhq/core-team-issues/issues/1262
In this PR we add the update permission check layer by
- for the graphql api: extracting columns to update from the
expressionMap
- for rest api: .save() is used so we need to add the permission layer
to .save directly. We also take advantage of this PR to filter out
non-readable fields from save response (other save returns the whole
entity) - this was planned in
https://github.com/twentyhq/core-team-issues/issues/1216
The current solution does not work with rest api depth 2 queries, but
this seem to already not work on main (for timeout reasons though, so
different). I offer to create a ticket to fix it altogether later.
Fixes https://github.com/twentyhq/twenty/issues/13428
We perform the call enrichment even with id undefined. It returns the
first item in DB.
Adding two more fixes related to filters:
- Conditions title
- Fixing placeholder color for select control (only other impacted field
is in Advanced filters)
