It seems that the \Magento\Catalog\Model\ResourceModel\Collection\AbstractCollection will always, when there is no store id supplied, set it to the value supplied by $this->_storeManager->getStore()->getId()) (= 1 for example).
This will result in store 1 values being used to identify the categories on product import instead of the values from admin scope (store 0).
The core behaviour may be questionable, but we can just set it to 0 in our \Model\Import\Product\CategoryProcessor to avoid this.
Fixed Issues (if relevant)
magento-engcom/import-export-improvements#88
Manual testing scenarios
Reproduction as described in #88 (short version):
Create a category 'Test'
Set the category name to something completely different on default storeview
Create a csv with catalog product data
Set 'Default Category/Test' as the 'categories' value
Import
Contribution checklist
[ ] Pull request has a meaningful description of its purpose
[ ] All commits are accompanied by meaningful commit messages
[ ] All new or changed code is covered with unit/integration tests (if applicable)
[ ] All automated tests passed successfully (all builds on Travis CI are green)
Solved the integration test problem by adjusting the test csv used... obviously it was meant to be using storeId 1 value for identification of the category (!?).
Description
It seems that the \Magento\Catalog\Model\ResourceModel\Collection\AbstractCollection will always, when there is no store id supplied, set it to the value supplied by $this->_storeManager->getStore()->getId()) (= 1 for example). This will result in store 1 values being used to identify the categories on product import instead of the values from admin scope (store 0).
The core behaviour may be questionable, but we can just set it to 0 in our \Model\Import\Product\CategoryProcessor to avoid this.
Fixed Issues (if relevant)
Manual testing scenarios
Reproduction as described in #88 (short version):
Contribution checklist