-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
Improve order fulfillment process #1777
Conversation
2ee01cd
to
31f7f46
Compare
Codecov Report
@@ Coverage Diff @@
## master #1777 +/- ##
==========================================
- Coverage 83.52% 83.34% -0.18%
==========================================
Files 145 145
Lines 6250 6179 -71
Branches 664 652 -12
==========================================
- Hits 5220 5150 -70
- Misses 856 858 +2
+ Partials 174 171 -3
Continue to review full report at Codecov.
|
5b05ada
to
0850e76
Compare
Codecov Report
@@ Coverage Diff @@
## master #1777 +/- ##
=========================================
Coverage ? 83.94%
=========================================
Files ? 151
Lines ? 6427
Branches ? 665
=========================================
Hits ? 5395
Misses ? 857
Partials ? 175
Continue to review full report at Codecov.
|
e337d73
to
f4e170d
Compare
|
||
There are three possible delivery group statuses: | ||
There are two possible fulfillment statuses: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't there exist a third status to indicate which groups are already dispatched?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I came from the assumption, that we consider fulfilled group as dispatched. This is why user also is asked for tracking number, when fulfilling the items.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does that work with packing slips? The usual flow for a warehouse (where packing slips are used) is:
- dispatcher creates a shipment group (fulfillment)
- warehouse prints a packing slip
- warehouse collects and packages items
- warehouse dispatches the order (this is usually the moment you know the tracking number)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now we could leave this as it is, cause it's quite simple. We can discuss further changes in the flow and open new PR if necessary.
model_name='order', | ||
name='last_status_change', | ||
), | ||
migrations.RunPython(assign_order_to_lines, migrations.RunPython.noop) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we please move the RunPython
action to a separate migration file?
889a28d
to
dc6610a
Compare
6cafb3a
to
669a38d
Compare
saleor/order/models.py
Outdated
|
||
@property | ||
def quantity_fulfilled(self): | ||
lines = FulfillmentLine.objects.filter( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't the logic here too much for a property? I would expect from a property to perform rather simple logic based on model fields. Here we're performing a database query. I'm afraid that sooner or later this will lead to duplicated queries or someone will call it in a template (performing queries from templates isn't a good practice). Wouldn't it be better to denormalize this value and store it in the database? @patrys What's your view on that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 from my end. Executing queries in a property adds a hidden cost to something that looks innocent plus there is no way to optimize it.
As for the logic if FulfillmentLine
objects for the order are already prefetched then iterating over lines.all()
and filtering in Python is cheaper (as it won't touch the database) than executing a filter()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, if we did the filtering in Python then such logic would be acceptable for a property in my opinion. I assume that anyone using this will have to ensure proper prefetching.
22f5d06
to
ff947ad
Compare
5580b38
to
c9da395
Compare
I want to merge this change because it simplifies order related logic.
DeliveryGroup
model is removed with all logic related to it and all order lines are placed directly intoOrder
.Fulfillment
model is introduced and it represents single shipment of many order lines in given quantity. There may be many fulfillments in an order and each order line may be in many fulfillments.Closes #1767, closes #1850
Pull Request Checklist
pycodestyle
,pydocstyle
,pylint
.eslint
.[Edit]
Order details dashboard page.
Fulfillment view.
Cancel fulfillment modal.
Order details storefront.