**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

This pull request introduces an automated process to periodically update the DGI (Dirección General Impositiva) state for Uruguayan electronic stock pickings, along with improvements to error handling and logging when a picking is rejected. The main changes are the addition of a scheduled cron job, enhanced logging, and user notifications for rejected pickings.

**Automated DGI State Updates:**

* Added a new scheduled cron job (`ir_cron_update_dgi_state_pickings`) that runs every 10 minutes to update the DGI state of stock pickings with electronic documents in the "received" state. (`l10n_uy_edi_stock/data/ir_cron.xml`, `l10n_uy_edi_stock/__manifest__.py`) [[1]](diffhunk://#diff-36f19bab7c2edeb0f43a1db1639b72e8508deed19652e0b1142ebfce688b9d3eR1-R11) [[2]](diffhunk://#diff-370a6cfd5890d6504958deb4a225d69ec84e84fa59deeeb52c96a849f3fdfc22R14)
* Implemented the `_l10n_uy_edi_stock_cron_update_dgi_state` method in `stock_picking.py` to process batches of pickings and trigger itself again if more records remain. (`l10n_uy_edi_stock/models/stock_picking.py`)

**Error Handling and Notifications:**

* Enhanced the `l10n_uy_edi_action_update_dgi_state` method to log rejected pickings and post a message in the chatter to notify users when a picking has been rejected by DGI, prompting manual review and correction. (`l10n_uy_edi_stock/models/stock_picking.py`)
* Introduced logging setup for the module to support the new logging functionality. (`l10n_uy_edi_stock/models/stock_picking.py`) [[1]](diffhunk://#diff-108d31170c95f307accd45410f9a98bd16ce0413932fab4732eb764d75d3e260R2) [[2]](diffhunk://#diff-108d31170c95f307accd45410f9a98bd16ce0413932fab4732eb764d75d3e260R14)

Forward-Port-Of: odoo/enterprise#109518

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. 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

### 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:
---
- Install `Sales` module.
- Create a Sale Order.
- Add a section with products.
- Add a subsection under it with products.
- Enable `Hide Prices` on the section.
- Enable `Hide Composition` on the subsection.
- Preview the Sale Order.

Issue:
---
- Prices are still visible in the subsection (grouped view) even though `Hide Prices` is enabled on the parent section.

Root cause:
---
- The variable `show_section_total` was defined only within the main rendering block and not reused in the grouped (`t-else`) block.
- The grouped section summary (used when `collapse_composition=True`) did not respect the parent section's `collapse_prices` setting, causing prices to be displayed.

Solution:
---
- Moved `show_section_total` definition outside the main conditional block so it can be reused in both rendering paths.
- Applied `t-if="show_section_total"` to price fields in the grouped section summary to ensure consistency with the parent section's price visibility.

Before:
---
<img width="1030" height="232" alt="image" src="https://github.com/user-attachments/assets/1ac05e5e-6841-420f-909f-994690656cc0" />

After:
---
<img width="1023" height="232" alt="image" src="https://github.com/user-attachments/assets/921ae337-4d53-433a-a42b-bdc437181889" />



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

Forward-Port-Of: odoo/odoo#255464

Currently an error is generated when the user tries to save a report with an empty XML format.

Steps to reproduce:
- Install web_studio and sale_management
- Sales > Studio > Reports > New > External > Type Text in report
- Save > Edit Sources > Remove full XML > Save

Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)`

This error occurs because line [1] in `web_editor` attempts to access nodes by using `etree.fromstring()` with an empty `view.arch`, which is empty, resulting in an error.

In earlier versions, this error was already handled by the `_check_xml` constraint, which raised a validation error when an `etree.ParseError` occurred while parsing `etree.fromstring(view.arch)` with an empty `view.arch` (see code reference [2]). However, recent changes introduced in commit [3] allow  `view.arch` to be empty. As a result, this error is no longer handled by the constraint.

This commit fixes the issue by adding a condition to prevent calling `etree.fromstring()` when `view.arch` is empty, avoiding attempts to access nodes from invalid data. It also updates the logic in the `web_studio` module's `get_xml_editor_resources` method to ensure resources are processed only when a valid view architecture is available.

[1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367
[2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377
[3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f

sentry-6288795955

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#256009
Forward-Port-Of: odoo/odoo#255316

The AVCO audit report currently recalculates the AVCO value on outgoing moves. Based on the logic in `run_average_batch()`, it should instead use the AVCO value computed on the last ingoing move to recalculate the
`added_value`.                                                         

On the other hand, the `added_value` should not be recomputed from the AVCO value on ingoing moves.

Source of those changes: [245141](https://github.com/odoo/odoo/pull/245141)

Steps to reproduce the issue:
1. Create a new product. Do not assign it to a category yet.
2. Set the cost (standard_price) to 10$ on the product form.
3. Add 10 units to inventory.
4. Sell and deliver 5 units to a customer.
5. Purchase 10 units at 25$/ea and validate the receipt.
6. Sell and deliver 5 units to a customer.
7. Assign the product to category with AVCO cost method.
8. Go to the AVCO justification report:
    - The added value on the purchase is incorrect: 200$ instead of 250$.
    - On the last delivery: the added value is -125$ and the AVCO increases from 20$ to 25$.

Ticket: opw-5921104

Forward-Port-Of: odoo/odoo#252239

**Description of the issue this PR addresses:**
Ensure the `Looking for Help` timer is shown even when the current 
user is already a member of the livechat channel.

**Steps to Reproduce:**
1. Log in as a visitor and as Mitchell Admin (Live Chat operator).
2. From the visitor side, select I have a pricing question.
3. From the admin side, mark the conversation as Looking for Help.
4. The channel appears in the Looking for Help category.
5. Observe that the timer should be visible there (e.g., 1m).

**Current behavior before PR:**
- The timer was hidden when an agent was already a member of the 
conversation, assuming that once an agent joined, the `waiting for help` 
phase was over.

- However, in escalation workflows an analyst may escalate a chat and 
remain a member while the channel returns to the `Looking for Help` 
state for another expert. In this case, the escalating analyst could not 
see the timer needed to track SLA requirements (e.g., creating a 
ticket after 10 minutes).

- Also, the mock server did not recompute
`livechat_looking_for_help_since_dt` when `livechat_status`
changes, leading to incorrect timer values (e.g., showing 2d
instead of < 1m after switching back to Looking for Help).

**Desired behavior after PR is merged:**

- The timer is displayed whenever the channel is in `need_help` 
and `livechat_looking_for_help_since_dt` is set, regardless of 
whether the current user is a member of the channel.
- The mock server now mirrors server-side behavior by updating
`livechat_looking_for_help_since_dt` when livechat_status changes,
prevents missing recomputations and ensuring consistent test
behavior.

task-[6009851](https://www.odoo.com/odoo/project/1519/tasks/6009851)


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

With l10n_be company:
- Create at least two invoices for two different customers (companies) for whom you will add a fake VAT number. Make sure the total on both your invoices is more than 250€ and set their Accounting date to last year.
- Go check the VAT partner Listing report (Accounting > Reporting); make sure you see both partners in the listing.
- Click on returns > Check that report return then Submit and download the XML file: both partners & amounts will appear.
- Now with dev mode, go to Accounting reports, open the Partner VAT listing form > Options > set the "load more limit" to 1.

Download the XML again: only the first partner appears (the only that was loaded with the load more limit.

This commit is a backport of bugfix: PR odoo/enterprise#106134 commit e532750fe3dc1f2d10d995d01446b04a3a227a72
Original problem introduced in `saas-18.3`: PR odoo/enterprise#111783 commit 4c927b389252b595bcbb44d020899ae5abf0aa89

Ticket [link](https://www.odoo.com/odoo/project.task/6051120)
opw-6051120

Forward-Port-Of: odoo/enterprise#111783

```js
---------- FAILED: [7/19] Tour test_quality_check_packages_lots_tour →
Step .o_barcode_line_summary ----------
{
  'trigger': '.o_barcode_line_summary',
  'run': 'click'
},
------------------------------------------------------------------------
```

The tour `test_quality_check_packages_lots_tour` was failing at the step
waiting for `.o_barcode_line_summary` after calling `o_put_in_pack`.

**Root cause:**
the JS barcode model sets `groupingLinesEnabled` directly from
the `group_production_lot` security group flag returned by the backend:

https://github.com/odoo/enterprise/blob/bd35e9c16a6c0fd743c934024db2821b8ae21fdc/stock_barcode/static/src/models/barcode_model.js#L53

When `groupingLinesEnabled` is false, `groupLines()` skips the grouping
logic entirely and individual move lines are rendered as flat
`LineComponent` instances. The `.o_barcode_line_summary` element only
exists inside `GroupedLineComponent`, which is only rendered when lines
are actually grouped (i.e. a parent line has `line.lines` sublines).

The test setup already granted `group_tracking_lot` (required to show the
`o_put_in_pack` button) but was missing `group_production_lot`. Without
it, after scanning `lot-01` twice and packing, the two lot sub-lines were
never merged into a `GroupedLineComponent`, so `.o_barcode_line_summary`
never appeared in the DOM and the tour timed out.

Fix: add `group_production_lot` alongside `group_tracking_lot` in the
test user's groups so that line grouping is enabled in the JS model,
allowing `GroupedLineComponent` to render `.o_barcode_line_summary` as
expected by the tour.

similar fix - https://github.com/odoo/enterprise/pull/82677/changes/05883b2c9cadb1187df404a4bef638f933922755

---

runbot error:241926

Fixes Task 5213234

Issue:
In AccountMove method _find_matching_po_and_inv_lines (called when looking for
a subset match of EDI invoice lines with PO lines), the price_unit of a
purchase.order.line is compared to the price_unit of an invoice line.
However, currently the comparisons do not take into account the precision to be
applied to product prices.
In some cases, the invoice line price_unit differs from the price_unit in a PO
line, but by less than the "Product Price" precision. With the current
comparisons this leads to not matching the lines.
This has prevented matching some invoices received via Peppol for at least one
big customer (see Task-5213234)

Steps to reproduce:
- Create an XML document for an EDI UBL invoice with 2 lines; the first line
  has a price_unit 113.57 euros (for example) 
- Create a PO with a reference matching the invoice, and one PO line with a
  price_unit matching the price_unit of the first invoice line (113.57 euros)
- Upload the XML invoice and create a bill from it; during the creation of the
  account.move.line, the price_unit gets a value which is slightly different
  from 113.57 (113.57000000000001) (due to python rounding ?)
- Result: no link is established between the PO and the invoice.

This fix makes sure that the "Product Price" precision is used when comparing
the invoice line price_unit with a PO line price_unit.

opw-5213234

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

Forward-Port-Of: odoo/odoo#235477
Forward-Port-Of: odoo/odoo#232527

Current behavior:
When trying to validate a picture instruction in shopfloor, Odoo legitimately raises a UserError if the picture is missing. However, even after adding a picture afterward, the Validate button remains unclickable, forcing the user to close the wizard and start again.

Expected behavior:
Even if an error occurs during validation, the Validate button should remain clickable (especially once the cause is addressed).

Steps to reproduce:
- Create a BoM with one operation - Save.
- Add a "take a picture" instruction on this operation.
- Create a MO with this BoM, confirm it.
- Go to the shopfloor, find the WO of the created MO. Open "instructions".
- Click on the small camera to open the check wizard.
- Confirm without taking a picture or uploading an image.
- Error pops up ("Please upload a picture"), close the popup.
- Then add a picture. => The Validate button remains unclickable. We need to close and re-open the wizard to continue, which can be frustrating and time-consuming for manufacturing users, especially with many instructions.

Issue Explanation:
In MrpQualityCheckConfirmationDialog/doActionAndClose, this.props.record.model.orm.call can legitimately raise a UserError, but the button is disabled at the beginning of the method and remains in this state regardless of what happens afterward.

Fix:
Add a try-catch clause to re-enable the button if an error occurs.

Alternative fix:
The button should remain disabled until a picture is taken, but that sounds like a more disruptive change that might impact other flows.

### Open questions

Do we need to add a test for it? Only a JS tour is suitable which it seems a bit much for this kind of bug. What do you think?

https://github.com/odoo/odoo/pull/246481

Forward-Port-Of: odoo/enterprise#105990

Steps to Reproduce:
1. Create an event with a limited number of tickets (e.g., Max Capacity = 1).
2. Try to buy the last tickets at the same time from the POS and the Website.
3. Observe that both transactions succeed, resulting in overbooking.

Problem:
When multiple transactions attempt to purchase the last available ticket for an event simultaneously—whether through the Point of Sale, the website, or the backend—the system can conflict. In the Website vs. Website scenario, this conflict often manifests as an InFailedSqlTransaction. This occurs because both transactions attempt to update the same row in the "event_mail" table (the mail_count_done counter) to schedule confirmation emails. Under PostgreSQL's REPEATABLE READ isolation, this concurrent update triggers a "could not serialize access" error, aborting the transaction and causing subsequent database commands to be ignored.

While this "accidental" lock prevents overbooking on the website by crashing the loser of the race, it does not provide a robust solution and is entirely bypassed by the POS. The root cause lies in how PostgreSQL handles REPEATABLE READ isolation. In Odoo, when a transaction starts, it works from a snapshot of the database. If transactions run concurrently:
* Both read the registration count from their own isolated snapshot (which shows seats are still available).
* Both pass the validation check because they cannot see the other's uncommitted rows.
* Once both commit, the event ends up over-booked.

Previously, there was no locking mechanism to serialize these checks or force a fresh read of the data.

Fix:
A new method _lock_and_check_availability is added to event.event.ticket to ensure registrations are handled one at a time.

1. Row-Level Locking: The method issues a SELECT ... FOR UPDATE on the event_event and event_event_ticket rows. This prevents other transactions from modifying these records until the current one commits.
2. Fresh Data Read: After securing the lock, the method opens a new database cursor via self.pool.cursor(). Because this is a separate cursor, it ignores the stale snapshot of the original transaction and reads the true, committed state of the seats.

Implementation Details:
* Triggers: This check is called during payment post-processing (payment.transaction) and Point of Sale order finalization (pos.order).
* Error Handling:
    * Retries: The payment controller now catches InFailedSqlTransaction. If a transaction loses the race for a lock and the cursor fails, Odoo will automatically schedule a retry.
    * Blocking: If the fresh check determines no seats remain, it raises a ValidationError, rolls back the transaction, and informs the customer.
* User Feedback: A processing_msg field is added to payment.provider to update the portal UI. This ensures customers see a 'Processing' status while the availability check is running.

opw-5932567

### Issue before this commit:
When creating a credit note using “Reverse and create invoice”, the generated invoice loses the Source field. While the original invoice correctly displays the source, the new invoice created after reversal does not, leading to missing information in the report.

### Steps to reproduce the issue:
1. Create a sales order for product A
2. Deliver product A
3. Create invoice
4. Create credit note by clicking on "Reverse and create invoice"
5. The new invoice correctly remains linked to the Sales order
6. However, the source document disapear on the PDF

### Cause of the issue:
In the reversal flow, the new invoice is created using copy_data() without explicitly preserving the invoice_origin field. As a result, the newly created invoice does not inherit the source information from the original invoice, even though it is still logically linked.

### Reason to introduce the fix:
To ensure consistency between invoices and preserve important traceability information, the invoice_origin field must be propagated to the new invoice created during the reversal process. This guarantees that the Source is correctly displayed in the PDF.

opw-6034574

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

Forward-Port-Of: odoo/odoo#254290

# How to reproduce
- Create a time off request for a single employee
- Refuse it
- Duplicate it
- Refuse the duplicate
- Try to go back to draft

# The problem
The user is deadlocked and cannot go back to draft because of a client validation on the field employee_ids. The user cannot change that field because it is readonly, so he is stuck.

# Why
When duplicating a hr.leave, employee_id is copied but not employee_ids. Going back to the issue steps, if you look at the Employees field of the duplicate, it is empty. This later cause the issue with the client side validation.

Copying employee_ids when there are multiple employees did not seem like the best idea because a lot of flows relies on employee_id. employee_id is computed as follows :
```py
    def _compute_from_employee_ids(self):
        for holiday in self:
            if len(holiday.employee_ids) == 1:
                holiday.employee_id = holiday.employee_ids[0]._origin
            else:
                holiday.employee_id = False
```
So if we copy multiple employees in employee_ids, employee_id will be null, which might break these flows.

opw-5995398

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

Forward-Port-Of: odoo/odoo#253075

# How to reproduce
- Create a time off request for a single employee
- Refuse it
- Duplicate it
- Refuse the duplicate
- Try to go back to draft

# The problem
The user is deadlocked and cannot go back to draft because of a client validation on the field employee_ids. The user cannot change that field because it is readonly, so he is stuck.

# Why
When duplicating a hr.leave, employee_id is copied but not employee_ids. Going back to the issue steps, if you look at the Employees field of the duplicate, it is empty. This later cause the issue with the client side validation.

Copying employee_ids when there are multiple employees did not seem like the best idea because a lot of flows relies on employee_id. employee_id is computed as follows :
```py
    def _compute_from_employee_ids(self):
        for holiday in self:
            if len(holiday.employee_ids) == 1:
                holiday.employee_id = holiday.employee_ids[0]._origin
            else:
                holiday.employee_id = False
```
So if we copy multiple employees in employee_ids, employee_id will be null, which might break these flows.

opw-5995398

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

The _compute_cumulated_balance() method performs a query over every
existing move lines to get a dict associating the record id with
the cumulated sum at this point.

When there is a lot of move lines, the result returned by fetchall()
hits the memory limit and the server crashes.

We propose to encapsulate the original query to only return
the result for the account move lines present in self.

Benchmarks
---------------

The following benchmarks were generated with a customization of
the account.move.line list view to display the cumulated_balance
field.

Memory usage during the self.env.cr.execute and the dictionary
population:

|     Operation | Before the fix | After the fix |
|---------------|----------------|---------------|
| populate dict |         1.5 GB |       17.1 MB |
| execute query |         430 MB |        8.3 MB |

100 000 lines were displayed at the same time to get a significant
size.
So the number of records in self is more than 7 000 000 without
the fix and 100 000 with the fix.

Time spent in the _compute_cumulated_balance method:

| No of AML | Before the fix | After the fix |
|-----------|----------------|---------------|
| 7 000 000 |         10.4 s |         6.8 s |

opw-6053720

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