products_relation is now split in two, products_relation and
products_relation_incl_supplier_properties.
It avoids using a flag argument which is not a a good practice see:
https://martinfowler.com/bliki/FlagArgument.html
Due to primary_taxon and supplier having moved to the variant, filtering
by_producer and by_category with a custom order involves some
complicated sql queries. So we moved the sorting logic from
ProductsRenderer to OrderCycles::DistributedProductsService so we can
keep the complicated SQL logic contained in one place
- increments! & decrement! skip validations
- replaced increment! method calls
- one call was for a redefined increment! method
- the other for a regular(ActiveRecord::Persistence)
- removes increments/decrements definition now useless
Creating a variant actually create an extra one via the associated
product, as it will create a "standard variant".
As far as I can see there is no way around it, but it should be fixed
once the Product refactor is finished, and product becomes product
group.
Added a comment on the variant factory to explain the problem.
It's not ideal as it will slow down the test suite a little, but I think
it's better to write the code the way you would expect it, and it will
eventually get fixed.
The original spec check if the supplier and distributor where
updated after deleting product. In reality, the supplier and the
distributor are the same, so no need to test with the supplier
- Apply OR when filtering by both product properties and supplier
properties
- Apply AND when filtering by supplier properties and taxon
Filtering by product properties and taxon is handled by ransack, so
no change there
Due to moving the supplier to the variant, we had to add manual search
for producer properties instead of using ransack. So we need a way
for the frontend to diferenciate between product properties and producer
properties. This is the first step towards that
