* 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>
Prior to this commit, the company of the invoices generated through the use
of the `sale.advance.payment.inv` wizzard were not forced to the one of the
related sales orders. From the compute method on account.move the company would
then be either the one of the journal or the current company.
It seems that context_keys were used 'at least in industry_fsm_sale' in order
to ensure that the company was correctly set (although the one of the task
was used instead of the one of the SO).
This commit ensures that invoices created through the wizzard now takes the company
of the SO they are generated from.
Finaly this commit adds a multicompany test in the sale module in order to ensure
that the `sale.advance.payment.inv` wizzard is not impacted by the multicompany.
task-2608812
Closes: #79926
Prior to this commit it was not possible to get a hook from
sale.advance.payment.inv in order to get the created invoices.
The create_invoices def returns either an action or an ir.actions.act_window_close
The introduction of the _create_invoices def will allow to get the created invoices
from the wizzard.
task-2608812
Closes: #79926
Current behavior :
When creating payment from invoice, the payment had the wrong sales team id
Steps to reproduce :
- Create atleast 2 invoices with different sales team and same partner
- Register payments for every invoice
- Go in payments list view
- Filter on partner and group by sales team
- All the payments are grouped in the same sales team
opw-2681041
closesodoo/odoo#82114
X-original-commit: 2f3ebe86b2d520dd9c7570f60056f200bb091aab
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* Move specific actions to their place of use (as they are not expected
to be used anywhere else)
* order actions by use/importance in sale_order_views.xml, and server
actions in a specific "section"
Use the recursive definition of menuitems
Only archive the root menu (to be unarchived in sale_management)
Clean menus specifications, order attributes, ...
Those were not accounted for, leading to fstrings passing through
unflagged.
Also update the SQL checker to be stricter but smarter:
The previous version would "fail open", unknown nodes would be allowed
through hence f-strings not being flagged when they started appearing
in arg0 position, should now fail-closed, anything that's not allowed
is forbidden.
This flags a few more cases, all of which seem acceptable upon review.
However the previous version would also only resolve arg0 (in case it
had a `NAME`, to see if that resolved to an acceptable form of
query-building). The new version performs resolution during
`_check_concatenation` and should thus allow e.g. format strings to be
separate variables (though not e.g. module-level constants, yet
anyway).
In resolution, replace the ad-hoc process by astroid's built-in
`lookup` which seems to provide the same information. Slightly more in
fact, as it yields every assignment in case of e.g. conditionals, but
making use of that would require a lot more changes in the checker so
leaving the behaviour as-is for now.
It's important to *not* use `ilookup` here, because ilookup is not
"iterable" but "inferring", and we don't want values, we want
expression ASTs for analysis.
NOTE: previous improvements as well as fixes to existing code were
only implemented in 14.0, hence this being merged in 14.0 not 13.0
despite 13.0 still being supported.
closesodoo/odoo#81721
X-original-commit: 376ccf0944dae1bc53ae9c5385977c4e6b23e083
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@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>
Since 6f182eeeab UoM should be created through the UoM category tab as the UoM form view is now unusable.
To ensure that this is the case, we remove menu link to the form view and update the other to lead to UoM category instead.
opw-2702953
closesodoo/odoo#81221
X-original-commit: 58a3954d606d48b2a4cf678eb0bf13d6e28b1aef
Signed-off-by: Damhaut Florian (flda) <flda@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>
Steps to follow
- Click on a product from a sale.order.line
- The form is switched to edit mode
-> We can't go to the product page
Cause of the issue
The quick edit feature was introduced in saas-14.4
Solution
- remove the 'no_open' attribute from the product
opw-2688863
closesodoo/odoo#81047
X-original-commit: 57d662c4817b83a8f166d11bf35b4b73206704b0
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Victor Feyens