fix(plugin-import-export): the import with CSV file doesn't populate fields correctly

[TommasoCappelletti]

Describe the Bug

When fields are formatted in snake_case, they are not imported correctly. This issue occurs because the import/export plugin relies on the underscore character (_) within CSV files to identify the nesting of field groups. Consequently, it misinterprets the snake_case field names as nested groups rather than flat fields.

The plugin should be able to distinguish between standard snake_case field names and the underscores used for group nesting, allowing snake_case fields to be imported and exported correctly without data loss or mapping errors.

Here is where is the function that doesn't manage this particular case:

packages/plugin-import-export/src/utilities/unflattenObject.ts

This is test file that doesn't manage this case:

packages/plugin-import-export/src/utilities/unflattenObject.spec.ts

This is the test that should pass:

describe('fields with any permitted name types', () => {
const fields: FlattenedField[] = [
{
name: 'simple',
type: 'text',
} as FlattenedField,
{
name: 'camelCase',
type: 'text',
} as FlattenedField,
{
name: 'PascalCase',
type: 'text',
} as FlattenedField,
{
name: 'with_underscores',
type: 'text',
} as FlattenedField,
{
name: '_start_with_underscore',
type: 'text',
} as FlattenedField,
{
name: 'with_numbers_1',
type: 'text',
} as FlattenedField,
{
name: 'localized_with_underscores_with_numbers_1',
type: 'text',
localized: true,
} as FlattenedField,
]

it('should handle documented fields names', () => {
const data = {
simple: 'simple',
camelCase: 'camelCase',
PascalCase: 'PascalCase',
with_underscores: 'with_underscores',
_start_with_underscore: '_start_with_underscore',
with_numbers_1: 'with_numbers_1',
localized_with_underscores_with_numbers_1_en: 'localized_with_underscores_with_numbers_1_en',
localized_with_underscores_with_numbers_1_es: 'localized_with_underscores_with_numbers_1_es',
}

const result = unflattenObject({ data, fields, req: mockReq })

expect(result).toEqual({
simple: 'simple',
camelCase: 'camelCase',
PascalCase: 'PascalCase',
with_underscores: 'with_underscores',
_start_with_underscore: '_start_with_underscore',
with_numbers_1: 'with_numbers_1',
localized_with_underscores_with_numbers_1: {
en: 'localized_with_underscores_with_numbers_1_en',
es: 'localized_with_underscores_with_numbers_1_es',
},
})
})

const groupFields: FlattenedField[] = [
{
name: 'group',
type: 'group',
flattenedFields: [
...fields,
],
} as FlattenedField,
]

it('should handle documented fields names nested', () => {
const data = {
group_simple: 'simple',
group_camelCase: 'camelCase',
group_PascalCase: 'PascalCase',
group_with_underscores: 'with_underscores',
group__start_with_underscore: '_start_with_underscore',
group_with_numbers_1: 'with_numbers_1',
group_localized_with_underscores_with_numbers_1_en: 'localized_with_underscores_with_numbers_1_en',
group_localized_with_underscores_with_numbers_1_es: 'localized_with_underscores_with_numbers_1_es',
}

const result = unflattenObject({ data, fields: groupFields, req: mockReq })

expect(result).toEqual({
group: {
simple: 'simple',
camelCase: 'camelCase',
PascalCase: 'PascalCase',
with_underscores: 'with_underscores',
_start_with_underscore: '_start_with_underscore',
with_numbers_1: 'with_numbers_1',
localized_with_underscores_with_numbers_1: {
en: 'localized_with_underscores_with_numbers_1_en',
es: 'localized_with_underscores_with_numbers_1_es',
},
},
})
})
})

Link to the code that reproduces this issue

https://github.com/TommasoCappelletti/payload-issue-plugin-import-export.git

Reproduction Steps

• Export the data to a CSV (select the vat_number field);
• Modify the CSV (the vat_number field);
• Attempt to import the CSV;
• See that the vat_number field has not been updated.

Which area(s) are affected?

plugin: import-export

Environment Info

Binaries:
  Node: 22.22.0
  npm: 10.9.4
  Yarn: 3.8.6
  pnpm: N/A
Relevant Packages:
  payload: 3.85.0
Operating System:
  Platform: linux
  Arch: x64
  Version: #35~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue May 26 19:30:42 UTC 2
  Available memory (MB): 63500
  Available CPU cores: 16

[github-actions]

Please add a reproduction in order for us to be able to investigate.

Depending on the quality of reproduction steps, this issue may be closed if no reproduction is provided.

Why was this issue marked with the invalid-reproduction label?

To be able to investigate, we need access to a reproduction to identify what triggered the issue. We prefer a link to a public GitHub repository created with create-payload-app@latest -t blank or a forked/branched version of this repository with tests added (more info in the reproduction-guide).

To make sure the issue is resolved as quickly as possible, please make sure that the reproduction is as minimal as possible. This means that you should remove unnecessary code, files, and dependencies that do not contribute to the issue. Ensure your reproduction does not depend on secrets, 3rd party registries, private dependencies, or any other data that cannot be made public. Avoid a reproduction including a whole monorepo (unless relevant to the issue). The easier it is to reproduce the issue, the quicker we can help.

Please test your reproduction against the latest version of Payload to make sure your issue has not already been fixed.

I added a link, why was it still marked?

Ensure the link is pointing to a codebase that is accessible (e.g. not a private repository). "example.com", "n/a", "will add later", etc. are not acceptable links -- we need to see a public codebase. See the above section for accepted links.

Useful Resources

• Reproduction Guide
• Contributing to Payload