**Problem:**
When we do a downpayment on an invoice then pay the rest and do a credit note, the credit note does not reverse the cogs

**Steps to reproduce:**
- create a storable product invoiced on ordered quantity
- set the category of the product as avco and "inventory valuation"
of the category as automated
- set an onhand quantity and a positive cost
- create a SO for 1 quantity of this product and confirm
- click on create invoice, select downpayment percentage and 25%
- click on create draft and confirm it
- click on create invoice, select regular, create draft
- confirm and select credit note
- write something in the reason field and click on reserve
- confirm it

**Current behavior:**
if you open the "Journal Items" page of the credit note you'll see that there is no line revresing the cogs (there would be if we didn't do a downpayment but invoiced all at once)

**Expected behavior:**
There should be:
- A line crediting "600000 Expenses" (or the account that was debited for the cogs on the original invoice) with the amount being the cost of your product.
- A line debiting "110300 stock interim (delivered)"(or the account that was credited for the cogs on the original invoice) with the amount being the cost of your product.

**Cause of the issue:**
Since this commit https://github.com/odoo/odoo/pull/163251/commits/d7b0510908d341c205461ca18b1730c93b88e445 (slightly modfified for efficieny reasons by this commit https://github.com/odoo/odoo/commit/4f9c52c03c65a497937053530e8d6c775d305e35), when _stock_account_prepare_anglo_saxon_out_lines_vals is called on the account move (the credit note) it calls _get_anglo_saxon_price_ctx.
https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/stock_account/models/account_move.py#L114 One of the invoice lines of the account move is linked via sale_line_ids attribute to a sale order line that is a downpayment. As a consequence, inside _get_anglo_saxon_price_ctx, move_is_downpayment will be populated with this line. https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_stock/models/account_move.py#L136-L139 Then _stock_account_prepare_anglo_saxon_out_lines_vals calls _stock_account_get_anglo_saxon_price_unit.
https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/stock_account/models/account_move.py#L131

Inside this method, because move_is_downpayment is populated, is_line_reversing will stay false
https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_stock/models/account_move.py#L163-L164

As a consequence,
- qty_to_invoice will become - qty_to_invoice
- account_move will be populated
- therefore posted_cogs will be populated https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_stock/models/account_move.py#L166-L174 So _compute average price will be called with a qty_invoiced of 1 instead of 0 and a qty_to_invoice of -1 instead of 1. So it will return 0 instead of the cost of the product because "missing" will be negative.
https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/stock_account/models/product.py#L915

**fix**
The use case of this commit https://github.com/odoo/odoo/pull/163251/commits/d7b0510908d341c205461ca18b1730c93b88e445 is this one :
- SO for qty of 10 (product invoiced on delivered qty).
- 100% downpayment.
- deliver 6.
- invoice. 
In that case the invoice is actually a credit note but it still has to include the cogs (not reversed), so move_is_downpayment needs to be populated

However in our use case the cogs has to be reversed (so move_is_downpayment has to be None). One difference between those two use case is that in our use case the account move has a reversed_entry_id.

opw-5041783

Forward-Port-Of: odoo/odoo#229774
Forward-Port-Of: odoo/odoo#226809

**Steps to reproduce:**
- create a storable product with fifo category
- update the cost to 200
- click on the on hand smart button and add a quant of 1 quantity
- update the cost to 300
- click on the on hand smart button and update the quantity to 2
- the value should be 500, which makes a 250 value per product
- open Inventory/valuation and search your product
- group by product, select your product and click on "+" icon to open 
the revaluation widget
- add 200 (so +100 per unit)
- go back to the product form

**Current behavior:**
the cost is now at 400

**Expected behavior:**
the cost should be at 350 (250 + 100)
If we change the standard_price we should change it in accordance 
with the valuation

**Cause of the issue:**
In action_validate_revaluation, during the update of the standard_price, 
the current standard_price (set by the user and disconnected from the
valuation) is used in the computation.
https://github.com/odoo/odoo/blob/5118f7cb80744f901d7028dc75c29aba9591b83b/addons/stock_account/wizard/stock_valuation_layer_revaluation.py#L127

opw-5028848

Forward-Port-Of: odoo/odoo#229977
Forward-Port-Of: odoo/odoo#228457

Currently, leads are not automatically assigned via rule-based assignment 
when duplicating an existing lead, even if the duplicated lead matches 
the assignment criteria.

**Pre-requisites:**
1) Set up rule-based lead assignment in the CRM settings. 
2) Configure the sales team's assignment domain:
   `[("user_id", "=", False)]`
3) Configure the sales team members' domain:
   `[("probability", ">=", 10)]`

**Steps to Reproduce:**

1) Create a lead that matches the above assignment rules. 
2) Remove the salesperson (user_id) and sales team from the lead. 
3) Duplicate the lead.
4) Update the probability to a valid value (e.g., ≥ 10). 
5) Manually trigger the `Rule-Based Assignment`.

**Issue:**
The original lead gets assigned, but the duplicated one does not.

**Cause:**
When duplicating, the system sets date_open to the current date by default, 
even if the duplicated and original leads have no assigned users.

https://github.com/odoo/odoo/blob/3e7d85cf25386615dea559d954cebb1424b62f35/addons/crm/models/crm_lead.py#L929-L931

However, `rule-based assignment` only considers leads where `date_open` is False https://github.com/odoo/odoo/blob/3e7d85cf25386615dea559d954cebb1424b62f35/addons/crm/models/crm_team_member.py#L136-L141

**Solution:**
Set `date_open` to False during duplication if the original lead has no `user_id`. 
This ensures the new lead remains eligible for assignment.

opw-5003529

Forward-Port-Of: odoo/odoo#229512
Forward-Port-Of: odoo/odoo#227387

Issue:

In this bug, workorder duration inverse is causing some time_ids to be deleted.

To reproduce:
1- Create a db with mrp installed, and enable work orders in Setting
2- Create a MO, and confrim it
3- Add a new work order to the MO
4- Add two time tracking lines:
   - First one an arbitary duration
   - Second one sub-duration of the first one

5- As you see, duration reflects duration of first line as it is the interval duration
6- Save and close work center form. Then save MO form.
7- Open work orders again: As you see second line is unlinked

Cause:

The reason to this bug, is because in Enterprise, the `_compute_duration` override changes the logic of how duration is computed but the inverse function doesn't reflect the same logic.

To be specific this is the compute function override: https://github.com/odoo/enterprise/blob/3cbe2bbbfd989a3daaa32769a843aeaa09c7ed3e/mrp_workorder/models/mrp_workorder.py#L757-L766

In which duration is calculated using get_duration: https://github.com/odoo/enterprise/blob/3cbe2bbbfd989a3daaa32769a843aeaa09c7ed3e/mrp_workorder/models/mrp_workorder.py#L828-L837

Which doesn't sum the durationw, but calculates the intervals duration counting overlaps only once.

However, there is no override of inverse method in Enterprise, meaning that the logic behind inverse will not match with this logic. In the inverse it is assumed duration is sum of all time_ids intervals:
https://github.com/odoo/odoo/blob/9b286285a6c66bc2d629eacf651c3439cffb55cc/addons/mrp/models/mrp_workorder.py#L355-L400

As a result, if time_ids overlap:
new_order_duration < old_order_duration

As a result some time_ids will be unlinked and some will have duration changed.

Fix:

The issue can be fixed by overriding inverse method `_set_duration`:
```diff
- old_order_duration = sum(order.time_ids.mapped('duration'))
+ old_order_duration = order.get_duration()
```

In order to not repeat unchanged logic in override, the unchanged part is packed into `_sync_duration_changes`.

opw-5082477

**Steps to reproduce:**

1-Install the purchase_stock module.
2-Create a Purchase Order with a new vendor.
3-In the Purchase Order line, add a product without a category. 
4-Confirm the order and validate the generated receipt. 
5-In the vendor form view, click the On-time Rate smart button → no graph is
 visible.

**Issue:**

https://github.com/odoo/odoo/blob/77b3956ed5635d79ae8dc19423140dc6a10098f1/addons/purchase_stock/report/vendor_delay_report.py#L46-L50

```
The On-time Rate graph is not displayed in the Vendor Delay report.
```

**Cause:**

- From version 18.2, `categ_id` was removed as a required field. The report query still uses an inner join on `categ_id`, which  excludes products without a category and prevents data from being generated.

- Commit which make `categ_id` non require  - https://github.com/odoo/odoo/pull/166323/commits/b039caecbeb04057fbccb1cc88d03a4946f88e8e

**Solution:**

- Replace the inner join with a left join so that products without a `categ_id` are also included in the report (with null values when the category is not set).

**opw** - 4991367

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

Forward-Port-Of: odoo/odoo#225557

Currently, leads are not automatically assigned via rule-based assignment 
when duplicating an existing lead, even if the duplicated lead matches 
the assignment criteria.

**Pre-requisites:**
1) Set up rule-based lead assignment in the CRM settings. 
2) Configure the sales team's assignment domain:
   `[("user_id", "=", False)]`
3) Configure the sales team members' domain:
   `[("probability", ">=", 10)]`

**Steps to Reproduce:**

1) Create a lead that matches the above assignment rules. 
2) Remove the salesperson (user_id) and sales team from the lead. 
3) Duplicate the lead.
4) Update the probability to a valid value (e.g., ≥ 10). 
5) Manually trigger the `Rule-Based Assignment`.

**Issue:**
The original lead gets assigned, but the duplicated one does not.

**Cause:**
When duplicating, the system sets date_open to the current date by default, 
even if the duplicated and original leads have no assigned users.

https://github.com/odoo/odoo/blob/3e7d85cf25386615dea559d954cebb1424b62f35/addons/crm/models/crm_lead.py#L929-L931

However, `rule-based assignment` only considers leads where `date_open` is False https://github.com/odoo/odoo/blob/3e7d85cf25386615dea559d954cebb1424b62f35/addons/crm/models/crm_team_member.py#L136-L141

**Solution:**
Set `date_open` to False during duplication if the original lead has no `user_id`. 
This ensures the new lead remains eligible for assignment.

opw-5003529

Forward-Port-Of: odoo/odoo#229512
Forward-Port-Of: odoo/odoo#227387

The system crashes with an error when a user adds a prompt in AI and searches.

**Steps to produce:**
- Install the `Sales and AI` module with demo data.
- Go to sales and click on the AI button on top.
- Add query that used pivot view like `Top 5 sales reps by revenue also make pivot view`.
- Try multiple times (error only comes in terminal).

**Error:**
ValueError: Measure 'price_subtotal:sum' not found in model 'sale.report' for menu ID 331.

**Cause:**
- Here at [1], we split the measure_str and assign the first element to `measure_name`.
- At [2], we try to find a field in the model using this `measure_name`, which fails.
- The issue is that `measure_name` can contain both the `field` and its `aggregation` function (e.g., product_qty:sum), which is not a valid field.

**Solution:**
- In this PR, a new method `validate_measures` has been added to ensure that
  the provided measures are valid and properly defined.

[1]
https://github.com/odoo/enterprise/blob/f838bbd0ce425d24444b510e49752c3da8068712/ai/models/ai_agent.py#L1244-L1245

[2]
https://github.com/odoo/enterprise/blob/f838bbd0ce425d24444b510e49752c3da8068712/ai/models/ai_agent.py#L1264-L1265

**sentry-6917511363,6915439025**

Forward-Port-Of: odoo/enterprise#96247

ISSUE
=====

Introduced in bce7e94650c337a9046958a7689c81db5b2a4c73, We now handle capacity when booking users.
They have each a max capacity of user_capacity for each slot.

However, when it comes to the manual confirmation treshold, we do not account for the total capacity of all users combined, but consider the maximum to be user_capacity!

This can lead to a lot of 'request' meetings as we reach the manual confirmation percentage very quickly.

STEPS TO REPRODUCE
==================

1. Create an appointment type based on users, with 'manage capacities' enabled, 'manual confirmation' enabled and 'when over' 50% total capacity. Set 2 users and 3 'seats max'. This way, the total capacity of your appointment is 2 * 3 = 6 per slot.
2. As a public user, take an appointment for 2 capacity in the front end
3. The meeting will end up as a 'request', even though the capacity booked is 2/6 < 50%, and should be 'booked'

FIX
===

We now multiply the number of users on the appointment type by the user_capacity when computing the total capacity and comparing it to the asked capacity on booking an appointment.

A test is included

Task-4930778

Forward-Port-Of: odoo/enterprise#94446
Forward-Port-Of: odoo/enterprise#89876

**Problem:**
When we do a downpayment on an invoice then pay the rest and do a credit note, the credit note does not reverse the cogs

**Steps to reproduce:**
- create a storable product invoiced on ordered quantity
- set the category of the product as avco and "inventory valuation"
of the category as automated
- set an onhand quantity and a positive cost
- create a SO for 1 quantity of this product and confirm
- click on create invoice, select downpayment percentage and 25%
- click on create draft and confirm it
- click on create invoice, select regular, create draft
- confirm and select credit note
- write something in the reason field and click on reserve
- confirm it

**Current behavior:**
if you open the "Journal Items" page of the credit note you'll see that there is no line revresing the cogs (there would be if we didn't do a downpayment but invoiced all at once)

**Expected behavior:**
There should be:
- A line crediting "600000 Expenses" (or the account that was debited for the cogs on the original invoice) with the amount being the cost of your product.
- A line debiting "110300 stock interim (delivered)"(or the account that was credited for the cogs on the original invoice) with the amount being the cost of your product.

**Cause of the issue:**
Since this commit https://github.com/odoo/odoo/pull/163251/commits/d7b0510908d341c205461ca18b1730c93b88e445 (slightly modfified for efficieny reasons by this commit https://github.com/odoo/odoo/commit/4f9c52c03c65a497937053530e8d6c775d305e35), when _stock_account_prepare_anglo_saxon_out_lines_vals is called on the account move (the credit note) it calls _get_anglo_saxon_price_ctx.
https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/stock_account/models/account_move.py#L114 One of the invoice lines of the account move is linked via sale_line_ids attribute to a sale order line that is a downpayment. As a consequence, inside _get_anglo_saxon_price_ctx, move_is_downpayment will be populated with this line. https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_stock/models/account_move.py#L136-L139 Then _stock_account_prepare_anglo_saxon_out_lines_vals calls _stock_account_get_anglo_saxon_price_unit.
https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/stock_account/models/account_move.py#L131

Inside this method, because move_is_downpayment is populated, is_line_reversing will stay false
https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_stock/models/account_move.py#L163-L164

As a consequence,
- qty_to_invoice will become - qty_to_invoice
- account_move will be populated
- therefore posted_cogs will be populated https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_stock/models/account_move.py#L166-L174 So _compute average price will be called with a qty_invoiced of 1 instead of 0 and a qty_to_invoice of -1 instead of 1. So it will return 0 instead of the cost of the product because "missing" will be negative.
https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/stock_account/models/product.py#L915

**fix**
The use case of this commit https://github.com/odoo/odoo/pull/163251/commits/d7b0510908d341c205461ca18b1730c93b88e445 is this one :
- SO for qty of 10 (product invoiced on delivered qty).
- 100% downpayment.
- deliver 6.
- invoice. 
In that case the invoice is actually a credit note but it still has to include the cogs (not reversed), so move_is_downpayment needs to be populated

However in our use case the cogs has to be reversed (so move_is_downpayment has to be None). One difference between those two use case is that in our use case the account move has a reversed_entry_id.

opw-5041783

Forward-Port-Of: odoo/odoo#229774
Forward-Port-Of: odoo/odoo#226809

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/86fc4428f8 [REL] 19.0.5 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/47bb54fc70 [FIX] chart: zoomable chart should be animated [Task: 5079057](https://www.odoo.com/odoo/2328/tasks/5079057)
https://github.com/odoo/o-spreadsheet/commit/301b2ca0ec [IMP] carousel: allow full screen toggle in carousel [Task: 5078831](https://www.odoo.com/odoo/2328/tasks/5078831)
https://github.com/odoo/o-spreadsheet/commit/975b3487fe [MOV] figures: rename `fullScreenChart` to `fullScreenFigure` [Task: 5078831](https://www.odoo.com/odoo/2328/tasks/5078831)
https://github.com/odoo/o-spreadsheet/commit/0cea053f34 [FIX] format: wrong internal format conversion [Task: 5126306](https://www.odoo.com/odoo/2328/tasks/5126306)
https://github.com/odoo/o-spreadsheet/commit/a2df5684dd [FIX] spreadsheet: prevent sheet name edit from losing focus [Task: 5109129](https://www.odoo.com/odoo/2328/tasks/5109129)
https://github.com/odoo/o-spreadsheet/commit/0c0386b3ec [FIX] Evaluation: remove spread relations [Task: 5105030](https://www.odoo.com/odoo/2328/tasks/5105030)
https://github.com/odoo/o-spreadsheet/commit/297ca4a894 [FIX] headers: can add lots of headers [Task: 5092626](https://www.odoo.com/odoo/2328/tasks/5092626)
https://github.com/odoo/o-spreadsheet/commit/030841ec5e [FIX] composer: show FX icon in inactive mobile composer [Task: 5092659](https://www.odoo.com/odoo/2328/tasks/5092659)
https://github.com/odoo/o-spreadsheet/commit/23f44838cb [FIX] chart: fix button hover background in dashboard menu [Task: 5082189](https://www.odoo.com/odoo/2328/tasks/5082189)
https://github.com/odoo/o-spreadsheet/commit/242c9a7966 [FIX] pivot: add deferred calculated measure [Task: 5096156](https://www.odoo.com/odoo/2328/tasks/5096156)

Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com>
Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

**Steps to reproduce:**
- create a storable product with fifo category
- update the cost to 200
- click on the on hand smart button and add a quant of 1 quantity
- update the cost to 300
- click on the on hand smart button and update the quantity to 2
- the value should be 500, which makes a 250 value per product
- open Inventory/valuation and search your product
- group by product, select your product and click on "+" icon to open 
the revaluation widget
- add 200 (so +100 per unit)
- go back to the product form

**Current behavior:**
the cost is now at 400

**Expected behavior:**
the cost should be at 350 (250 + 100)
If we change the standard_price we should change it in accordance 
with the valuation

**Cause of the issue:**
In action_validate_revaluation, during the update of the standard_price, 
the current standard_price (set by the user and disconnected from the
valuation) is used in the computation.
https://github.com/odoo/odoo/blob/5118f7cb80744f901d7028dc75c29aba9591b83b/addons/stock_account/wizard/stock_valuation_layer_revaluation.py#L127

opw-5028848

Forward-Port-Of: odoo/odoo#229977
Forward-Port-Of: odoo/odoo#228457

**Steps to reproduce:**
- enable "units of measure & packagings" settings
- navigate to "units and packagings" and create a new one called 
"pack of 2"
- set a quantity of 2 and the reference unit as "units"
- create a new storable product
- next to "sale price" change the unit to "pack of 6"
- in the sales tab add "pack of 2" in the packagings
- in the purchase tab add a vendor
- click on the reordering rule smart button and create a new one
- set the min and max to 0 and set the replenishment multiple to 
"pack of 2" (you might have to make this column visible using the filters)
- create and confirm a quotation for 1 pack of 6

**Current behavior:**
a new Purchase Order is created for a quantity of 1.02

**Expected behavior:**
it should be a quantity of 1

**Cause of the issue:**
qty_multiple is rounded (in _compute_quantity) before the computation
of remainder.
https://github.com/odoo/odoo/blob/7a0a246016d50ae80e49f3502a97e82d414ab0b0/addons/stock/models/stock_orderpoint.py#L373-L376
In cases of repeating decimal numbers (like 0.3333333 in our example),
this leads to the remainder not being 0 even though it should be 0.

opw-5040144

Forward-Port-Of: odoo/odoo#230013
Forward-Port-Of: odoo/odoo#228014

While the fix has been already implemented in 19.0 in [1], this commit
forwards-port the test of the original commit, as it differs from the
one included (modified) in [1] and treats the case of managing capacity,
and some other use cases not covered by the test in [1].

A small error is also corrected in a separate commit, as the appointment
used to get the phone question was wrong in a test related to the original
issue.

ORIGINAL ISSUE
==============

Introduced in https://github.com/odoo/enterprise/commit/bce7e94650c337a9046958a7689c81db5b2a4c73,
We now handle capacity when booking users.
They have each a max capacity of user_capacity for each slot.

However, when it comes to the manual confirmation treshold,
we do not account for the total capacity of all users combined,
but consider the maximum to be user_capacity!

This can lead to a lot of 'request' meetings as we reach the
manual confirmation percentage very quickly.

STEPS TO REPRODUCE
==================

1. Create an appointment type based on users, with 'manage capacities'
enabled, 'manual confirmation' enabled and 'when over' 50% total
capacity. Set 2 users and 3 'seats max'. This way, the total capacity
of your appointment is 2 * 3 = 6 per slot.
2. As a public user, take an appointment for 2 capacity in the front
end
3. The meeting will end up as a 'request', even though the capacity
booked is 2/6 < 50%, and should be 'booked'

FIX
===

We now multiply the number of users on the appointment type by the
user_capacity when computing the total capacity and comparing it
to the asked capacity on booking an appointment.

1 : https://github.com/odoo/enterprise/commit/b19e26b0333180ba7a487e14e06385693cf7ab16

Task-4930778

Forward-Port-Of: odoo/enterprise#89876

**Steps to reproduce:**
1. Install `l10n_ke_edi_oscu_pos`.
2. Set company to a Kenya (KE) company.
3. Open POS → Clothes shop → add a product → go to Payment 
→ try to Validate → traceback occurs.

**Issue:**
- A traceback is raised when validating a payment in the POS screen.

`undefined
TypeError: Cannot read properties of undefined (reading 'services')
    at OrderPaymentValidation.beforePostPushOrderResolve`

**Cause:**
-  ` this.env` and `this.orm` is not directly accessible in `OrderPaymentValidation`.

https://github.com/odoo/enterprise/blob/8ca771eb28a1fac13037c0d45e8d716d3dfc6ed2/l10n_ke_edi_oscu_pos/static/src/app/utils/order_payment_validation.js#L7-L24

**Solution:**
- Use `this.pos.env` instead of `this.env`, and `this.pos.data.call` instead of
  `this.orm.call` to correctly access the environment and execute data calls
  during payment validation.

> Reference:

https://github.com/odoo/enterprise/blob/5a794a6e69ba884862b4a3f399143d1392caa6f0/pos_barcodelookup/static/src/overrides/components/product_screen/product_screen.js#L8-L10

[Related Community PR](https://github.com/odoo/odoo/pull/230069)

**opw - 5137557**

**Step to Reproduce**

1- Install point_of_sale and quality_control.
2- Open POS -> Product -> Product
3- Open any product and click the Quality Points smart button → traceback occurs

**Issue** 

`UncaughtPromiseError > OwlError
Uncaught Promise > The following error occurred in onWillStart: ""quality.point"."product_variant_count"
field is undefined."`

**Root Cause**

https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/point_of_sale/views/product_view.xml#L23-L25

- View reference is passed in the context.
- When this context is propagated to `action_see_quality_control_point`,

https://github.com/odoo/enterprise/blob/7b777bffbebfb6503bb348005e9ce076825926e4/quality_control/models/quality.py#L579-L584

https://github.com/odoo/enterprise/blob/2e08282ca275bf1e66c58e28391f11f8bd7884d2/quality_control/views/quality_views.xml#L859-L868

- Than traceback occurs because the action does not pass a `view_id`. 
- When the context contains `list_view_ref`, it attempts to load the product template 
list view with the `quality.point` model. 
- This leads to a traceback since the fields defined in that view do not exist on the `quality.point` model.


**Solution**

- Pass a proper `view_id` from the Python side to ensure the correct view is loaded,
preventing `list_view_ref` from forcing to load an invalid template.

**opw-** **5090505**

Forward-Port-Of: odoo/enterprise#95040

**Steps to reproduce:**

1. Install the POS module.
2. Open POS and add a product.
3. Proceed to the payment page.
4. Make a payment greater than (total cost of order * 1000).
5. Try to validate the payment → traceback occurs.

**Issue:**
- A traceback is raised when validating a payment in the POS screen. 

`undefined
TypeError: Cannot read properties of undefined (reading 'utils')
    at OrderPaymentValidation.isOrderValid `

**Cause:**
-  ` this.env` is not directly accessible in `OrderPaymentValidation`.

> Reference:

https://github.com/odoo/odoo/blob/33c789eeed3b307e40c0f7ab2c6bc07c33867498/addons/pos_online_payment/static/src/app/utils/order_payment_validation.js#L25-L28

**Solution:**.
-  Use `this.pos.env` instead of `this.env` to correctly access the environment
during payment validation,

> NOTE
- After fixing the traceback, the 'Large Payment Amount' confirmation dialog
appears correctly. However, when clicking 'OK', the dialog was not closing
because the callback function `validateOrder` returned `False` even for valid
orders. This caused the dialog to reopen in an infinite loop.

https://github.com/odoo/odoo/blob/d309b52e5b19727b3e91ed91afd44e392a3b851a/addons/web/static/src/core/confirmation_dialog/confirmation_dialog.js#L71-L91

- Add return `True` in `validateOrder`, because even when the order was valid,
it returned `False`, causing the `ConfirmationDialog` to reopen repeatedly
when clicking "OK". Returning `True` ensures the dialog closes properly after
successful validation.

> Reference:
https://github.com/odoo/odoo/blob/4cd1ad3aa46ad4645fc7b5e530b79d53382de6d5/addons/point_of_sale/static/src/app/utils/order_payment_validation.js#L108-L138


[Related Enterprise PR](https://github.com/odoo/enterprise/pull/96284)

opw-5137557

**Steps to reproduce:**
- Install l10n_in and l10n_in_hr_holidays module
- Time off > configuration > Public holidays
- Create a public holiday for Independence Day (15/08/2025)
- Go to Time off > configuration > 'Time off Types',
- Create a Time off type with
   - 'Sandwich leave' ticked and `Take Time Off in` to half a day
- Go to Time off > Management > Time off
- Case 1: Create a paid time off leave for the employee from 13/08 to 17//08/2025 
- Case 2: Create a paid time off with any date and mark it as a half-day

**Observation:**
- Case 1: You will see Duration 3 days with the sandwich leave policy.
- Case 2: Half-day leave shows 1 day instead of 0.5

**Root Cause:**
- Case 1: For the sandwich leave rule, here we checked only one day after and before, leave start and leave end, respectively. It will cause an issue if an employee applies leave that starts or ends with 3 non-working days.
https://github.com/odoo/odoo/blob/5d2f1510c08d5570fc2c6c8de0cb4042bacf12d6/addons/l10n_in_hr_holidays/models/hr_leave.py#L39-L46
- Case 2: We forcefully added a 1-day leave, without checking if the leave is half day or not.
https://github.com/odoo/odoo/blob/5d2f1510c08d5570fc2c6c8de0cb4042bacf12d6/addons/l10n_in_hr_holidays/models/hr_leave.py#L19

**Solution:**
- Case 1: Extend the sandwich leave logic to check every day before and after until a working day is found.
- Case 2: Fixed duration calculation to add 0.5 for half-day leaves.

opw-5025766

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

Forward-Port-Of: odoo/odoo#226883

Currently, leads are not automatically assigned via rule-based assignment 
when duplicating an existing lead, even if the duplicated lead matches 
the assignment criteria.

**Pre-requisites:**
1) Set up rule-based lead assignment in the CRM settings. 
2) Configure the sales team's assignment domain:
   `[("user_id", "=", False)]`
3) Configure the sales team members' domain:
   `[("probability", ">=", 10)]`

**Steps to Reproduce:**

1) Create a lead that matches the above assignment rules. 
2) Remove the salesperson (user_id) and sales team from the lead. 
3) Duplicate the lead.
4) Update the probability to a valid value (e.g., ≥ 10). 
5) Manually trigger the `Rule-Based Assignment`.

**Issue:**
The original lead gets assigned, but the duplicated one does not.

**Cause:**
When duplicating, the system sets date_open to the current date by default, 
even if the duplicated and original leads have no assigned users.

https://github.com/odoo/odoo/blob/3e7d85cf25386615dea559d954cebb1424b62f35/addons/crm/models/crm_lead.py#L929-L931

However, `rule-based assignment` only considers leads where `date_open` is False https://github.com/odoo/odoo/blob/3e7d85cf25386615dea559d954cebb1424b62f35/addons/crm/models/crm_team_member.py#L136-L141

**Solution:**
Set `date_open` to False during duplication if the original lead has no `user_id`. 
This ensures the new lead remains eligible for assignment.

opw-5003529

Forward-Port-Of: odoo/odoo#229512
Forward-Port-Of: odoo/odoo#227387

### Reproduction Steps

1. Install `knowledge`, `spreadsheet`, and `planning` modules
2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user
3. Log in as the portal user and attempt to print/export the article
4. Also attempt to print/export the same article from the public (unauthenticated) view

**Result**:

* As a portal user: a blank page is displayed instead of the article.
* As a public user: a blank page is also displayed instead of the article.

### Root Cause

The blank print issue comes from multiple problems with CSS asset loading in print mode:

1. **Spreadsheet Conflict (Portal View)**
   The spreadsheet module’s print styles were incorrectly included in the `web.assets_backend` bundle, causing conflicts. These styles are already properly loaded through `spreadsheet.assets_print` and shouldn’t be duplicated in the backend.

2. **Missing Print Assets (Portal View)**
   The knowledge portal template was missing the `web.assets_web_print` bundle, which contains the core print styles needed for proper article formatting.

3. **Planning Conflict (Public View)**
   The planning module’s print styles in the `web.assets_frontend` bundle were globally hiding elements, conflicting with the display of knowledge articles.

4. **Missing CSS rules (Public View)**
   The public knowledge templates were also missing specific CSS rules required for proper article rendering in print mode.

### Fix

This PR fixes problems 2, 3 and 4 by:

* Removing the unused/irrelevant planning print styles
* Ensuring `web.assets_web_print` is loaded in portal
* Creating a new print bundle for the frontend view
* Hiding the knowledge header in the public view when printing (to improve layout)


The first issue is tackled in odoo/odoo#223434

opw-4816241

### Reproduction Steps

1. Install `knowledge`, `spreadsheet`, and `planning` modules
2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user
3. Log in as the portal user and attempt to print/export the article
4. Also attempt to print/export the same article from the public (unauthenticated) view

**Result**:

* As a portal user: a blank page is displayed instead of the article.
* As a public user: a blank page is also displayed instead of the article.

### Root Cause

The blank print issue comes from multiple problems with CSS asset loading in print mode:

1. **Spreadsheet Conflict (Portal View)**
   The spreadsheet module’s print styles were incorrectly included in the `web.assets_backend` bundle, causing conflicts. These styles are already properly loaded through `spreadsheet.assets_print` and shouldn’t be duplicated in the backend.

2. **Missing Print Assets (Portal View)**
   The knowledge portal template was missing the `web.assets_web_print` bundle, which contains the core print styles needed for proper article formatting.

3. **Planning Conflict (Public View)**
   The planning module’s print styles in the `web.assets_frontend` bundle were globally hiding elements, conflicting with the display of knowledge articles.

4. **Missing Print Assets (Public View)**
   The knowledge public templates were also missing the `web.assets_web_print` bundle, preventing proper article rendering in print mode.

### Fix

This PR addresses the first issue by removing spreadsheet print assets from the `web.assets_backend` bundle, since they're already available through their dedicated `spreadsheet.assets_print` bundle.

The remaining issues are tackled in odoo/enterprise#92665

opw-4816241

**Problem:**
unbuilding a Manufactring order created through a subcontracting
process gives the wrong account move lines

**Steps to reproduce:**
- create a storable product (the comp) and set a cost
- create a storable product (the final product), set a cost
and set a vendor
- for the final product set the category as avco and automated
- for the final product create a bill of materials subcontracted
 and set the same vendor
- for the components add the comp for a quantity of 1
- create a Purchase order for the final product and the same vendor
and confirm
- validate the receipt
- From the receipt click on the valuation smart button and click on 
the book widget of the line of the final product
- notice how there is 3 journal items line including one 
crediting "stock interim (Received)"
- unarchive the operation type "subcontracting"
- open Manufacturing/Manufacturing Orders, delete the "to do" 
filter and search for a Manufacturing order with your final product
- unbuild it
- Open accounting/journal entries and select the journal entry for 
the unbuild

**Current behavior:**
There is only two account lines. 
There is no line balancing the "Stock Interim" line of the
manufacturing order.

**Cause of the issue:**
The override of _generate_valuation_lines_data in
mrp_subcontracted_account adds the stock interim line on the 
manufacturing order.
However when unbuilding, the qty is negative so we exit the function
https://github.com/odoo/odoo/blob/1358f93a4c73de5a28cda72ec78769625c863efd/addons/mrp_subcontracting_account/models/stock_move.py#L20

**fix**
Because subcontracted Manufacturing orders are not meant 
to be unbuilt, we prevent it

opw-4998137

**Issue:**
Multiple errors occur when processing payroll for "Fully Flexible" employees
and overlapping leave scenarios:

1. ValueError "Expected singleton: hr.work.entry.type(7, 8)" during work entry generation
   when sick leave overlaps with public holiday

**Steps to Reproduce:**
1. Go to the **Employees** app and create a new employee.
   * Set the working hours to **empty (fully flexible)**.
2. Go to **Contracts** and create a new contract.
   * Set the **Work Entry Source** to *Attendance*.
   * Save and make the contract **Running**.
3. Go to **Time Off** → **New**, and create a sick time off for the employee.
   * Example: from **25th to 29th**.
   * Approve the time off.
4. Go to **Configuration** → **Public Holidays**, and create a new public holiday.
   * Example: **27th**, which overlaps with the sick time off.
   * Work Entry Type = **Paid Time Off**.
5. Go to **Payroll** → **Work Entries**.
   * A **traceback** occurs.

**Root Causes:**
- In `_get_interval_leave_work_entry_type()`: Direct access to `interval[2].work_entry_type_id.code` causes singleton violation when overlapping leaves create intervals containing multiple work entry types.

**Fix:**
- Replace direct access to `interval[2].work_entry_type_id.code` with safe recordset slicing `interval[2].work_entry_type_id[:1].code` to prevent singleton violation when interval contains multiple work entry types

This resolves payroll blocking issue for deployments using the
Fully Flexible employee feature, where employees may have
overlapping leave types and no assigned working calendar.

Test : [PR](https://github.com/odoo/enterprise/pull/93902)

opw-4979974

### Steps to reproduce:
	- Install Time off apps
	- Create two consecutive allocations (e.g. one for 2025 and one for 2026)
	- Create a leave that overlap with the two allocation (e.g. from 8th Dec to 3rd Jan)
	- Create a public holiday at the beginning of the second allocation (e.g. on 1st Jan 2026)

### Cause:
When we are checking the leave duration after having a public holiday the  will return the attendance without
the public holidays duration so when subtracting the attendance duration from the leave duration we will have a remaining amout equals to the public holiday duration and it will be considered as excess days.

https://github.com/odoo/odoo/blob/06e47d8601ba56b1650eeaeef71ebd7a4af39b8b/addons/hr_holidays/models/hr_employee_base.py#L228-L230

https://github.com/odoo/odoo/blob/06e47d8601ba56b1650eeaeef71ebd7a4af39b8b/addons/hr_holidays/models/hr_employee_base.py#L246-L254

### Fix:
We check for public holidays in the interval we are fetching its attendance to avoid assuming it is an excess days in the leave

opw-5006119

**Steps to reproduce:**
1. In Settings, enable "Work Orders".
2. Create a product with a BOM that has 2 operations: op1 and op2.
3. Create and confirm an MO for 1 unit.
4. Start op1 and change the Real Duration of op2.
5. Try to save.

**Issue:**
- Traceback : 
`'<' not supported between instances of 'datetime.datetime' and 'bool'`

**Cause of the issue:**
Starting the first operation launches a call of the `button_start` method creating
a `resource.calendar.leaves` to set on the `leave_id` of this first operation:
https://github.com/odoo/odoo/blob/97a70e71c32ea6183f87fd5eb558b32bcbd2d231/addons/mrp/models/mrp_workorder.py#L630-L641

Then, setting the duration of the second operation from the form view of the MO
and saving triggers a call of the write of the MO containing the
`[Command.update(op_2.id, new_duration)]` as vals.This, in turn, calls 
`_plan_workorders`:
https://github.com/odoo/odoo/blob/97a70e71c32ea6183f87fd5eb558b32bcbd2d231/addons/mrp/models/mrp_production.py#L939-L942
while the first operation has a set `leave_id` but the second do not

However, the `min` operator will be applied to both the set and the unset values,
comparing a `boolean` with a `datetime`:
https://github.com/odoo/odoo/blob/97a70e71c32ea6183f87fd5eb558b32bcbd2d231/addons/mrp/models/mrp_production.py#L1581-L1588

**Solution:**
Only workorders with a `leave_id` (i.e., those planned in work-center schedule)
should be considered when computing MO `date_start` and `date_finished`.
Workorders without a `leave_id` are not yet scheduled and therefore should not influence MO start and end dates.

As both `date_start` and `date_finished` of a workorder are related to the `leave_id` record. As per `mrp_workorder._compute_dates`, these dates reflect the work-center scheduling (`leave_id.date_from` and `leave_id.date_to`).
https://github.com/odoo/odoo/blob/6a075fa3c090920499ccbd5fe673819da7e3f95e/addons/mrp/models/mrp_workorder.py#L250-L260
Therefore, when computing MO dates, it logically follows that only workorders with an assigned `leave_id` should be used. This avoids mixing unscheduled operations (`leave_id = False`) with scheduled ones, preventing invalid comparisons and ensuring accurate production timing.


**opw-5068080**

Backport of some changes included here https://github.com/odoo/odoo/commit/2cf73ba8fe50288a0ea9d0ad4b8aeb51bc345740

The goal of this pr is to see for which company belongs each sale/purchase tax in a product when more than one company is selected.

This pr solves odoo task #4829985 and this issue https://github.com/odoo/odoo/issues/147673

Steps to reproduce:

1) Go to runbot odoo enterprise 18 instance and select companies "My Belgian Company" and "My Company (San Francisco)" taking position in "My Belgian Company".

2) Go to "Accounting / Customers / Products" and get into product with name "Bolt" and internal reference "CONS_89957". There is shown two taxes in "Sale Taxes" and "Purchase Taxes" fields but is not possible to distinguish for which company belongs each tax.

Current behavior:
It can not be distinguished whenever for which company belongs each customer tax in a product if more than one company is selected.

Expected behavior:
It can be distinguished whenever for which company belongs each customer tax in a product if more than one company is selected.

Task Adhoc side: 52262

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

The previous fix for `message/rfc822` attachments forced binary encoding (`cte='binary'`) to comply with RFC 2046. However it also introduced a new issue: emails containing `.eml` attachments with non-ASCII characters could not be serialized

### Steps to reproduce

1. Send an email via the chatter with a `.eml` file attached containing non-ASCII characters (e.g., "é") in its body.

The sending of that email will fail with a `UnicodeEncodeError` error

### Cause

Commit 6197233ef1611ddd974cfdb06ae2568e4af369de attempted to fix an issue where `.eml` (`message/rfc822`) attachments were not RFC-compliant. It did this by forcing the `Content-Transfer-Encoding` to `binary` for the raw byte content of the attachment.

While this worked for simple ASCII attachments, it failed for attachments containing non-ASCII characters. When Python's `email` library later tried to serialize the entire message, it treated the attachment's content as an opaque binary blob. It did not understand the character encoding within that blob, leading to a `UnicodeEncodeError` during the final serialization process.

### Fix

Instead of attaching the raw bytes, we now:
* Parse `.eml` contents using `email.parser.BytesParser`, producing a proper `Message` object.
* Attach the parsed message directly, letting the email library handle correct encoding and transfer settings automatically.

opw-4655868

Forward-Port-Of: odoo/odoo#223790

Issue:
Doing down payment up to 100% can create a -0.00 PayableAmount that won't match the QR Code value, as it's set to absolute.

Step to reproduce:
1 Install l10n_sa_edi
2 Navigate to Accounting > Configuration > Taxes.
3 Select the 15% tax and copy it.
4 In the Advanced Configuration tab, select the "Included in Price" option. 5 Navigate to Sales.
6 Select NEW
7 Add ARAMCO (default customer in l10n_sa) as a customer
8 Click into ARAMCO and change contact type to an Individual. 
9 Navigate back to Sale Order.
10 Add the following products:
-  a 	Booking Fees.              1 quantity. Unit price  225.4 	15% tax (price included)
-  b  Burger Menu Combo. 1 quantity. Unit price  180 	15% tax (price included)
-   c  Booking Fees.              1 quantity. Unit price  300 15% tax (price included)
-  d  Burger Menu Combo.   1 quantity. Unit price -101.43 	15% tax (price included)

11 Select Confirm.
12 Select Create Invoice, then Down payment of 100%.
13 Confirm the invoice.
14 Navigate back to Sale order.
15 Select Create Invoice, then Regular Invoice.
16 Confirm the invoice.
17 Select "Process now" in the blue banner.
18 Receive error.

Current behavior:
- Message: "Invoice was rejected by ZATCA"
- ZATCA return an error 400 and states the QR Code is invalid as the BT-115 in the invoice (XML) and QRCode doesn't match

Expected behavior:
- Message: "Invoice Successfully Submitted to ZATCA"

Cause of the issue:
- Some issues with floating point operations create a difference in value between a 100% down payment and the value of the invoice it covers. This results in a -1e-13 `payable_amount` that ends up being a -0.00 PayableAmount after going through `float_rounding`.

Solution:
- By rounding the `payable_amount` as per currency limit, the `payable_amount` fall back to -0.00. Then it goes through `float_rounding` which return 0.00.
opw-5059795

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

Chrome iOS wraps some text nodes (like measures, email...) with a
`<chrome_annotation>` tag, which breaks OWL rendering.

This commit works around it by adding the (undocumented) `<meta
name="chrome" content="nointentdetection">` tag to disable this Chrome
behavior. The tag has to be set before the onDOMContentLoaded event to
be taken into account.

Note: Looks like this behavior was present in Chrome iOS 127 and
disabled afterward (because it already had issues) but it appeared again
in version 140-141.

References:
- https://issues.chromium.org/issues/353650041
- https://issues.chromium.org/issues/388718411
- https://stackoverflow.com/questions/78207646/how-do-i-disable-chrome-annotation-tags
- https://stackoverflow.com/questions/78575970/prevent-auto-detection-of-phone-numbers-in-chrome-mobile
- https://stackoverflow.com/questions/78725191/stop-chrome-ios-auto-detecting-numbers-followed-by-letter-m-as-metre-units-an
- https://github.com/solidjs/solid/issues/2235

opw-4969197

Steps to reproduce:
1. Install Time Off (hr_holidays).
2. Go to Time Off → Configuration → Mandatory Days.
3. Create a mandatory day.
4. Open the user profile (top right corner) and change the language to Hebrew.
5. Open Time Off and view the calendar.

Issue:
The mandatory day marker is displayed on the incorrect date when the interface is in Hebrew.

Cause:
https://github.com/odoo/odoo/blob/ea9cd8357e148654458e3505963ae847d181776e/addons/hr_holidays/static/src/views/hooks.js#L18-L32
This is because the code was using 'info.el.dataset.date' directly which is based on the rendered DOM element and can be influenced by locale formatting, instead of the canonical ISO date, leading to incorrect selectors when trying to add the hr_mandatory_day CSS classes to the date.

solution:
Use the correct date value derived from info.date via Luxon’s toISODate() method Replaced info.el.dataset.date in the DOM selectors with the normalized ISO date to ensure that the correct element is targeted
regardless of the current language or locale.

opw-4979274

This bug is in France localization. In some cases employee schedule seems ignored in timesheet entry
(`account.analytic.line`) creation, and the duration field is created using the company schedule.
The reason is the case which the employee schedule starts before company scheudle or ends after it.

To reproduce the bug:
1- Make a db with fr company (install l10n_fr)
2- Make two working schedule:
- Company schedule with working day on Monday from 8:00-12:00 13:00-17:00
- Employee schedule with working day on Monday from 8:30-12:25 13:30-17:15

3- Assign company schedule to company in `Company Working Hours` in Setting and apply employee schedule to an employee from `Payroll` tab of employee
4- Allocate some time off to the employee and take a time off on Monday
5- Check the work entries for the day you took the day off on timesheet app
6- 7:24 `Worked Hour` is shown instead of 7:40

The bug occurs because in calling `adjust_date_range`, the case which employee's schedule ends after company schedule is not considered.

opw-4868643

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