feat: display record identifier field as first column in table

[thaisguigon]

& forbid hiding and moving record identifier column

Closes #3303

[github-actions]

TODOs/FIXMEs:

• // Todo replace this with label identifier logic: packages/twenty-front/src/modules/object-record/record-index/options/hooks/useRecordIndexOptionsForBoard.ts

Generated by 🚫 dangerJS against 761658c

[lucasbordeau]

Should we move the "+" new button on the record identifier row ?

[lucasbordeau]

Should we move auto-complete "Untitled" on the record identifier field ?

[lucasbordeau]

Is it relevant to fix this in this PR ?

The breadcrumb should show the record identifier content :

[lucasbordeau]

Couldn't we use a dedicated selector for that ?

[thaisguigon]

Done!

[thaisguigon]

Should we move the "+" new button on the record identifier row ?

Good catch, done!

[thaisguigon]

Is it relevant to fix this in this PR ?

The breadcrumb should show the record identifier content

Absolutely! Done, thank you!

[thaisguigon]

Should we move auto-complete "Untitled" on the record identifier field ?

Not sure how to go about this one, as the "Untitled" value is generated on backend (default value for the "name" field). Maybe @Weiko has some input on this?

[Weiko]

Should we move auto-complete "Untitled" on the record identifier field ?

Not sure how to go about this one, as the "Untitled" value is generated on backend (default value for the "name" field). Maybe @Weiko has some input on this?

That means "default value" should be editable for existing fields. I'm not sure this has been really tested since the UI does not allow that, but yes it should work 🤔.
We could also make this field required, by also editing the isNullable. However I'm pretty sure that this case is not managed by our migration service since updating nullability on DB level has some edge cases to handle (for example if there is existing rows). => Actually we already create TEXT field as non-nullable (cc @charlesBochet).
I don't have a clear answer yet, I suggest that we discuss with the product as well 👍

[charlesBochet]

@Weiko @thaisguigon
From a DB perspective, it is non nullable because all text fields are non nullable have a default value: "".

From an API perspective, all fields are non required because they are either nullable in DB or have a default value. (here name has default value so is non-required)

[charlesBochet]

@thaisguigon I think we are adding too much complexity on the recordTable:

• I think we should aim to reduce the number of selectors we have as this gets quickly out of control : contributors are not forced to re-use selectors so they usually re-code the logic again and again, or introduce their own selectors that are slightly different. It's hard to get this factored. I prefer having basic states and basic selector and factorize logic in components or utils if it's needed, but usually it is not: for example the availableTableColumnKey is only extracting the availableTableColumnKey
• I think we should not add all this logic about labelIdentifiers fetching in the table itself. We could add it to mapViewFieldsToColumnDefinitions "isLabelIdentifer"?

[thaisguigon]

@thaisguigon I think we are adding too much complexity on the recordTable:

• I think we should aim to reduce the number of selectors we have as this gets quickly out of control : contributors are not forced to re-use selectors so they usually re-code the logic again and again, or introduce their own selectors that are slightly different. It's hard to get this factored. I prefer having basic states and basic selector and factorize logic in components or utils if it's needed, but usually it is not: for example the availableTableColumnKey is only extracting the availableTableColumnKey
• I think we should not add all this logic about labelIdentifiers fetching in the table itself. We could add it to mapViewFieldsToColumnDefinitions "isLabelIdentifer"?

@charlesBochet Done:

• removed some selectors
• added some utils
• moved the label identifier logic to mapViewFieldsToColumnDefinitions