**Steps to reproduce:**
* Install the `quality_control` module.
* Create a storable product.
* Configure a Quality Control Point:
  * Set Control per : Quantity.
  * Set Operation Type to Receipts.
  * Set Product to the created product.
* Create a Receipt for the product with a demand of  5 units.
* Confirm the receipt and mark it as To Do.
* Click on the Quality Check button.
* Click on Fail and set the failed quantity to 3.
* Click on Confirm.

**Observed behavior:**
* A new stock move is created for the failed quantity.
* The original move is split incorrectly:
  * First move: 2 `product_uom_qty` and 2 `quantity`.
  * Second move: 2 `product_uom_qty` and 3 `quantity`.
* The failed move has a demand of **2** instead of **3**.

**Cause:**
* Clicking on *Quality Check* triggers `check_quality`, 
which opens the wizard `action_open_quality_check_wizard`: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/stock_picking.py#L79-L82
* Clicking on *Fail* triggers `do_fail`, opening the confirmation wizard: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/wizard/quality_check_wizard.py#L85-L88
* Clicking on *Confirm* triggers `confirm_fail`, which calls `_move_line_to_failure_location`: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/wizard/quality_check_wizard.py#L97
* In `_move_line_to_failure_location`, a new stock move 
is created for the failed quantity: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/quality.py#L480
* The demand quantity is computed using the minimum of the 
failed quantity and the move line quantity.
* This leads to an incorrect demand of *2* instead of *3*.
* However, the move line quantity was already reduced by the failed quantity: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/quality.py#L472

**Fix:**
* Ensure that partial failures properly split stock moves with 
correct `product_uom_qty` and `quantity` values.

---

opw-5492095

Forward-Port-Of: odoo/enterprise#112298
Forward-Port-Of: odoo/enterprise#107493

When a report uses 'previous_return_period' date_scope on one of its expressions, if there's no account.return.type linked to that report, the opening of the report crashes. This is a bit stupid, since a return type without periodicity will anyway fallback to the the company's tax periodicity field. When there's no return type, we should simply fallback in the same way.

To reproduce:
- Make a Belgian company, install the CoA and localization
- Manually uninstall l10n_be_reports
- Try opening the tax report

Another message also checked that we couldn't compute this date_scope in case there was more than one return type linked to the report, arguing they have different periodicities, so we can't infer which one to use. However, it they actually shared the same periodicity, that check failed anyway. We refine it to authorize this case, and only raise if they truly have different periodicities.

opw-6022150

Forward-Port-Of: odoo/enterprise#111872
Forward-Port-Of: odoo/enterprise#111796

Before this commit:
-------------------------
- In the Repair module, when a quality check for a product was marked as failed,
  Even after selecting a failure location, the failure location is not being set
  at the final product move.
- Instead of showing the selected failure location, the system displayed another
  location as the move destination after completing the repair process.

Steps to reproduce:
-------------------------
1. Install the quality_repair module.
2. In Quality, create a Control Point with:
   - Type = Pass-Fail
   - Control Per = Product or Operation
   - Set at least 1 Failure Location
3. Create a Repair Order for any product and start the repair process.
4. Perform a quality check, set it to Fail, and select a failure location.
5. Open the product moves, the destination location does not match the selected
   failure location.

Cause of the issue:
-------------------------
The failure location was not correctly assigned when a quality check failed
during the repair process because _move_to_failure_location determines the
destination location based on a stock picking (for receipts) or a production_id
(for manufacturing). In the Repair module, however, quality checks are linked to
a repair order, so the selected failure location was not set correctly.

After this commit:
-----------------------
- When a quality check fails in a repair order, the product’s destination
  location is correctly set to the failure location selected by the user.
- This ensures that, upon completion of the repair, the product is moved to the
  selected failure location, maintaining accurate inventory tracking and
  management.

Task ID:5254334

Forward-Port-Of: odoo/enterprise#99235

**Steps to reproduce**
1. Have an employee using a flexible schedule
2. Create a slot from e.g. 20PM to 4AM for this employee. Make
sure this is the only slot that week for the employee.
3. Publish the Schedule and send it to the employee. Open the
outgoing mail to access the link to the planning view.

Issue: the slot is not visible in the week view.

**Cause**
https://github.com/odoo/enterprise/blob/04a885dbb6eed96297cb5ce9a155ebf8e169427c/planning/controllers/main.py#L193-L194
The `event_hour_min` and `event_hour_max` returned by `planning_get`
and used to control the min/max hours displayed in the week view,
didn't account for slots over multiple days.
For a slot between 20pm and 4am, the `event_hour_max` should be the
end of the day, and the `event_hour_min` should be the start of the
day.

**Solution**
- we change the `event_hour_min` and `event_hour_max` for multi-day
slots to display the full days in the week view
- the previous point has the drawback of displaying the full days
for non-flexible employees even when not necessary. This is because
`slots_start_datetime` and `slots_end_datetime` contained the
`planning.slot` start and end. Instead, we can look at the actual
slot values displayed (by `_get_slots_vals`). For example, a 5 day
slot for a non-flexible employee may contain actual slot values
corresponding to a typical 8-17 working day.

opw-5245985

Forward-Port-Of: odoo/enterprise#111658
Forward-Port-Of: odoo/enterprise#99784

### Steps to reproduce:
	- Install the l10n_ae_hr_payroll module.
	- Configure at least two employees, who'll use the UAE Monthly pay structure.
	- On at least one of the employees, set the work entry source to attendance.
	- Register a paid leave time off entry, for the employee whose work entry source is set to attendance.
	- Compute a payslip batch using the UAE Monthly pay structure.
	- Go to the payslip of the employee with the work entry source set to attendance and compute the sheet again.
	- The 'Paid Leave' salary rule results, will change given that the computation of the field l10n_ae_hourly_wage is different when the computation is done for batches and individually.

### Cause:
In 'Paid Leave' rule we use l10n_ae_hourly_wage to compute its result and while computing this field we use self.worked_days_line_ids instead of record inside the loop. This leads to an issue when self has more than one payslip it will take into account all the worked days for each payslip for different employees

### Fix:
We use record instead of self to avoid taking other payslips into consideration while computing the hourly wage.

opw-5979631

Forward-Port-Of: odoo/enterprise#112229
Forward-Port-Of: odoo/enterprise#111280

### Steps to reproduce
------------------
- Install `l10n_ae` module.
- Go to *Settings → Countries* and rename the country "United Arab Emirates" (e.g. change it to "UAE").
- Upgrade the `l10n_ae` module.

### Issue
-----
The file `l10n_ae/data/res.bank.csv` references the country using its name ("United Arab Emirates"). During the module upgrade, the CSV import tries to resolve the country relation using the country name. If the country name has been modified by the user (for example to "UAE"), the lookup fails and the module upgrade crashes with:

```python3
No matching record found for name 'United Arab Emirates' in field 'Country'
```

### Root Cause
----------
Using translatable/display names in CSV data is unreliable, as these values can be customized or translated by users.

### Fix
---
Replace the country name reference with the stable XMLID `base.ae` in `res.bank.csv`.

Using XMLIDs ensures consistent resolution regardless of name changes or translations.

opw-6015302
upg-3950261
tbg-2492

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#255993

### Steps to reproduce
------------------
- Install `l10n_pe` or `l10n_ec` module.
- Go to *Settings → Countries* and rename the country (e.g. "Peru" → "PERÚ",
  "Ecuador" → "ECUADOR").
- Upgrade the module.

### Issue
-----
The files `l10n_pe/data/res.bank.csv` and `l10n_ec/data/res.bank.csv`
reference countries using their names (e.g. "Peru", "Ecuador").

During module upgrade, the CSV import resolves many2one relations using
the country name. If the country name has been modified by the user,
the lookup fails and the module upgrade crashes with:


```python3
2026-03-06 23:48:11,112 27 CRITICAL db_3950261 odoo.service.server: Failed to initialize database `db_3950261`.
Traceback (most recent call last):
  File "/home/odoo/src/odoo/19.0/odoo/service/server.py", line 1510, in preload_registries
    registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
  File "/home/odoo/src/odoo/19.0/odoo/tools/func.py", line 88, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/19.0/odoo/orm/registry.py", line 199, in new
    load_modules(
  File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 456, in load_modules
    load_module_graph(
  File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 216, in load_module_graph
    load_data(env, idref, mode, kind='data', package=package)
  File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 59, in load_data
    convert_file(env, package.name, filename, idref, mode, noupdate=kind == 'demo')
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 689, in convert_file
    convert_csv_import(env, module, pathname, fp.read(), idref, mode, noupdate)
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 754, in convert_csv_import
    raise Exception(env._(
Exception: Module loading l10n_pe failed: file l10n_pe/data/res.bank.csv could not be processed:
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'

 select id,name,code from res_country where code='PE'
+-----+----------------------------------------------------------------------+------+
| id  | name                                                                 | code |
|-----+----------------------------------------------------------------------+------|
| 173 | {"de_DE": "Peru", "en_US": "PERÚ", "es_ES": "PERÚ", "es_PE": "Perú"} | PE   |
+-----+----------------------------------------------------------------------+------+
```


### Root Cause
----------
Using translatable/display names in CSV data is not reliable, as these
values can be customized or translated.

### Fix
---
Replace country name references with stable XMLIDs:
- `base.pe` for Peru
- `base.ec` for Ecuador

Using XMLIDs ensures consistent resolution regardless of name changes
or translations.

opw-6015302
upg-3950261
tbg-2492

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#256201
Forward-Port-Of: odoo/odoo#254096

### Steps to Reproduce:

- Create a toggle list and add content.
- Expand the toggle list and insert a code block (e.g.: /code).
- Add multiple lines inside the code block using Enter.
- Refresh the page with the toggle open, content is preserved.
- Close the toggle and refresh then content collapses into one line.

### Description of the issue/feature this PR addresses:

- When the toggle list is closed, the code block is inside `display: none` container. In this state, `innerText` depends on rendered layout and does not preserve newline characters `\n`. As a result, multiline code content is extracted as single line.

### Desired behavior after PR is merged:

- Read html and normalize it into plain text by:
  - Converting `<br>` tags into newline characters.
  - Stripping remaining HTML tags.
  - Decoding HTML entities back to their literal characters.
  - Removing the extra newline introduced by a trailing `<br>`
  - Cleaning up invisible zero-width characters.

task-5909034

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

Forward-Port-Of: odoo/odoo#248391

Steps to reproduce:
-----------------------------------------
1. Install `sale_purchase_project` and Accounting modules
2. From settings, enable Budget Management
3. Create a new product with type Service and enable Create a project on order.
4. Create and confirm the sale order with that product (note the name of created project)
5. Create and confirm purchase order as follows:
> In other information page, select the created project in the Project field
> Add the same product in POL, Set price unit price to 100 and remove any tax
6. Create and post a Vendor Bill for the same vendor as the PO as follows:
> Add Bill line with label downpayment
> Set the Analytic Distribution to the created project
> Set amount to 30
7. Go to the created purchase order > Click on bill matching
8. Select the downpayment bill > Add to PO > Select created PO > Add Down Payment
9. Go to the created project and open dashboard

Observation:
-----------------------------------------
In the Costs section:
Expected Cost: 130
To Bill: 100
Billed: 30

Expected values:
-----------------------------------------
Expected Cost: 100
To Bill: 70
Billed: 30

Issue:
----------------------------------------
In the following code:
https://github.com/odoo/odoo/blob/7e81c528ae350aab4432207f5655dcfadf6ec627/addons/project_purchase/models/project_project.py#L186-L190

When an invoice line was posted (billed), the code correctly subtracted the cost from `amount_invoiced` (making it negative, representing actual cost). But the billed amount was NOT removed from `amount_to_invoice`. This caused double counting the same cost appeared in both 'To Bill' and 'Billed'

Solution:
-----------------------------------------
Replaced the quantity-based calculation with a proper amount-based approach:
- Introduced `total_invoiced_amount` to track the sum of all non-refund invoice line amounts (both posted and draft).
- Modified the unbilled calculation to: `PO_amount - total_invoiced_amount`, ensuring that the unbilled portion accurately reflects what remains to be invoiced from the purchase order.
- Excluded refunds from `total_invoiced_amount` calculation because credit notes represent reversals of previous invoices, not consumption of the purchase order.  Refunds still correctly affect the "billed" and "to_bill" buckets through the normal invoice line processing.

This ensures the accounting principle is maintained: Total Expected Cost = Billed + To Bill = Purchase Order Amount

opw-5167734

Forward-Port-Of: odoo/odoo#245649

Currently, an error occurs when a user creates an alias ID.

**Steps to Reproduce:**
 - Install the `hr_recruitment` module.
 - Go to `your current company` and set the `Email Domain` value.
 - Go to `Recruitment` > `Applications` > `By Job Positions`.
 - In `list view`, create or open an existing `Job Position`.
 - In the `Trackers` tab, create a record through “Add a line”.
 - Click the `copy clipboard` button next to the `email` field.

**Error:**
`AttributeError: 'hr.recruitment.source' object has no attribute 'name'`

After [this commit], the dependency of utm.source.mixin was removed, along with the 
source_id field referencing a source. The name field was provided by utm.source.mixin, 
and it is now being accessed in recruitment source, which raises the error [1].

This commit ensures that the system uses the name of source_id, as it has been 
replaced by _rec_name to "source_id".

[this commit]: https://github.com/odoo/odoo/commit/927682ce8f5e6faea0da7216ac1163411f5e83bd

[1]- https://github.com/odoo/odoo/blob/949d368eda3d6f2c9b5fb04ec3a41fa1b2cc90d4/addons/hr_recruitment/models/hr_recruitment_source.py#L42

sentry-7353030705

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

Steps to reproduce:
--------------------------------------
1. Install Time off module
2. Navigate to Time off > Management > Allocations
3. Click on the 'New Group Allocation' button
4. Click on the Time Off Type field to open the selection dropdown.

Observation:
--------------------------------------
Traceback occurs:
```
  File '/home/odoo/odoo/community/odoo/orm/domains.py', line 920, in _raise
    raise error(message % (*args, self.field_expr, self.operator, self.value))
ValueError: Invalid field hr.work.entry.type.company_id in condition ('company_id', 'in', [1, False])
```

Issue:
--------------------------------------
In the commit https://github.com/odoo/odoo/pull/244436/changes/5b9570e4bd4cc0ae7d9a81e33f49dc538ae5acd3 model name changed from `hr.leave.type` to
`hr.work.entry.type`. With this change `company_id` field is removed too. However, the domain on the field still referenced `company_id`, leading to an invalid domain and traceback.

Solution:
--------------------------------------
Remove the company_id condition from the domain since the field no longer exists on `hr.work.entry.type`.

opw-6037286

**Steps to reproduce:**
* Install *purchase_stock* and *sale_management* module.
* Go to *Inventory > Configuration > Settings*. Enable *Multi-Step Routes*.
* Go to *Inventory > Configuration > Warehouses*.
* Set the warehouse delivery flow to *Pick + Pack + Ship (3 steps)*.
* Create a new product. Under the *Purchase* tab, add a vendor.
* Create a sales order for this product with some quantity.
* Confirm the sales order. Validate all three generated transfers (*Pick*, *Pack*, *Ship*).
* Create a purchase order for the same vendor.
* In the purchase order line, click *Catalog* and search for the product.

**Observed behavior:**
* In the catalog view, the *Monthly Demand* is shown as *3x* 
the original sales order quantity instead of the actual demand.

**Cause:**
* *Monthly Demand* is a computed field using `_compute_monthly_demand`, 
which relies on `_get_monthly_demand_moves_location_domain()`.
* In a 3-step delivery flow, all related moves have a final location with usage set to *customer*.
* The domain condition: `('location_final_id.usage', 'in', ['customer', 'production'])`
counts all intermediate pickings.
* Additionally, the fallback condition: `[('location_final_id.warehouse_id', '!=', warehouse_id)]`
is always true because *customer* locations are not linked to a warehouse.
* As a result, all three pickings are counted, inflating the demand. See: https://github.com/odoo/odoo/blob/6bbaea728dbcba49776e813c70dff649d041bdc9/addons/purchase_stock/models/product.py#L144-L157

**Fix:**
* Prevent counting intermediate pickings in 3-step delivery by 
restricting the domain to moves with `move_dest_ids = False`,
ensuring only the final move is considered for monthly demand computation.

---

opw-5453991

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

Forward-Port-Of: odoo/odoo#256228
Forward-Port-Of: odoo/odoo#244180

Steps to reproduce:
--------------------------
1. Install sale_timesheet
2. Create a quotation with a timesheet-based product
   - Set quantity = 3
   - Set UoM to Days (timesheet UoM is Hours)
3. Confirm the quotation and click on the smart button Recorded.
4. Record 16 hours of timesheets.
5. Create an invoice using a timesheet period (starting from SO date)
6. Check the invoice quantity

Issue:
-----------
The invoice quantity is incorrect. It assigns the hour value (e.g., 16) to the invoice line even though the SOL is configured in "Days" (expected 2 days for 16 hours).

Cause:
-----------
After this commit c3b6053, The `_recompute_qty_to_invoice` method sums timesheet `unit_amount` (in hours) and assigns it directly to `qty_to_invoice` without converting it to the sale order line UoM when a timesheet period is applied.

Solution:
---------------
Convert the aggregated timesheet hours into the SOL UoM before assigning it to qty_to_invoice.

opw-6024804





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

Forward-Port-Of: odoo/odoo#255790
Forward-Port-Of: odoo/odoo#254273

Before this commit, closing an AI chat window could lead to the following crash:

```js
TypeError: Cannot read properties of undefined (reading '_raw')
```

Steps to reproduce:
- have no chat windows open, cache cleared.
- open DM with demo in chat window from messaging menu, in home menu.
- open AI chat, from systray.
- close the AI chat window. => crash

This happens because when closing the AI chat window, it deletes the AI conversation. By deleting the AI conversation, it removes the conversation from `store.menuThreads`, which is the list of conversations to display in messaging menu. Removal of this conversation in `menuThreads` is done internally through

```js
const index = recordList.indexOf(record);
recordList.splice(index, 1);
```

This is done that way as to reuse custom methods of `RecordList`, especially the `splice()` that is used by many methods that mutate the record list. Internal code of the custom `splice` method does `slice()`, which is used to retrieve some records without mutating the record list.

In practice, these `.slice()` were accidentally mutating the list, because they invoke the `Proxy.getter` of the `RecordList`, and when the list is flagged for `computeOnNeed` / `sortOnNeed`, invoking this `Proxy.getter` would mistakenly enable the `computeInNeed` / `sortInNeed` flags and thus mutate the list, e.g. with a sort, which may change the order of items and mess up the `index` computed in `indexOf()` step.

This is what happens with the chat window. The `menuThreads` looked something like this:

```js
menuThread = ["thread_1", "thread_2", "thread_3"];
```

With the removal of `thread_2`, the `.indexOf()` is `1`, but due to `.slice()` triggering the sort, the list was changed to:

```js
menuThread = ["thread_2", "thread_1", "thread_3"];
```

... And it instead removed `thread_1` but kept `thread_2` in list. This introduce 2 problems:
- `thread_1` is mistakenly removed from relation when it shouldn't
- `thread_2` is kept, but since this is a local id with no actual record in store, `recordList[index]` would return `undefined` as there's no existing record matching this local id.

This commit fixes the issue by improving internal code of record list
methods to avoid accidental triggering of lazy re-compute and
re-sort. The accidental re-compute and re-sort come from invoking
non-implemented array methods on the proxy of record, such as:

- `recordProxy.at()`
- `recordProxy.slice()`

These methods were just used meant to retrieve records from the record list, and they did so by using accessing through `recordProxy`. This approach has the benefit to look good as this is exactly the same as the external API, but it has the unintended side-effect of the re-compute / re-sort of lazy fields. Instead of using these methods, records are retrieved with:

- raw access to get local ids in relation
- convert local ids to raw records through raw access in `store.recordByLocalId`

This approach, while uglier, has the benefit to not accidentally trigger the re-compute / re-sort.

opw-5761279

Forward-Port-Of: odoo/odoo#251769

# Description of the issue/feature this PR addresses:

From saas-18.3 onward, the pos_settle_due module introduced a new method to identify settlement lines. 
While the old method **isSettleDueLine()** is still there, 
the new **isAnySettleLine()** covers both order settlement and invoice settlement. 

This change was not reflected in the Saudi POS EDI integration during forward-porting,
which caused incorrect validation when processing POS orders containing both
regular sale lines and settlement lines.

# Current behavior before PR:

- Orders containing a mix of new sale lines and settlement lines could bypass
the intended validation.

- The validation logic relied on the old isSettleDueLine() method

# Desired behavior after PR is merged:

- Update the validation flow to use isAnySettleLine() (when available) to
correctly detect settlement lines.

- Prevent validation of POS orders that contain both settlement lines and new
sale lines.

- Ensure compatibility with newer versions of the pos_settle_due module and
restore the intended settlement validation behavior.

- Test case to ensure no regression on this feature

I confirm I have signed the CLA and read the PR guidelines at
[www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Forward-Port-Of: odoo/odoo#256177
Forward-Port-Of: odoo/odoo#254275