Do localizations honour the idField when linking entries?

[amityweb]

Hello. Not sure if its a bug report or feature request or just a How To question...

When I import entries with localizations, will the localizations honour the idField to match entries? Importing the main entries works OK, but when I then import localized content and in those refer to the English "myCustomField" value as per set in the idField, they are not linked to the english entry with that myCustomField value. I removed the entry ID number from the import because they were updating based on ID originally, but now the entry is matched to some other/wrong entry which I cant figure out. Its not matched to the entry with the same myCustomField as set in idField.

Thank you

  "pluginOptions": {
    "i18n": {
      "localized": true
    },
    "import-export-entries": {
      "idField": "myCustomField"
    }
  },

[amityweb]

Actually I think its working. Maybe I had an error in my json. This is what I just tried and it worked!

{               
    "version": 2,
    "data":
    {
        "api::category.category":
        {
            "1":
            {
                "title": "Test US",
                "myCustomField": "99999-us",
                "categoryDescription": "Lorem ipsum blah blah blah",
                "slug": "test-us",
                "SpecialistCategory": 0,

                "childCategories": [
                ],

                "locale": "en",
                "localizations": [],
                "createdAt": "2019-07-23T02:20:00.000Z",
                "updatedAt": "2021-06-10T15:41:00.000Z",
                "publishedAt": "2019-07-23T02:20:00.000Z",
                "createdBy": "4",
                "updatedBy": "4"
            },          
            "2":
            {
                "title": "Test FR",
                "myCustomField": "99999-fr",
                "categoryDescription": "Lorem ipsum blah blah blah",
                "slug": "test-fr",
                "SpecialistCategory": 0,

                "childCategories": [
                ],

                "locale": "fr-FR",
                "localizations": [
                    "99999-us"
                ],
                "createdAt": "2019-07-23T02:20:02.000Z",
                "updatedAt": "2019-08-14T12:17:12.000Z",
                "publishedAt": "2019-07-23T02:20:00.000Z",
                "createdBy": "4",
                "updatedBy": "4"
            }
        }
    }
}

BUT I did not change the unique identifier fields in the options. If I click options then its set at id even though I set it as myCustomField in the config. When I do change this unique identifier in the admin to myCustomField, the second import above wont import. If I import it separately it does then work.

So I am not sure what unique field it is using, this aspect is confusing. It "seems" to work when I do not change the idField in the admin and leave it at id, even though in config I set it to myCustomField (which it seems to use) but I am not using IDs anymore in the above (there is no need, as we dont know what they will be). I don't know if its using the one in config, or the one in admin, and whether its myCustomField or id. Your docs say "The idField specified from the import modal of the admin UI takes precedence over the one defined in the pluginOptions of the collection.". So I have a couple of questions about this:

1) If I set the fieldId in the config, does the selection showing in the admin (id) actually imply its not selected, its just selected the first in the drop down and its not using id? In which case, should your plugin options reflect what I set in the config? I assume it must be importing by myCustomField because its the only link between them in the data.

2) If I do choose myCustomField in the admin, how come it does not import the second localized one above, but it does import it OK if I dont choose myCustomField in the admin? (so assume its using my config setting).

Thanks!

[KestasVenslauskas]

I already made this bug report few months ago #127 Also there is an open PR #128 that fixes this issue, but is being ignored. So I made a patch for this PR to be applied to our project

[amityweb]

So sorry for the late reply, I did not see any notification you replied.

Thats great you have fixed it for you and shame no response from the developer... but I am not such an expert on node package development. I was looking into how to apply the patch but the file in my node_modules is a .js file and yours is a .ts file, and they have differences, so am not familiar enough with how this woks to proceed! Mine is v1.23.1.

[KestasVenslauskas]

@amityweb It's .ts because it's the source I've changed. Every .ts file will be converted into .js file after building. That how Typescript works.

So you do not need to update pre-built files but instead use patche in you dependency definitions. If you use NPM you can use this - https://www.npmjs.com/package/patch-package If you use yarn it has patching function internaly - https://yarnpkg.com/cli/patch

I do use yarn and at the end of my package.json I have:

...
  "packageManager": "yarn@3.5.1",
  "resolutions": {
    "strapi-plugin-import-export-entries@^1.21.0": "patch:strapi-plugin-import-export-entries@npm%3A1.21.0#./.yarn/patches/strapi-plugin-import-export-entries-npm-1.21.0-62d3a779c5.patch"
  }