A user may want to enter a coupon on the 'Payment' page, for example after he selected his delivery method. That way, he isn't forced to come back on the 'Preview Order' page to enter the coupon and reselect its shipping and delivery addresses.
When the function map_tax is called on the fiscal position in repair
lines to compute taxes, the partner and product are not passed to the
method which leads to mistakes when the module account_taxcloud tries to
get back the taxes for the specific partner and tic_category of the
product.
To fix the issue, we pass the product and partner that we already have
to the function map_tax.
When updating several moves for the same product, each time a write was done,
the move.product_id.standard_price was not updated due to "with_context(force_company=move.company_id.id)"
before write. Making a with_context before write changes the environment of the write, this why the cache
was not updated.
opw:709329
In mass mailing there is several possibilities of states when rendering
the widget with a possibly new value:
1. we are not in edition
a. we are in same language than user language => the editor content
can be updated
b. we are in a different language => the content cannot be updated
2. we are in edition
a. we are editing translation : the editor content cannot be updated
b. we are not editing translation (editor language == en_US)
i. we are requesting editor update (by having magic value
`on_change_model_and_list`) => the editor can be updated
ii. we are in same language than user language => the editor content
can be updated
iii. we are in a different language => the editor content cannot be
updated
In summary:
- if language is the same than the user, we can update the value
- if value is magic `on_change_model_and_list` and we are not translating,
we can update the editor
Before this commit, this worked as expected but for 2.a.ii. which if the
user language was not en_US would for example prevent editor updating.
closes#15583closes#15414
opw-708032
inspired by a27e24c6d1
note: the fix is a fix for 9.0 and saas-11 only.
The `rating_last_value` field was a related on the One2many
field `rating_ids`, on which the domain
`[('res_model', '=', self._name)]` is applied.
The problem is that this domain is not taken into account
when retrieving the records for which this value must be recomputed
Therefore, when computing the `rating_last_value` of a record,
if there was a record with the same `res_id` but another
`res_model`, the `rating_last_value` of this other record
is recomputed as well.
And, if you did not have the write access rights on this other
record, it raised a security exception.
There is at the moment no way in the ORM to filter the
depends on a specific subset of records for which
a computed field must be recomputed. Therefore,
we have no other choices to make the recomputation
of the records value as sudo. It will
recompute the value of other records which have nothing
to do with the one on which this value must be recomputed
(nothing to do except the id of the records which is common),
but at least it will succeed.
opw-709349
To reproduce:
1. Set a product with 'Perpetual (automated)' valuation and 'Average
Price' costing method.
2. Make a PO of 2 units, unit price 100, receive the delivery
=> Cost of product is 200 / 2 = 100
3. Make a SO of 1 unit, unit price 250. Confirm the SO, but do not
deliver the product and do not create the invoice.
4. Make a PO of 1 unit, unit price 200, receive the delivery
=> Cost of product is 400 / 3 = 133.33
5. Deliver the product sold
=> A debit of 133.33 is created on the 'Stock Output Account'
6. Make a PO of 1 unit, unit price 250, receive the delivery
=> Cost of product is 516.66 / 3 = 172.22
7. Create the invoice of the SO
=> A credit of 100 is created on the 'Stock Output Account'
There is an inconsistency between entries created at steps 5 and 7. The
reason is that the price unit on the stock move is not updated when the
delivery is completed.
opw-709726
The fields objects are responsible for creating their column/table and indexes.
The methods that update the schema are overridden to handle cases specific to
each type of field.
Simplify the API as much as possible, and delegate all the implementation
details to the models `ir.model`, `ir.model.fields`, `ir.model.constraint` and
`ir.model.relation`.
When uninstalling the module sale_margin, the view 'sale_report' was deleted
because this view was overwritten in this module.
But the module sale still uses the 'sale_report' view so it raised an error
each time this view was required.
opw:709328
Due to these commits, it was impossible to make an uninstall_hook
just after an uninstallation.
In some case, it 's needed to make an uninstall_hook just after the uninstallation.
Look this commit for example: e03c919e9955c5d3f678c0580744d9ef8c483c74
When the internal category of a product is in costing method = "Average Price"
and Inventory Valuation = "Perpetual(automated)", a button with the label
"Compute from average price" was displayed. But when clicking on this button,
it just allows to set the standard price. So the label of this button must be
"Set standard price".
opw:709329
- Create a partner with an invoicing and a delivery address.
- Connect to the website as this partner, create an order
- In the "Shipping & Billing" page, the delivery address is selected
automatically. Change and set to "Ship to the same address", and
confirm.
The "Ship To" address is still the delivery address, while it should be
the same than the "Bill To" address.
This reintroduces the v8 behavior:
`order_info.update(partner_shipping_id=checkout.get('shipping_id') or partner_id)`
https://github.com/odoo/odoo/blob/8.0/addons/website_sale/controllers/main.py#L623
Create the following
- Create a partner of type "Company" (Address 1)
- Add an "Invoicing" address to this partner (Address 2)
- Add a "Contact" address to this partner
- Authorize this contact as a portal user
Connect as the portal user created:
- Place an order from website, add a product to cart
- In "Shipping & Billing", confirm the order. The proposed billing
address is "Address 1". Do not change the shipping address ("Ship to
the same address"), and confirm.
The "Bill To" as well as the "Ship To" address are set to "Address 1".
This is a regression from v8. In v8, "Bill To" is set to "Address 2",
while "Ship To" is set to "Address 1".
opw-707283
Martin Trigaux