* make sure full content is translated in partner language
* drop useless product param (use line product_id field instead)
* delegate order lines name computation to computes for ecommerce carts
closesodoo/odoo#82620
Related: odoo/enterprise#23432
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce the issue:
- Install eCommerce module
- Go to Settings
- Ensure `Product Prices` is set to 'Tax included'
- Create a new Product as storable
- Set `Sales Price` to $1.0 and `Customer Taxes` to 10.00 %
- Under `Variants` tab add an Attribute with 2 values
- Set "Price Extra" to $2.0 to one of the variants
- Go to the Shop and select the product
Issue:
The extra price badge does not include the taxes
($2.0 instead of $2.2), however the final price does.
Cause:
The price_extra field from ptav (used in the badge) does not include
the taxes.
However, when calculating the final price, we do first the sum of all
prices (including the extra prices) and then apply the taxes.
Solution:
In the template, for each 'variants', we call `_get_combination_info`
to get the variant.price_extra with taxes included/excluded
depending the `Product Prices` setting.
opw-2669871
closesodoo/odoo#81949
X-original-commit: 6f04935d14d595faa3bb8dd6ba9e0dcf1d694886
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Do not fetch products attributes specifications if there is no
custom/no_variant attributes specified on the SOline.
Also update query counters according to recent performance changes
(batched followers insertion and other things)
closesodoo/odoo#81585
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Purpose
=======
The fields are not used, don't work correctly and there is a specific
report to generate the product prices according to the pricelist and
the ordered quantities
Cache the pricelist rule used for price computation in a dedicated non
stored field, since it is used both for the price_unit and the discount
computation.
This divides by 2 the number of pricelist requests/queries when
discounts computation is enabled.
* Do not rely on context, everything should be cleary specified through
parameters
Catch context keys in an unique targeted place to improve code clarity
* Drop strange old API
* do not provide unused partner parameter anymore
* do not provide products, qty as a list of tuple, we only request the
same qty for all products anyway
* Clear methods, add/adapt comments and docstrings
* Reduce potential side-effects of context content.
Issues
------
In the module sale, with the automatic invoicing configured.
Payment transaction generate, post and send the invoice when
they are post process.
In some country the invoice is not directly ready to be sent
due to some edi document
Solution
--------
use the mechanism introduce with https://github.com/odoo/odoo/commit/3a29371eb70309f46e3b8938434287fefc23b351
to delay the sending. Introduce a cron that check invoice to send
closesodoo/odoo#81526
X-original-commit: 97b74d8304337d901d9422418cbd0dcdcc46fcf5
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Issue
-----
When a customer sign and pay a sale order from the portal and
automatic invoicing is enabled, it generate an invoice.
Once the payment done the customer is redirected to
the sale order preview with a link to the invoice created.
To display the link to the invoice the method _portal_ensure_token() is
called and write the access token token.
In parallel, if the invoice need to send edi document, the cron job is
triggered at the posting of the invoice and thus the cron job try to
write as well on the invoice as the invoice link is displayed to the
customer
This lead to a concurrent update for the cron job that do not retry in
case of concurrent update as normal transactions do. So the edi document
is never synchronized and the invoice never sent
Solution
--------
Avoid to write on the invoice while displaying the sale order portal
view by already generating the access_token in the transaction that post
the invoice
closesodoo/odoo#81731
X-original-commit: ccf76a5b8c0671e69e8875ea476d13005dab8d72
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Context
-------
On some database, record rule may be configured in such a way
that user are able to read Purchase/Sale order
with a company_id != user.company_ids
Issue
-----
This commit https://github.com/odoo/odoo/commit/4dd150950274b1d7c3b24b7665443318f94323f6#
introduce a new field tax_country_id that require to be able to read
the fiscal.position as well.
The reading of a sale.order or purchase.order should not require the
right to read the fiscal.position for the computation of a technical
field only use during the modification.
Solution
--------
Compute tax_country_id as sudo
closesodoo/odoo#80049
X-original-commit: b329c3b18197ac6db5ffdf3cb4945a14997a1f0b
Signed-off-by: Olivier Dony <odo@odoo.com>
Signed-off-by: Thibault Francois <tfr@odoo.com>
Steps to reproduce:
- Install and launch sales
- In settings: activate price lists and discount; price list based on advanced rules
- Create a new price list; based on percentage (54%)*; applicable on all products; show discount
- Make sure the Public Price List has show discount activated
- Create a new quotation
- Select the Test pricelist
- Select a product (price 0.03 eur/$/other)*
- Change the price list to Public price list
- update the prices
- change the price list to Test price list
- update the prices
-> The Discount shown is not the one defined in the price list (66.67%)*
*(values for my example)
Solution:
Use the real price and not the a posteriori-rounded price for the computation of the discount in the `update_prices` method.
opw-2677884
closesodoo/odoo#81395
X-original-commit: 986dbc20952caae9d5a1b4b7ee34cfb994dea077
Signed-off-by: yosa-odoo <yosa@odoo.com>
The commit ca7d5701c6a46f7781bdc9af9f2d26cca880eb93 fixes issue with
backorder being to quickly canceled but as it call `action_cancel`
before the condition who's looking on the SO state, the condition can
never be matched as the SO state will always be `cancel`.
So, the exception about the SO being cancelled will not be logged on
following documents.
How to reproduce:
- Create a product and enable route MTO + Manufacture on it and create
a BoM for this product;
- Create a SO for this product and confirm it;
- Cancel the SO and check the generated MO => There is no exception
about the cancellation of the SO.
This commit fixes this issue and doesn't impact the previous fix.
task-2657799
closesodoo/odoo#79215closesodoo/odoo#81178closesodoo/odoo#81401
Related: odoo/enterprise#22008
Related: odoo/enterprise#22814
Related: odoo/enterprise#22896
Signed-off-by: Arnold Moyaux <arm@odoo.com>
With recent update to computed fields [1] order responsible is now always
changed to the partner responsible, or its commercial entity responsible.
This cause issues, notably with ACLs 'own documents only'. Indeed a salesperson
could update or set a partner on an order that would change the responsible and
lead to ACLs issues. Moreover some functional flows automatically set a partner
(online registrations, ...) that would make the responsible change without a
clear notification or warning.
We prefer to keep a less intrusive behavior, aka setting a responsible when
no one is set.
Task-2703285 (event performance)
Task-2703289 (event testing)
[1] odoo/odoo@210c9daebcclosesodoo/odoo#81025
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Compute was never called because of the compute, which lead to wrong
values (raising due to the SQL constraints).
Integrate the default in the compute directly.
* remove useless hook _get_customer_lead, since the field is now
computed
* Add inverse to properly modify existing stock moves when the customer
delay is modified
Victor Feyens