[Improvement]: Combine the attribute for the import loading strategy with a defined object tree path

[thomas-udalrik]

Improvement description

Improvement description (User story)

As a data maintainer of a product catalog I want to define a path (optional) to combine with the value of "Data Source Index" in order to be able to use the same class in the import resolver for multiple product vendors where the identifying attribute may not be unique.

Current situation
The import resolver configuration is lacking an option to limit a selection of elements by data object tree paths.

This leads to a situation where there can be 2 import files in separate import configuration jobs for different vendors in which the vendor SKU may not be unique in the whole PIM system.

Example:

Vendor A

SKU: ABC
Product: Super Food 2000

Vendor B

SKU: ABC
Product: Fashion Magazine

Since the only suitable loading strategy is by "Attribute" on the identifying field "SKU" it's not possible to create a clear configuration, where there is defined from which path the elements get loaded. The result is unpredictable and it's likely that the wrong element gets loaded and fatally updated by the wrong feed import.

Currently the challenge is afaik only solvable by modifying the original import source file to contain the unique identifier itself - which should not be a necessary workaround.

The improvement and herby solution to me is to introduce the combination with the path option as it is present in the sections "Element Creation" and "Element Location Update".

Draft:

[github-actions]

Thanks a lot for reporting the issue. We did not consider the issue as "Pimcore:Priority", "Pimcore:ToDo" or "Pimcore:Backlog", so we're not going to work on that anytime soon. Please create a pull request to fix the issue if this is a bug report. We'll then review it as quickly as possible. If you're interested in contributing a feature, please contact us first here before creating a pull request. We'll then decide whether we'd accept it or not. Thanks for your understanding.

[nilscyber]

I strongly agree with this suggestion—it would be a significant improvement to the functionality.

@thomas-udalrik , have you found a workaround or similar to the issue?

[fashxp]

this should be pretty simple to implement, similar to what happened here with the unpublished: #83

just be careful about SQL injection!

[thomas-udalrik]

@nilscyber

have you found a workaround or similar to the issue?

No - the only workaround I could think of was using multiple data classes or manipulating the source data, which both is not really a solution.

@fashxp

this should be pretty simple to implement

Maybe I can have a look into it if I have to solve the issue again.

[nilscyber]

@thomas-udalrik . Thank you for taking time to answer! I was also thinking about multiple classes and I started building that with a common brick that could be reused on each class. But it's not really a great solution if you have very many vendors. And also, when you'd need to extract data from the system you couldn't do that easily. So I'm sticking with one standard product model for now. In my case this is not urgent, but in the long run it's an important feature.

@fashxp . I'm pretty new to pimcore so I'm not yet competent to solve it myself. But thank you for the suggestion!