## How to reproduce: 1- Create Product Category "PC" AVCO|FIFO Automated. 2- Create Storable Product "P" with product category PC and unit cost to 1. 3- Create SO with 10 units of P. 4- Create PO with 10 units of P and unit cost of 2. Delivery of the SO should now have 2 IV layers, with one being "Revaluation of XXX (negative inventory)" Global IV of P should be 0 qty, 0 value. 5- Return the delivery order of SO. 6- Open valuation of the return => The value is 0, should be 20

## How to reproduce:
1- Create Product Category "PC" AVCO|FIFO Automated.
2- Create Storable Product "P" with product category PC and unit cost to 1.
3- Create SO with 10 units of P.
4- Create PO with 10 units of P and unit cost of 2.
    Delivery of the SO should now have 2 IV layers, with one being "Revaluation of XXX (negative inventory)"
    Global IV of P should be 0 qty, 0 value.
5- Return the delivery order of SO.
6- Open valuation of the return

=> The value is 0, should be 20
In `_get_price_unit`, `price_unit` is taken on the last svl of the origin_returned_move_id, in our case it's the revaluation layer.
`_get_price_unit` now take all svls of origin_returned_move_id into account.

---
The logic for using all IV layers to compute the price_unit is as follows:
If you (1) Sold 10 P (uc 1)  , (2) Purchase 10 P (uc 2)  , (3) Return the 10 P from the SO
It should have the same end result as (1) Purchase 10 P (uc 2)  , (2) Sold 10 P  , (3) Return the 10 P from the SO
The end result for the last scenario is 10 qty, 20 value.
The former scenario should also have the 10 qty, 20 value, to do so it need to take into account the revaluation layer.

---
Bug introduced by https://github.com/odoo/odoo/pull/84274
Before the mentioned PR, when the unit_cost of the last valuation layer from the original stock move was 0 (aka: probably always the case when a revaluation layer was created), ` _get_price_unit()` would use the product standard_cost, making the issue mostly invisible.

OPW-2784033

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#88110
Forward-Port-Of: odoo/odoo#85751

Currently, when modifying an invoice line and setting taxes (price included) for 100%, the price_unit field will be displayed as 0. This is incorrect and is being fixed here. opw-2793284 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#87960

Currently, when modifying an invoice line and setting taxes
(price included) for 100%, the price_unit field will
be displayed as 0.

This is incorrect and is being fixed here.

opw-2793284

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#87960

Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#87957

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#87957

- The image transform option uses the `transform` CSS property, which is very poorly supported in email clients. This hides that option so as to avoid bad surprises. - Images with an aspect ratio of 299×524 that aren't linked to anything are treated as downloadable attachments by GMail and get a little "download" icon. This tends to ruin carefully crafted mailing designs so this ensures all images are actually linked to something (at the very least, to `#`) so the icon doesn't appear. task-2

- The image transform option uses the `transform` CSS property, which is very poorly supported in email clients. This hides that option so as to avoid bad surprises.
- Images with an aspect ratio of 299×524 that aren't linked to anything are treated as downloadable attachments by GMail and get a little "download" icon. This tends to ruin carefully crafted mailing designs so this ensures all images are actually linked to something (at the very least, to `#`) so the icon doesn't appear.

task-2802705

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#87981
Forward-Port-Of: odoo/odoo#87253

**Current behavior before PR:** In Discuss topbar, call buttons are added to allow call and video between channel members. Those buttons were also added to live chat channels but any voice call or video call features are not available for visitors. **Desired behavior after PR is merged:** Call buttons will not appear in Discuss top bar for live chat channels. **Task**-2744224 Forward-Port-Of: odoo/odoo#88002 Forward-Port-Of: odoo/odoo#83908

**Current behavior before PR:**

In Discuss topbar, call buttons are added to allow call and video between
channel members. Those buttons were also added to live chat channels but any
voice call or video call features are not available for visitors.

**Desired behavior after PR is merged:**

Call buttons will not appear in Discuss top bar for live chat channels.

**Task**-2744224

Forward-Port-Of: odoo/odoo#88002
Forward-Port-Of: odoo/odoo#83908

Before this commit, when closing a legacy action Dialog an error was raised. Forward-Port-Of: odoo/odoo#88081

Before this commit, when closing a legacy action Dialog an error was raised.

Forward-Port-Of: odoo/odoo#88081

**Current behavior before PR:** When you create a new channel HTML tags are visible in Autocomplete text area for a split second **Desired behavior after PR is merged:** Added prevendDefault for the autocomplete select event to stop it's defaullt behaviour as changing the autocomplete text area's value by the selected item's value Task-2792365 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#88097

**Current behavior before PR:**

When you create a new channel HTML tags are visible in Autocomplete text area
for a split second

**Desired behavior after PR is merged:**

Added prevendDefault for the autocomplete select event to stop it's defaullt
behaviour as changing the autocomplete text area's value by the selected item's
value

Task-2792365


--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#88097

In case of purchase agreement, call for tender still appears everywhere and it's confusing for the user in case of purchase agreement. It would be better to create another action to have a correct pdf name and report name but it will be modify in master and we could keep a minimal diff here. Forward-Port-Of: odoo/odoo#88076

In case of purchase agreement, call for tender still appears everywhere
and it's confusing for the user in case of purchase agreement. It would
be better to create another action to have a correct pdf name and report
name but it will be modify in master and we could keep a minimal diff
here.

Forward-Port-Of: odoo/odoo#88076

The name_search of product_template was very slow one problem was the search for product_variant_ids = False here i changed the expression.py using postgresql "exists" instead of "id in (select ..." as reference here the amount of data - 297487 entries in product_template - 299006 entries in product_product Forward-Port-Of: odoo/odoo#78607

The name_search of product_template was very slow
one problem was the search for product_variant_ids = False
here i changed the expression.py using postgresql "exists" instead of "id in (select ..."

as reference here the amount of data
- 297487 entries in product_template
- 299006 entries in product_product

Forward-Port-Of: odoo/odoo#78607

Since [1] the CSRF token used by the donation snippet's form did end up being cached for new visitors that did not have a session id yet. This made the validation of the token fail when using the form because the token from the very first new visitor on the worker was reused. After this commit pages that contain a Donation snippet are not cached anymore in order to always get a fresh CSRF token - similarly to what is done for the form snippet. When using incognito mode the csrf token

Since [1] the CSRF token used by the donation snippet's form did end up
being cached for new visitors that did not have a session id yet.
This made the validation of the token fail when using the form because
the token from the very first new visitor on the worker was reused.

After this commit pages that contain a Donation snippet are not cached
anymore in order to always get a fresh CSRF token - similarly to what is
done for the form snippet.

When using incognito mode the csrf token is sometimes not recognized
during navigation to the donation payment page.
Simple sequence to reproduce it:
- drop a Donation snippet on the Home page
- use Firefox and do not log in
- in normal browser, select 25 then press Donate Now
- open an incognito browser, select 50 then press Donate Now
=> 400 Bad Request
Alternative (any browser):
- open page with Donation snippet in incognito window
- remove session id from cookies using developer tools
- close window
- reopen page in a new incognito window
- try to donate
=> 400 Bad Request

[1]: https://github.com/odoo/odoo/commit/7fccbac004628093da49016f75370a84bba49465

opw-2774065

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#87045

Steps to reproduce: - Create a new product as a storable - Set quantity to 0 - Create a new internal transfer Issue: - The forecast button is in green which should not be the case Solution: For the internal transfers view, the green forecast button was invisible when "forecast are strictly less than 0". It should be "less than or equal to 0". Inversely, the red forecast button should be invisible only when is "forecast are strictly greater than 0". opw-2806764 Forward-Port-Of: o

Steps to reproduce:
- Create a new product as a storable
- Set quantity to 0
- Create a new internal transfer

Issue:
- The forecast button is in green which should not be the case

Solution:
For the internal transfers view, the green forecast button was invisible when  "forecast are strictly less than 0". It should be "less than or equal to 0".
Inversely, the red forecast button should be invisible only when is "forecast are strictly greater than 0".

opw-2806764

Forward-Port-Of: odoo/odoo#88146
Forward-Port-Of: odoo/odoo#87863

When using a pricelist with a currency different than the one of the product, the prices used in the pricelist (surcharge, min_margin, & max_margin) are using the default currency of the company which is invalid. To reproduce the issue: 1. Enable multiple currency and enable a second one with an exagerated rate for the sake of clarity. 2. Create a formula pricelist with the newly activated currency using either surcharge or the margin. 3. Create a SO with a standard product. By switching

When using a pricelist with a currency different than the one
of the product, the prices used in the pricelist (surcharge, min_margin,
& max_margin) are using the default currency of the company which is invalid.

To reproduce the issue:
1. Enable multiple currency and enable a second one with an exagerated rate for the sake of clarity.
2. Create a formula pricelist with the newly activated currency using either surcharge or the margin.
3. Create a SO with a standard product. By switching between pricelist, you will see an invalid price.
E.G.:
        EUR_rates = 2 compared to USD        PRICELIST = surcharge of 10€ on any product
        PRODUCT_price = 300$      PRODUCT_price_euros = 150€
        CURRENT_SO_price = (300 + 10)/rate_EUR = (300 + 10)/2 = 155€
        EXPECTED_SO_price = (300 + 10*rate_EUR)/rate_EUR = (300 + 10*2)/2 = 160€

Solution: Adapt the computation of a pricelist_item to take into account the currency.
Could not embed everything in the PricelistItem._compute_price method as it would imply
changing its signature (to include the date of the transaction). Consequently,
using a context to pass the adapted prices.

opw-2760720

Forward-Port-Of: odoo/odoo#88143
Forward-Port-Of: odoo/odoo#87018

Because some lines can be sections/notes without a product, and the product presence when needed is already verified by the sql constraints. Fixes the mistake from #81818 specifying the field as required when it shouldn't be. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#88194

Because some lines can be sections/notes without a product, and the product
presence when needed is already verified by the sql constraints.

Fixes the mistake from #81818 specifying the field as required when it shouldn't be.


--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#88194

In the Disallowed Expenses Report, we can have zero total amounts. This fix is avoiding ZeroDivisionError when computing the rate. [opw-2812849](https://www.odoo.com/web#id=2812849&model=project.task) Forward-Port-Of: odoo/enterprise#26014

In the Disallowed Expenses Report, we can have zero total amounts. This
fix is avoiding ZeroDivisionError when computing the rate.

[opw-2812849](https://www.odoo.com/web#id=2812849&model=project.task)

Forward-Port-Of: odoo/enterprise#26014

The options are not exported because of the name change of a function from https://github.com/odoo/enterprise/commit/4641825daa0ed3b8e407fb3817c582cb541e88a4. Changing it indeed provides it to the xml. Forward-Port-Of: odoo/enterprise#25385

The options are not exported because of the name change of a function from https://github.com/odoo/enterprise/commit/4641825daa0ed3b8e407fb3817c582cb541e88a4. 
Changing it indeed provides it to the xml.

Forward-Port-Of: odoo/enterprise#25385

In case of 'sum_if_pos'/'sum_if_neg'/'sum_if_pos_groupby'/'sum_if_neg_groupby', the totals of the financial report line was well computed. However, when unfolding the line, the displayed grouped lines were always computed like a 'sum'. For example, assume a financial report line with 'sum_if_neg_groupby' as formula considering 2 lines: one +2000 on A, one -10000 on B. In this case, the total of the report line is correct (-10000). However, when unfolding the line, we get A: +2000 B: -1000

In case of 'sum_if_pos'/'sum_if_neg'/'sum_if_pos_groupby'/'sum_if_neg_groupby', the totals of the financial report line was well computed.
However, when unfolding the line, the displayed grouped lines were always computed like a 'sum'.

For example, assume a financial report line with 'sum_if_neg_groupby' as formula considering 2 lines: one +2000 on A, one -10000 on B.
In this case, the total of the report line is correct (-10000). However, when unfolding the line, we get
A: +2000
B: -10000
... instead of only B.

task: 2791942

Forward-Port-Of: odoo/enterprise#25935
Forward-Port-Of: odoo/enterprise#25177

Forward-Port-Of: odoo/enterprise#25892

Forward-Port-Of: odoo/enterprise#25892

Before this commit, once the package setting is active, the "Put in Pack" button was shown for any type type of barcode operations, even for inventory adjustments. This button is no longer displayed for inventory adjustments. Forward-Port-Of: odoo/enterprise#25810 Forward-Port-Of: odoo/enterprise#25794

Before this commit, once the package setting is active, the "Put in Pack" button was shown for any type type of barcode operations, even for inventory adjustments.
This button is no longer displayed for inventory adjustments.

Forward-Port-Of: odoo/enterprise#25810
Forward-Port-Of: odoo/enterprise#25794

On the MPS, when updating a schedule impact another schedule not in the list, we add the impacted schedules at the end of the list. (A schedule update can impact the schedule of the bom components of the product) Currently, when multiple warehouses are present in the company, the new schedule is inserted INSIDE the last schedule. With the fix, the new schedule is inserted AFTER the last schedule. --- Example: In local 14, FURN_8900 and FURN_1118 are components of FURN_7800. We creat

On the MPS, when updating a schedule impact another schedule not in the list, we add the impacted schedules at the end of the list. (A schedule update can impact the schedule of the bom components of the product)

Currently, when multiple warehouses are present in the company, the new schedule is inserted INSIDE the last schedule.
With the fix, the new schedule is inserted AFTER the last schedule.

---

Example: 
In local 14, FURN_8900 and FURN_1118 are components of FURN_7800.
We create a new warehouse in the current company, the issue only happen with multiples warehouses in the MPS.
We update the list limit to not show the 2 components in the list.
We update the forecasted demand of FURN_7800 so that the components are added to the list:

- Behavior before fix: https://watch.screencastify.com/v/keCIZ0UOcGyOjxE4kCYh
- Behavior after fix: https://watch.screencastify.com/v/zurLZjWZMHMDNl7ByNae

---

OPW-2786188

---

Forward-Port-Of: odoo/enterprise#25930