Feature/minimal variant price sorting

[derenio]

This PR:

• adds minimal_variant_price to the Product model,
  • a field that stores the minimal price among all the variants of the product,
• updates the minimal_variant_price on:
  • product's creation/update,
  • product variant's creation/update/removal,
  • sale's creation/update.

[NyanKiyoshi]

Did you notice that pytest is printing 100 time:

.tox/py36-django22/lib/python3.6/site-packages/django/db/models/fields/init.py:1363

I believe it's a warning, but I don't see any message. I checked, the travis build on master doesn't do that. Could you take a look?

[django-queries]

Here is the report for d7eded6 (mirumee/saleor @ feature/minimal_variant_price_sorting)
Base comparison is 246c788.

No differences were found. (click me)

# api.benchmark checkout
  test name                           	left count 	right count	duplicate count
  ------------------------------------	-----------	-----------	---------------
  add billing address to checkout     	         34	         34	             20
  add shipping to checkout            	          7	          7	              0
  checkout payment charge             	         14	         14	              0
  complete checkout                   	          6	          6	              0
  create checkout                     	         48	         48	             24

# api.benchmark homepage
  test name                           	left count 	right count	duplicate count
  ------------------------------------	-----------	-----------	---------------
  retrieve main menu                  	          5	          5	              0
  retrieve product list               	          4	          4	              0
  retrieve secondary menu             	          5	          5	              0
  retrieve shop                       	          2	          2	              0

# api.benchmark product
  test name                           	left count 	right count	duplicate count
  ------------------------------------	-----------	-----------	---------------
  product details                     	         13	         13	              3

# api.benchmark variant
  test name                           	left count 	right count	duplicate count
  ------------------------------------	-----------	-----------	---------------
  retrieve variant list               	         15	         15	              8

[codecov]

Codecov Report

Merging #4416 into master will increase coverage by <.01%.
The diff coverage is 96.42%.

@@            Coverage Diff            @@
##           master   #4416      +/-   ##
=========================================
+ Coverage   91.39%   91.4%   +<.01%     
=========================================
  Files         308     308              
  Lines       18261   18326      +65     
  Branches     1814    1835      +21     
=========================================
+ Hits        16690   16751      +61     
  Misses       1058    1058              
- Partials      513     517       +4

Impacted Files	Coverage Δ
saleor/graphql/product/schema.py	100% <ø> (ø)	⬆️
saleor/graphql/product/resolvers.py	85% <100%> (-0.15%)	⬇️
saleor/discount/utils.py	100% <100%> (+3.15%)	⬆️
saleor/dashboard/product/forms.py	91.8% <100%> (+0.08%)	⬆️
saleor/graphql/product/mutations/products.py	96.64% <100%> (+0.05%)	⬆️
saleor/graphql/product/enums.py	92.85% <100%> (+0.26%)	⬆️
saleor/graphql/product/filters.py	91.77% <100%> (-0.01%)	⬇️
saleor/graphql/discount/mutations.py	98.3% <100%> (+0.09%)	⬆️
saleor/graphql/product/types/products.py	91.9% <100%> (+0.01%)	⬆️
saleor/dashboard/product/views.py	93.4% <100%> (+0.03%)	⬆️
... and 27 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 246c788...d7eded6. Read the comment docs.

[koradon]

@derenio please rebase this PR to master

[koradon]

@derenio please fix CI

[maarcingebala]

@derenio Please rebase this branch with master as we've merged a large PR yesterday. Then I'll be able to re-review it.

[derenio]

@maarcingebala just rebased the PR.

[maarcingebala]

In API we also have bulk mutations that would affect minimal prices, such as:

• saleBulkDelete
• categoryBulkDelete
• collectionBulkDelete
• collectionBulkPublish
• productVariantBulkDelete

But I guess we could add support for calculating minimal prices in bulk actions in a separate PR as well.

[maarcingebala]

How do we handle published vs. unpublished collections in terms of minimal prices? E.g., if there is a sale for a particular collection, but the collection isn't published yet. Can we even create a sale for unpublished collections? I'm not sure how it works now but I'm writing that down for us not to forget to check it.

[koradon]

Publish/unpublish and calculating of minimal price are for me two separate things.
We should be able to publish/unpublish every variant we want and calculate the minimal price if there is any price to calculate.

[maarcingebala]

@koradon I think it is related, but the problem is more general. Consider this case:

1. I have a collection with a bunch of products. The collection is not published.
2. I'm creating a sale and associating it with the above collection.
   Now - is the discount active, if the collection is not published yet? Currently, it seems that it is which I consider a bug. But in general - both discounts and collections can be activated/published at some point in the future, and minimal variant price should become valid from that point of time (or should be recalculated at that point).

Maybe the simplest solution is to have a periodic task that recalculates all prices based on what is currently published in the store.

[koradon]

@maarcingebala yes, we ware talking about designing periodic task for recalculating prices. That was the main save behavior that will fix any mistakes in our logic.
According to your example:
We should calculate min_price every time when Sale or Collection changes state.

[derenio]

@maarcingebala I've rebased (twice x|) onto the latest master to resolve conflicts on the Pipfile.lock and the migration files.