Fix 'name' column wrongly added in standard objects #7428
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
PR Summary
This pull request addresses an issue with the 'name' column being incorrectly added to standard objects in the Twenty application.
- Removes 'name' column from default columns in
custom-table-default-column.util.ts - Adds 'name' column specifically for custom objects in
build-migrations-for-custom-object-relations.util.ts - Modifies
WorkspaceMigrationRunnerServiceto allow column creation during table creation - Ensures standard objects use their own specified labelIdentifierFieldMetadata
- Improves flexibility in the migration process for creating complex table structures
3 file(s) reviewed, 1 comment(s)
Edit PR Review Bot Settings
.../metadata-modules/object-metadata/utils/build-migrations-for-custom-object-relations.util.ts
Outdated
Show resolved
Hide resolved
Weiko
added a commit
that referenced
this pull request
Oct 7, 2024
Following this #7428 we now need to fix existing workspaces thanks to this migration command. This command will fetch all standard objects and their fields then filter out tables that don't have that column OR objects that have an existing fieldMetadata "name" of type TEXT and delete the rest.
harshit078
pushed a commit
to harshit078/twenty
that referenced
this pull request
Oct 14, 2024
## Context Name shouldn't be added to all tables, especially standard objects because they already have their own labelIdentifierFieldMetadata specified in the workspace-entity schema. This PR removes this column from the "base" list of columns to add when creating a new object/table and moves it to the object-metadata service that is, as of today, only used for custom objects. Also had to modify the migration-runner to handle column creation in a table creation migration (this was available in the migration definition already but was not doing anything) This also fixes an issue in standard objects that already have a "name" field defined with a different field type, this is even more important when the said field is a composite field. For example people already has a FULL_NAME name field which clashes with the default TEXT name field meaning it was only creating 1 field metadata for 'name' but 3 columns were created: `name, nameFirstName, nameLastName`. This inconsistency with metadata (which is our source of truth everywhere) brought some issues (lately, converting back typeorm response to gql (including composition) was broken).
harshit078
pushed a commit
to harshit078/twenty
that referenced
this pull request
Oct 14, 2024
Following this twentyhq#7428 we now need to fix existing workspaces thanks to this migration command. This command will fetch all standard objects and their fields then filter out tables that don't have that column OR objects that have an existing fieldMetadata "name" of type TEXT and delete the rest.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context
Name shouldn't be added to all tables, especially standard objects because they already have their own labelIdentifierFieldMetadata specified in the workspace-entity schema. This PR removes this column from the "base" list of columns to add when creating a new object/table and moves it to the object-metadata service that is, as of today, only used for custom objects. Also had to modify the migration-runner to handle column creation in a table creation migration (this was available in the migration definition already but was not doing anything)
This also fixes an issue in standard objects that already have a "name" field defined with a different field type, this is even more important when the said field is a composite field. For example people already has a FULL_NAME name field which clashes with the default TEXT name field meaning it was only creating 1 field metadata for 'name' but 3 columns were created:
name, nameFirstName, nameLastName. This inconsistency with metadata (which is our source of truth everywhere) brought some issues (lately, converting back typeorm response to gql (including composition) was broken).