* can't compare a function and a float in Python 3 (it works in
Python 2, though it makes no sense and was just hiding a bug)
* no iteritems method on dict in Python 3 (use compat helper)
* P3-invalid "except" syntax (sadly pylint apparently does not have a
standard lint for that, though it's easy to catch... if you can run
the code under P3)
Thanks to @xmo-odoo and its Python3 virtual machine for spotting this
one (and shame on Python2 that does not crash when comparing a method to
a float because voilà).
When an order is shipped, a notification email is sent to the customer.
If there is a tracking URL, it is included in the email.
(and also a bit of refactoring)
Having price and availability as computed fields of a delivery.carrier
may sound handy.
Actually, it comes with is batch of lame hacks, poor performances and
terrifying heisenbugs.
We will try to make something better. It has to start with a breaking.
When updating a carrier that is not "fixed" or "base_on_rule", this
method was creating unnecessary delivery.price.rule at each write.
This patch fixes this issue.
Closes PR #17443
``import odoo.addons.foo as bar`` doesn't seem to properly trigger the
import hook in Python 3 (it blows up on decimal_precision and
base). Thus convert *all* examples of that pattern to the more
sensible ``from odoo.addons import foo as bar``.
If the picking has no carrier set, do not open the put in pack wizard
and keep the behavior of a classic picking. Also, filter the delivery
packages according to the carrier (note: this doesn't work at the moment
because of a bug in the new views, but it'll be fixed very soon, so we
merge anyway).
Also, remove an harmless typo in `manage_package_type` method.
When get_price() is called during tests, a ValidationError was returned but not catched
correctly due to the unavailability of delivery service.
Because this method is called during the creation of new sale order, it leads to some
operational error (broken cursor).
On a picking, the UoM of the weight is the default UoM for the weight
category. However, weights in Odoo are always considered to be
kilograms.
This might lead to inconsistencies between what is displayed on the
picking and what is printed on a shipper label.
opw-702564
Because now the carrier id is set on all picking from the same
procurement group, we want to call the carrier API only when there are
some package with a packaging_id set on it.
We have moved the 'quant.package' view into a wizard, because it's
always used as a wizard, and and there was context trouble with the
'Save' button as a button with nale 'write' (the context was mixed with
the field, and there were two write action whan "Save button was
clicked.
When our warehouse is configured to work as 'pick -> pack -> ship'
only the last picking (ship) has the information of which carrier
is set for this delivery.
This is a problem, because we also need the information in the packing
zone, to put in a pack with the correct package type.
To fix this problem, instead of overriding the function 'action_confirm'
which put the 'carrier_id' only on the 'ship' location. We set the
'sale_order_id' on the procurement groups created from the sales
order, and propagate it to the picking through the stock moves
from the procurement group.
The price set for the non integrated carrier must be the same either when you
set it on the SO with button "set_price" or when you set it on the stock picking.
The field "carrier_price" must be in readonly when the state of the picking is done.
opw:691224
Christophe Simonis