Import product function error. Importing "product_online" attribute value is applied to the Store but not Store View.

[piotrekkaminski]

From @Tonop on April 27, 2017 19:9

Preconditions

Magento: 2.1.6
PHP: 5.6.26
MySQL: 14.14 Distrib 5.7.15

Steps to reproduce

There are two store views View1 and View2

• There are two sub-products Product1 and Product2
• It needs to have Product1 is enabled in View1 and disabled in View2
• It needs to have Product2 is enabled in View2 and disabled in View1
• Prepare two files with data for import with following attribute values (simplified set):

sku;store_view_code;product_websites;product_online
File 1: Product1 ;View1;store;1
File 2: Product1 ;View2;store;2

1. Import file 1
2. Import file 2

Expected result

1. Product1 is enabled in View1
2. Product1 is disabled in View2

P.S. I tried set "product_online" values 0 and 1 but it didnt affect.

Actual result

Product1 is disabled in View1 and disabled in View2
System applies "product_online" attribute to the store but not store view.

1. [Screenshot, logs]

Copied from original issue: magento/magento2#9437

[piotrekkaminski]

From @vityakopin on June 29, 2017 9:56

Internal ticket MAGETWO-70330 was created.

[piotrekkaminski]

From @magento-engcom-team on October 6, 2017 13:30

@Tonop, thank you for your report.
We've created internal ticket(s) MAGETWO-70330 to track progress on the issue.

[adam-paterson]

@piotrekkaminski @dmanners

I'm not sure this is an issue. What are your thoughts?

product_online maps to the product attribute status which has two possible values STATUS_ENABLED = 1 or STATUS_DISABLED = 2. The status attribute has a Website scope and so I would expect not to be able to set the status of a product for a particular store view.

[Tonop]

Hi there,

How is possible to change the scope of the attribute from website to store?

[adam-paterson]

Hey @Tonop,

I wouldn't recommend making a scope change to a system attribute. I'll continue to look into this to ensure I'm correct with my findings.

Feel free to email me at hello[at]adampaterson.co.uk. We could talk through your requirements and see if there is actually a need to have this attribute at a store view scope rather than website.

[dmanners]

As discussed with @akaplya the following idea was raised.

Import should validate input data if, data assigned to website level has different values for associated stores Import should raise an exception.import should validate input data if, data assigned to website level has different values for associated stores Import should raise an exception.

[mautz-et-tong]

What's good first of all is that this error has the same behaviour in the backend. And to stay consistent we should have a look at the backend.
For example, if you are on the store view 1 and enable the product and save it, it will be enabled in the store view 2 because they belong to the same website and the product status is website based. So in this case, we have a consistency between the reported error here and the backend behaviour.

There are a few possibilities here, but they need to be discussed:

1. We can ignore upper scopes while importing on a specific scope level. E.g. on this example product_online wouldn't be imported because the attribute scope is website but the scope in the csv is store. In this case, we have to check each attribute scope that should be imported against the scope set in the csv and inform the customer, which attributes will be ignored. In this case we should remove all attributes which can not be set in the choosen scope from the product edit page in the backend.

2. We change nothing and do some kind of better information. Like: If you import attributes on a lower scope as the attribute is set up, it will overwrite the attribute value on the lowest attribute scope level it is possible. In this case it would be the exact behaviour as in the error report. The second import is overwriting the product status of the product on the website level from the first import.

3. We add some kind of switch to the backend to let the user choose the behaviour between 1. or 2.

[dmanners]

I would suggest that we should start by doing step 2 and documenting what will happen in this case. It might be a nice idea to add some devdocs or some other place an FAQ for such cases and common issues. @lorikrell do you think that this would make sense to be in dev docs?