Deleting a record does not update frontend. #9580
Assignees
Labels
Comments
This was referenced Jan 23, 2025
prastoin
added a commit
that referenced
this issue
Jan 24, 2025
…ship from Metadatas (#9815) # Introduction At the moment the relationships are inferred from the record data structure instead of its metadatas We should refactor the code that computes or not the necessity to detach a relation on a mutation We've refactored the `isObjectRecordConnection` method to be consuming a `relationDefintion` instead of "typeChecking" at the runtime the data structure using zod validation schema Related to #9580
DeepaPrasanna
pushed a commit
to DeepaPrasanna/twenty
that referenced
this issue
Jan 27, 2025
…ship from Metadatas (twentyhq#9815) # Introduction At the moment the relationships are inferred from the record data structure instead of its metadatas We should refactor the code that computes or not the necessity to detach a relation on a mutation We've refactored the `isObjectRecordConnection` method to be consuming a `relationDefintion` instead of "typeChecking" at the runtime the data structure using zod validation schema Related to twentyhq#9580
charlesBochet
added a commit
that referenced
this issue
Jan 29, 2025
# Introduction It seems like optimistic caching isn't working as expected for any record relation mutation, CREATE UPDATE DELETE. It should not have an impact on the destroy We included a new `computeOptimisticRecordInput` that will calculate if a relation is added or detach. Updated the `triggerCreateRecordsOptimisticEffect` signature we should have a look to each of its call to determine if it should be checking cache or not Related to #9580 --------- Co-authored-by: Charles Bochet <[email protected]>
This was referenced Jan 29, 2025
charlesBochet
pushed a commit
that referenced
this issue
Jan 29, 2025
# Introduction ~~this could be cool for the updateRecordFromCache to return the updated record, so we could consume its return value more explicitly such as `updatedRecordValue`~~ In fact this is nitpick as it would really be the same than returning the received params ## Fixes duplicated optimistic cache upsert <img src="https://github.com/user-attachments/assets/289f4801-5b67-4e4e-a87b-a512deb5180c" width="300px" height="300px"> We were before comparing the previously `cachedRecord` which is now, not the latest as the optimistic is (should) be working successfully since #9881 ## Reproduction 1- Open any Company 2- Attach an Opportunity it should appears only once 3bis- If you revert the last branch commit it will appear duplicated Related to #9580
github-project-automation
bot
moved this from 👀 In review
to ✅ Done
in 🎯 Roadmap & Sprints
eliezer-rodrigues037
pushed a commit
to mind-developer/kvoip-v2
that referenced
this issue
Jan 30, 2025
# Introduction This PR is highly related to previous optimistic cache refactor: twentyhq#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 twentyhq#9580 --------- Co-authored-by: Charles Bochet <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Deleting an opportunity through companies does not update the frontend, a reload is required for the opportunity to disappear. Also trying to detach the deleted opportunity before a reload gives an error.
The text was updated successfully, but these errors were encountered: