shopinvader_product_stock: fix stock qty compute

[len-foss]

[simahawk]

a title would help :)

[len-foss]

Well, I was short on time and the fact that Travis would have been red anyway did not motivate me. But as you are here, the issue baffled me: it appears that before the change, the stock quantities that are exported are the one on the product template, not on the product. Is there something we did not understand?

[simahawk]

Well, I was short on time and the fact that Travis would have been red anyway did not motivate me. But as you are here, the issue baffled me: it appears that before the change, the stock quantities that are exported are the one on the product template, not on the product. Is there something we did not understand?

@len-foss as the default field is qty_available then you should have any issue. OTOH it seems more correct to get to the right model when possible.

[len-foss]

@simahawk It seems I don't understand fully what happens, because on my end this test breaks non-deterministically. Most of the time, the test I pushed fails on AssertionError: 20.0 != 9.0. I pushed another commit that shows that this happens because the field is non-deterministically set (either on the record_id, or the inherited record_id). Is this a known problem, or is there something I miss?

[rousseldenis]

I think the issue is the design of models as inheritance order for parallel models is not guaranteed:

[len-foss]

To expand a bit, _add_inherited_fields will add the fields from self._inherits, which is {'shopinvader.product': 'shopinvader_product_id', 'product.product': 'record_id'} (randomly ordered). So the common fields will randomly be taken either from the template or from the variant (all of them follow the same choice -- so even the initial fix is wrong, we can never rely on self.

[len-foss]

Just a small remark: unfortunately it's not possible to cheat our way out by declaring the inherits as OrderedDict([("product.product", "record_id"), ("shopinvader.product", "shopinvader_product_id")]) Because of the way the resulting class is built out in _build_model_attributes, the order is messed up anyway.

[github-actions[bot]]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.