Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Selects correct stores value option #9549

Merged
merged 1 commit into from
May 16, 2017
Merged

Conversation

Corefix
Copy link
Contributor

@Corefix Corefix commented May 8, 2017

When saving the product and having indexers on live mode at least the value option for flat tabels gets a random stores value, this orders them and filters down to be either the selected store or the default stores value.

Description

Filter of unwanted stores values, and makes sure that we pic the store value if it is present and we have to chose between store value and admin value (default value)

Manual testing scenarios

To test before this patch

  1. Have multiple store instances on your Magento store.
  2. Have a dropdown field set to be visible in flat tables, enter values across all stores in the options
  3. Have product flat indexers set to update on save.
  4. Check database or FE to see the value is now from the wrong store in the _value field for some of the stores.

When saving the product and having indexers on live mode at least the value option for flat tabels gets a random stores value, this orders them and filters down to be either the selected store or the default stores value.
@vrann vrann self-assigned this May 9, 2017
@vrann vrann added this to the May 2017 milestone May 9, 2017
@vrann vrann added the develop label May 9, 2017
@vrann
Copy link
Contributor

vrann commented May 15, 2017

@Corefix I was not able to reproduce the issue, however, I'm was not sure I correctly understood the issue description and the steps to reproduce. So here is what I did:

  1. enable flat Catalog -> Storefront -> Use Flat Category, Use Flat Product
  2. create Store “Venomous" with Default Category, create store view
  3. create attribute Stores -> Product -> Add New Attribute
    • Default Label -> “where"
    • Input Type -> Dropdown
    • Add Options
      • first:
        • admin: low
        • default store view: low22
        • venomous store view: low33
      • high
        • admin: high
        • default store view: high22
        • venomous store view: high33
    • Storefront Properties -> everything to Yes
    • Save attribute and add it to Default Attribute Set
  4. Create Product
    • Set “where" attribute on Default store to “low22"
    • Save
    • Set “where" attribute on “Venomous" store to “high33"
    • Save
  5. Check database table: select * from catalog_product_flat_2;

I’m getting “where” column value for the product equals to “high33”, which is consistent with what I expected.

Can you please help to understand your use-case?

@Corefix
Copy link
Contributor Author

Corefix commented May 15, 2017

Hi @vrann

So its not about setting the attribute differently on each store that might work, its about the flat indexer not seeing the store level value.

So if you have set for example have set the product on the default scope set the attribute "where" to have the option "high".

This should go into the flat tables as follows:

catalog_product_flat_1:
where_value = high22

catalog_product_flat_2:
where_value = high33

But it could come out as:

catalog_product_flat_1:
where_value = high33

catalog_product_flat_2:
where_value = high33

Or

catalog_product_flat_1:
where_value = high22

catalog_product_flat_2:
where_value = high22

Depending on what value was the last one saved. As you can see on the additional statement added I just select from default or the current store scope, and order them so the store scope value would take priority. If this is not their any stores value could be selected.

I hope this makes sence.

@vrann
Copy link
Contributor

vrann commented May 15, 2017

@Corefix thank you for the explanation, now it makes much more sense. I did reproduce the issue and observe the weird behavior. The fix you provided targets that specific place in the logic where it should be fixed and makes sense to me. Will accept.

@magento-team
Copy link
Contributor

@Corefix thank you for your contribution. Your Pull Request has been successfully merged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants