The product_id_change was always triggered at the creation of a sale order line.
This is due to the 'type' field that is no longer present in 8.0 and makes the
condition to be always verified.
-account:_fix_tax_included_price
If a fiscal position mapped an included tax on a SO or on a PO line
then the price unit of the product must be recomputed.
-purchase: onchange_product_id test
Test that when an included tax is mapped by a fiscal position, the included tax must be
subtracted to the price of the product.
-sale:product_id_change test
Test that when an included tax is mapped by a fiscal position, the included tax must be
subtracted to the price of the product.
opw:647321
f26b94f had as goal to filter the taxes of the product
according to the company when the sale.order
was created/edited as SUPERUSER_ID
(Who ignores the record rules).
Unfortunetaly, to filter the taxes,
it used the company of the customer,
while it's actually the company of the order which
should be used.
Indeed, for instance,
partners can be shared among all companies.
It was way less simple to access the company
of the sale.order, this parameter being
not available in the on_change method signature.
This is the easiest way to solve this issue
without breaking the API / retro-compatibility.
opw-647819
This is a regression from rev.
1cedcf6abb
Not updating the product uos qty on updating the uom qty
is wrong, and it has multiple side-effect.
The SO line margin not being correctly recomputed
when changing the quantity is one of them.
opw-647902
Add company when calling product_id_change from _prepare_advance_invoice_vals on
sale.advance.payment.inv wizard.
This way we have same on change call as the one called from account_invoice
(e.g. on uos_id_change and onchange_account_id).
Closes#7939
When a partial invoice is created from a sale order, the field "note"
in the sale order must be written in the field "comment" of the invoice.
opw:646852
The problem originally arises in the frontend (eCommerce). In this case, it is
necessary to switch the user id to the SUPERUSER_ID in order to be allowed to
create a SO. This is done in the method sale_get_order in the module
website_sale. The consequence is that in a multicompany configuration, all taxes
of the product will be retrieved and applied in the frontend.
This fix filters the taxes retrieved to keep only the ones which apply to the
company of the partner, when the user id is SUPERUSER_ID.
opw-645258
opw-645915
The unticked option in Sales settings "Prepare invoices based on task's activities" doesn't
have to uninstall the options "Record timesheet lines per tasks" and "Generate tasks from sale orders"
in Project settings.
When "Prepare invoices based on task's activities" is unticked, this fix avoid to uninstall these options each
time we go to Sales settings because "onchange_task_work" is triggered each time we go to Sales settings.
opw:645833
The field "state" in "sale.report" model must consider the state used
by "sale.order.line" to be consistent with the view created in this model.
The function _sale_count in 'product.product' model must return
the number of product included in a "confirmed" or "done" sale order line.
opw:644200
4adb4b8d15
corrected the fact the quotation email
wasn't sent if you did not come back
from the payment provider
(when you closed your browser after
the payment but before coming back
to Odoo).
Before the above revision, the quotation
email was sent for payment methods
not redirecting to payment providers,
like transfers. It was no longer the case
with the above revision.
This revision re-introduces this behavior:
If there is a feedback from a transaction,
but the transaction isn't confirmed,
we send the quotation email without confirming
the sale order, like it was the case before
opw-644670
Not just when coming back from the payment provider to the
payment validation route `/shop/payment/validate`.
Otherwise, if you do not come back from the payment provider
page, that you quit just after having paid but just before
being redirected to Odoo, you do not receive the email.
The change within the `sale` module, while this issue concerns
`website_sale` only, has been accepted because this is a mechanism
that could be used by other modules.
opw-644348
The product_id_change method of sale.order.line
ignored the passed context.
The context was simply overwritten,
which is no a good practice.
Besides, it prevents customizations.
Closes#7447
opw-643983
When confirming a sales order with invoicing control
based on "Delivery order", confirming the quotation
didn't post the "Quotation Confirmed" message
subtype in the sales order thread.
opw-642744
During tests, some creation of user records would unnecessarily trigger
password reset or set a password, both of which would trigger password
hashing which takes some time (for good reasons).
Fix by:
* passing no_reset_password in YAML tests and some Python tests still
missing it (a number of Python tests already used it)
* removing passwords from YAML records as they're never necessary, the
test user records are not expected to ever log in
Martin Trigaux
Odoo Translation Bot
Christophe Simonis
Pedro M. Baeza
Denis Ledoux
Goffin Simon
Juan Jose Scarafia
Nicolas Martinelli
Olivier Dony
Valentin Chemiere
Jos De Graeve
Anaël Closson
Xavier Morel
Peter Alabaster
Alexandre Fayolle