Currently, a traceback occurs when a lead won in a previous year is moved to another won stage in the current year.

### **Steps to Reproduce:**
1) Install CRM without demo data.
2) From the `CRM>Configuration>Stages` make `new` stage as **'won'** stage.
 3) Create a lead with dated in the past (e.g., 30-12-2025 by changing system date)
   and with some expected_revenue.
4) Change the system date to today and move the lead to the Won stage.

Ref Video: https://drive.google.com/file/d/18OCQ4Tl6Co_oh28XNag3qjxMkXJNSMOh/view?usp=sharing

### **Error:**
`TypeError: '<' not supported between instances of 'NoneType' and 'float'`

### **Root Cause:**
When a lead is moved to a won stage, `_get_rainbowman_message` is called and computes the values for `max_{team,user}_{31,7}`. However, when the lead spans different years, the condition of SQL query at [1] fails(because 2025 != 2026) due to which SQL query return null from the MAX() Function. As a result, subsequent comparisons at [2] fail, raising an Error.

### **FIX:**
Introduce small helper method(`_is_lower_than_expected_revenue`) to ensure comparisons
across different years only happen when we have meaningful numeric values.

[1]- https://github.com/odoo/odoo/blob/fb4e08fe46c0e1865e30b0ce1eb5f4436438ea03/addons/crm/models/crm_lead.py#L1218

[2]- https://github.com/odoo/odoo/blob/fb4e08fe46c0e1865e30b0ce1eb5f4436438ea03/addons/crm/models/crm_lead.py#L1232

**opw-5484887**
**sentry-7026119584**

Forward-Port-Of: odoo/odoo#244938

Currently, when operating in a branch company, contacts belonging to the parent company are not visible in the partner dropdown on Invoices or Vendor Bills.

### **Steps to reproduce:**
1) Create a multi-company hierarchy (Company A -> Branch B). 
2) Create a contact owned by Company A.
3) Switch the current company to Branch B.
4) Go to Accounting > Customers > Invoices and create a new invoice.
5) Try to select the contact created in step 2.

### **Current/Buggy Behavior:**
The contact does not appear in the search results.

### **Expected Behavior:**
The contact should be selectable.

### **Root Cause:**
since commit https://github.com/odoo/odoo/commit/67169c42061cb51bc68f6c74f0674a670dd04f58,
the partner model supports the standard
`check_company=True` mechanism, and record rules were updated to allow
branches to access partners of their parent company.

However, the `partner_id` field on the `account.move` form view still
retained a explicit domain: `[('company_id', 'in', (False,
company_id))]` as shown at [1].

This domain overrides the standard `check_company` behavior.
due to which it restricts the selection to partners owned by the current company
(the branch) or partners with no company set. It explicitly excludes
partners owned by the parent company.

### **Fix:**
Remove the domain at [1],
This allows the field to rely on the standard `check_company=True`
logic, which correctly handles the multi-company hierarchy and allows
branches to select parent company partners.

[1]- https://github.com/odoo/odoo/blob/6b7b83449739932aa8420ef8fcd888116e3c0f8a/addons/account/views/account_move_views.xml#L896

**opw-5484611**

Forward-Port-Of: odoo/odoo#244671

This PR fixes an issue introduced by Commit[^1]. In Commit[^1], we decided to review the course card layout by removing the individual links that were wrapping the title, the cover image, and the description.

| 19.0 and above | This PR |
|--------|--------|
| <img width="333" height="392" alt="image" src="https://github.com/user-attachments/assets/3dce73b3-0ce9-486e-b1de-f88a74e52e05" /> | <img width="313" height="381" alt="image" src="https://github.com/user-attachments/assets/25d75970-7f55-4967-87ba-3ecf5710835d" /> |

#### Steps to reproduce:
1. Go to `website_slides`
2. Create a new course
3. Go to the description tab
4. Insert a link in the description and save
5. Go to the frontend to see the courses list
6. Course cards with a description containing a link are visually broken.

While this looked like an improvement because it simplified the DOM, it was done with the assumption that the course card could not contain another link. This is, of course, not the case, as the description field
is editable by the user and can therefore contain a link. Because this is not valid HTML, the layout removes all nested links and renders them separately. Since all the classes related to the card design
are applied to that `<a>` tag, all links are rendered with a border and other styling.

This PR fixes the issue by reassigning all the card styles to the card container. We then reassign each property to the corresponding element, adapt the styles to mimic the original card design, and hide extra links
that are rendered empty. This should at least fix the layout for users.

[^1]: https://github.com/odoo/odoo/commit/f632b8a9e74a050288e3ec75a4f49ae3ecb551d6

task-5957910

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

Forward-Port-Of: odoo/odoo#249969

Prior to this commit, since DOMPurify v3.1.2 (and more precisely since usage of v3.1.5
in Odoo), the JS sanitization process aggressively removes html attributes with
`-->`, `<style` and `<title` for security reasons (see [1]).

However `html_editor` embedded components use `data-attributes`
(`data-embedded-props` and `data-embedded-state`) to store various kind of data
as a JSON string. Obviously, such JSON strings easily match the DOMPurify regex
and these attributes are therefore removed, which results in an Editor crash.

There are multiple reasons why such values are acceptable as is for the
`html_editor` usage:
- only `HTMLElement` instances are sanitized, never a string, therefore there is
  no `DOMParser` to trick with invalid HTML.
- values in these attributes are always/exclusively parsed as JSON strings, and
  the editor will crash if the value is not a legit JSON.
- values in these attributes are HTML escaped by the python sanitizer when the
  serialized html is sent to the server.
- values in the JSON parsed object are at worst rendered as plain text (never as
  HTML or other parsed formats).
- values in the JSON parsed object are never executed as JS (only serializable
  primitives are stored).

Therefore, the suggested solution is to encode the values during sanitization,
and decode just after, to keep the rest of the codebase simple and explicit.

[1]: https://mizu.re/post/exploring-the-dompurify-library-hunting-for-misconfigurations#dompurify-gt-3.1.2-safe-for-xml

task-5960707

Forward-Port-Of: odoo/odoo#250475
Forward-Port-Of: odoo/odoo#250210

# How to reproduce
- Go to the Talen Pool sub-menu of the recuitment app
- Create a new Talent
- Click on the cog button, then on "Edit Properties"

# The problem
A not very descriptive error message is displayed

# Why
The hr.applicant model has a Properties field that allows the edition of its properties directly in the UI. This field needs to be linked to a PropertiesDefintion field in another model. In our case, that definition is in the hr.job model linked to the hr.applicant model via the field job_id. To be able to edit the properties of the hr.applicant model, it needs to be linked to a job, which is not always the case.

A fix was made in master to allow the edition of properties even when there is no job_id (https://github.com/odoo/odoo/commit/99aa75bc64ee8898a0815163603e5861c35b0b94) but that fix is not applicable to a stable version.

The fix I implemented instead hides the button when editing the properties would fail.

opw-5932666

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

Forward-Port-Of: odoo/odoo#248691

…n invoicing

**Issue:**
When generating an invoice for a subscription that contains a mix of regular products (invoiced on order) and timesheet-based services (invoiced on delivery), a traceback can occur if the timesheet service has 0 delivered quantity.

**Cause:**
During the invoice creation process, `_get_reinvoiced_analytic_lines_to_link` iterates over the newly created invoice lines to link analytic lines. It filters the linked sale order lines using `_is_line_reinvoicable()`. If the invoice only contains standard products (because the timesheet line was skipped due to 0 delivery), `so_lines` evaluates to an empty recordset. Passing an empty recordset into `_analytic_line_domain_get_invoiced_lines()` results in a traceback when evaluating the domain.

**Fix:**
Added a safeguard (`if not so_lines: continue`) inside the loop. If an invoice line does not contain any reinvoicable sale order lines, it is now safely skipped, allowing standard subscription lines to be invoiced alongside undelivered timesheet lines without crashing.

task: 5966725

Currently, a traceback occurs when a lead won in a previous year is moved to another won stage in the current year.

### **Steps to Reproduce:**
1) Install CRM without demo data.
2) From the `CRM>Configuration>Stages` make `new` stage as **'won'** stage.
 3) Create a lead with dated in the past (e.g., 30-12-2025 by changing system date)
   and with some expected_revenue.
4) Change the system date to today and move the lead to the Won stage.

Ref Video: https://drive.google.com/file/d/18OCQ4Tl6Co_oh28XNag3qjxMkXJNSMOh/view?usp=sharing

### **Error:**
`TypeError: '<' not supported between instances of 'NoneType' and 'float'`

### **Root Cause:**
When a lead is moved to a won stage, `_get_rainbowman_message` is called and computes the values for `max_{team,user}_{31,7}`. However, when the lead spans different years, the condition of SQL query at [1] fails(because 2025 != 2026) due to which SQL query return null from the MAX() Function. As a result, subsequent comparisons at [2] fail, raising an Error.

### **FIX:**
Introduce small helper method(`_is_lower_than_expected_revenue`) to ensure comparisons
across different years only happen when we have meaningful numeric values.

[1]- https://github.com/odoo/odoo/blob/fb4e08fe46c0e1865e30b0ce1eb5f4436438ea03/addons/crm/models/crm_lead.py#L1218

[2]- https://github.com/odoo/odoo/blob/fb4e08fe46c0e1865e30b0ce1eb5f4436438ea03/addons/crm/models/crm_lead.py#L1232

**opw-5484887**
**sentry-7026119584**

Forward-Port-Of: odoo/odoo#244938

Currently, when operating in a branch company, contacts belonging to the parent company are not visible in the partner dropdown on Invoices or Vendor Bills.

### **Steps to reproduce:**
1) Create a multi-company hierarchy (Company A -> Branch B). 
2) Create a contact owned by Company A.
3) Switch the current company to Branch B.
4) Go to Accounting > Customers > Invoices and create a new invoice.
5) Try to select the contact created in step 2.

### **Current/Buggy Behavior:**
The contact does not appear in the search results.

### **Expected Behavior:**
The contact should be selectable.

### **Root Cause:**
since commit https://github.com/odoo/odoo/commit/67169c42061cb51bc68f6c74f0674a670dd04f58,
the partner model supports the standard
`check_company=True` mechanism, and record rules were updated to allow
branches to access partners of their parent company.

However, the `partner_id` field on the `account.move` form view still
retained a explicit domain: `[('company_id', 'in', (False,
company_id))]` as shown at [1].

This domain overrides the standard `check_company` behavior.
due to which it restricts the selection to partners owned by the current company
(the branch) or partners with no company set. It explicitly excludes
partners owned by the parent company.

### **Fix:**
Remove the domain at [1],
This allows the field to rely on the standard `check_company=True`
logic, which correctly handles the multi-company hierarchy and allows
branches to select parent company partners.

[1]- https://github.com/odoo/odoo/blob/6b7b83449739932aa8420ef8fcd888116e3c0f8a/addons/account/views/account_move_views.xml#L896

**opw-5484611**

Forward-Port-Of: odoo/odoo#244671

This PR fixes an issue introduced by Commit[^1]. In Commit[^1], we decided to review the course card layout by removing the individual links that were wrapping the title, the cover image, and the description.

| 19.0 and above | This PR |
|--------|--------|
| <img width="333" height="392" alt="image" src="https://github.com/user-attachments/assets/3dce73b3-0ce9-486e-b1de-f88a74e52e05" /> | <img width="313" height="381" alt="image" src="https://github.com/user-attachments/assets/25d75970-7f55-4967-87ba-3ecf5710835d" /> |

#### Steps to reproduce:
1. Go to `website_slides`
2. Create a new course
3. Go to the description tab
4. Insert a link in the description and save
5. Go to the frontend to see the courses list
6. Course cards with a description containing a link are visually broken.

While this looked like an improvement because it simplified the DOM, it was done with the assumption that the course card could not contain another link. This is, of course, not the case, as the description field
is editable by the user and can therefore contain a link. Because this is not valid HTML, the layout removes all nested links and renders them separately. Since all the classes related to the card design
are applied to that `<a>` tag, all links are rendered with a border and other styling.

This PR fixes the issue by reassigning all the card styles to the card container. We then reassign each property to the corresponding element, adapt the styles to mimic the original card design, and hide extra links
that are rendered empty. This should at least fix the layout for users.

[^1]: https://github.com/odoo/odoo/commit/f632b8a9e74a050288e3ec75a4f49ae3ecb551d6

task-5957910

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

Forward-Port-Of: odoo/odoo#249969

Prior to this commit, since DOMPurify v3.1.2 (and more precisely since usage of v3.1.5
in Odoo), the JS sanitization process aggressively removes html attributes with
`-->`, `<style` and `<title` for security reasons (see [1]).

However `html_editor` embedded components use `data-attributes`
(`data-embedded-props` and `data-embedded-state`) to store various kind of data
as a JSON string. Obviously, such JSON strings easily match the DOMPurify regex
and these attributes are therefore removed, which results in an Editor crash.

There are multiple reasons why such values are acceptable as is for the
`html_editor` usage:
- only `HTMLElement` instances are sanitized, never a string, therefore there is
  no `DOMParser` to trick with invalid HTML.
- values in these attributes are always/exclusively parsed as JSON strings, and
  the editor will crash if the value is not a legit JSON.
- values in these attributes are HTML escaped by the python sanitizer when the
  serialized html is sent to the server.
- values in the JSON parsed object are at worst rendered as plain text (never as
  HTML or other parsed formats).
- values in the JSON parsed object are never executed as JS (only serializable
  primitives are stored).

Therefore, the suggested solution is to encode the values during sanitization,
and decode just after, to keep the rest of the codebase simple and explicit.

[1]: https://mizu.re/post/exploring-the-dompurify-library-hunting-for-misconfigurations#dompurify-gt-3.1.2-safe-for-xml

task-5960707

Forward-Port-Of: odoo/odoo#250475
Forward-Port-Of: odoo/odoo#250210

# How to reproduce
- Go to the Talen Pool sub-menu of the recuitment app
- Create a new Talent
- Click on the cog button, then on "Edit Properties"

# The problem
A not very descriptive error message is displayed

# Why
The hr.applicant model has a Properties field that allows the edition of its properties directly in the UI. This field needs to be linked to a PropertiesDefintion field in another model. In our case, that definition is in the hr.job model linked to the hr.applicant model via the field job_id. To be able to edit the properties of the hr.applicant model, it needs to be linked to a job, which is not always the case.

A fix was made in master to allow the edition of properties even when there is no job_id (https://github.com/odoo/odoo/commit/99aa75bc64ee8898a0815163603e5861c35b0b94) but that fix is not applicable to a stable version.

The fix I implemented instead hides the button when editing the properties would fail.

opw-5932666

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

Forward-Port-Of: odoo/odoo#248691

*: mrp_subcontracting

Issue:
---------------------------------
When subcontracting a lot/serial-tracked product and generating multiple subcontracting MOs by generating SN numbers or the "Create New Production" action, only the `first serial number line` appears in the "Move" detail operations smart button.
Although all move lines are correctly created on the move, this behaviour is confusing for the user.

Steps to reproduce:
---------------------------------
1. Install the `mrp_subcontracting_purchase` module.
2. Create a serial-tracked product and its subcontracting BoM.
3. Create a PO with a subcontracting vendor and a product quantity greater than 1.
4. Confirm the PO and validate the resupply.
5. Open the receipt and click on the "Subcontracting Production" smart button.
6. Generate serial numbers for the product.
7. Validate the receipt and open the "Move" detail operations smart button.
8. Only one line (the first serial number) is shown, while the move actually contains all move lines.

Cause:
---------------------------------
When serial numbers are generated from the subcontracting MO view, or when a new MO is created using the "Create New Production" action introduced in [PR](https://github.com/odoo/odoo/pull/218377), new move lines are created without setting the `picking_id`.
As a result, these move lines are linked to the stock move but not directly to the picking.
Since the "Move" detail operations smart button relies on the picking’s `move_line_ids`, the newly created move lines are not displayed.

With this commit:
---------------------------------
The `picking_id` is now set on newly created move lines. This ensures that all move lines are directly linked to the picking, allowing the "Move" detail operations smart button to display all serial/lot lines correctly and improving traceability for the user.

And also When working with a subcontracting order, if the user opens the lot/serial number generation wizard from the subcontracting production and directly clicks 'Apply' without creating or assigning any lot/serial number, Odoo raises the following traceback:
`IndexError: tuple index out of range`
This issue has also been fixed here.

Forward-Port-Of: odoo/odoo#243988

### Issue:
Having a calendar with a timezone different from utc and looking at the planning gantt view, the hours displayed in the "Total" row are wrong.

### Steps to reproduce:
- Have an employee with a calendar in "Europe/Brussels" and working from 8 to 17
- In planning add a line for this employee
- Display the gantt view on a day
- Create a shift for this employee from 8 to 17
- In the "Total" row, the first hour is not counted

### Cause:
To compute the values displayed in the Total row, we take the intersection of the shift and the working hours from the calendar. ([src](https://github.com/odoo/enterprise/blob/2b887d094c66be7aebd92fbf735b1852f5dde4b5/planning/static/src/views/planning_gantt/planning_gantt_renderer.js#L318)) But the working hours from the calendar are given in UTC for this computation (without conversion), this result in a discrepancy between the actual hours of the calendar (with timezone conversion) and the one given to compute the total row.

### Solution:
`resource_work_intervals()` returns the work intervals with the calendar hours and the resource timezone.

In our case, only the hours are interesting (the previous code replaced the timezone by UTC). We need to convert them from the calendar timezone to UTC. So the first thing to do is remove the timezone from `resource_work_interval` then we localize it in the calendar timezone and to finish we convert it to UTC.

opw-5564749

Forward-Port-Of: odoo/enterprise#106891

Currently, when a user tries to print a resume with an invalid template there’s no traceback to show what went wrong.

**Steps to produce:**
* Install `hr` with demo data
* Modify the view `report_employee_cv`  by adding `<div t-if=o.no/>`
* Print resume of any employee

**Observed Behavior:**
Currently it only shows the error in [1], with no context or traceback to explain what went wrong.

**Root cause:**
* This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6].

**Solution:**
* Catching and raising UserError shows appropriate traceback.

**Before:**
<img width="1606" height="796" alt="image" src="https://github.com/user-attachments/assets/d5432fbf-d016-46a9-bade-8e8408848c66" />

**After:**
<img width="1832" height="928" alt="image" src="https://github.com/user-attachments/assets/6f0413ca-a82a-487d-888f-81be6f0fab03" />

[1]:
https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing 
[2]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 
[3]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 
[4]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 
[5]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 
[6]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575
Related: https://github.com/odoo/enterprise/pull/100142

opw-5167898

Forward-Port-Of: odoo/odoo#250286
Forward-Port-Of: odoo/odoo#237262

Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong.

**Steps to produce:**
* Install payroll with demo data.
* Settings > Configure Document Layout then Edit Layout
* Add non-existent field `<div t-if='o.no'/>`
* Payroll > All payslips > print any payslip

**Observed Behavior:**
* Currently it only shows the error in [1], with no context or traceback to explain what went wrong.

**Root cause:**
* This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6].

**Solution:**
* Catching and raising UserError shows appropriate traceback.

**Before:**
<img width="1601" height="507" alt="image" src="https://github.com/user-attachments/assets/f7f208f0-cdd7-410e-87e7-32a9651df9d8" />

**After:**
<img width="1847" height="928" alt="image" src="https://github.com/user-attachments/assets/c73522d6-2632-422b-b1d1-234e6c61ed2e" />

[1]:
https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing 
[2]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 
[3]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 
[4]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 
[5]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 
[6]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575
Related:https://github.com/odoo/odoo/pull/237262

opw-5167898

Forward-Port-Of: odoo/enterprise#108438
Forward-Port-Of: odoo/enterprise#100142

Description:
-----------
When viewing planning shifts in the gantt view, the total hours column displayed wrong totals due to timezone
misalignment in work interval calculations.

Steps to reproduce:
-------------------
1. Create an employee with a fixed working schedule (e.g., 8am-12pm, 1pm-5pm with 1-hour lunch break)
2. Ensure the employee's timezone differs from UTC (e.g., Europe/Brussels UTC+1)
3. Create a shift for this employee covering their full working day (8am-5pm)
4. Open the planning gantt view and check the total hours column for that day
5. Expected: 8 hours total | Actual: 7 hours total (with hours misaligned by timezone offset)

Root Cause:
-----------
In version 19.0, `_gantt_progress_bar_resource_id` used `.replace(tzinfo=pytz.UTC)` when building work intervals, which only changes the timezone label without converting the actual time values. This caused a timezone offset mismatch in the frontend's hour-by-hour comparison.

Solution:
---------
Replace `.replace(tzinfo=pytz.UTC)` with `.astimezone(pytz.UTC)` to properly convert datetime values to UTC before sending to the frontend.

opw-5190244

Forward-Port-Of: odoo/enterprise#104185

Currently, when operating in a branch company, contacts belonging to the parent company are not visible in the partner dropdown on Invoices or Vendor Bills.

### **Steps to reproduce:**
1) Create a multi-company hierarchy (Company A -> Branch B). 
2) Create a contact owned by Company A.
3) Switch the current company to Branch B.
4) Go to Accounting > Customers > Invoices and create a new invoice.
5) Try to select the contact created in step 2.

### **Current/Buggy Behavior:**
The contact does not appear in the search results.

### **Expected Behavior:**
The contact should be selectable.

### **Root Cause:**
since commit https://github.com/odoo/odoo/commit/67169c42061cb51bc68f6c74f0674a670dd04f58,
the partner model supports the standard
`check_company=True` mechanism, and record rules were updated to allow
branches to access partners of their parent company.

However, the `partner_id` field on the `account.move` form view still
retained a explicit domain: `[('company_id', 'in', (False,
company_id))]` as shown at [1].

This domain overrides the standard `check_company` behavior.
due to which it restricts the selection to partners owned by the current company
(the branch) or partners with no company set. It explicitly excludes
partners owned by the parent company.

### **Fix:**
Remove the domain at [1],
This allows the field to rely on the standard `check_company=True`
logic, which correctly handles the multi-company hierarchy and allows
branches to select parent company partners.

[1]- https://github.com/odoo/odoo/blob/6b7b83449739932aa8420ef8fcd888116e3c0f8a/addons/account/views/account_move_views.xml#L896

**opw-5484611**

Forward-Port-Of: odoo/odoo#244671

Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong.

**Steps to produce:**
* Install payroll with demo data.
* Settings > Configure Document Layout then Edit Layout
* Add non-existent field `<div t-if='o.no'/>`
* Payroll > All payslips > print any payslip

**Observed Behavior:**
* Currently it only shows the error in [1], with no context or traceback to explain what went wrong.

**Root cause:**
* This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6].

**Solution:**
* Catching and raising UserError shows appropriate traceback.

**Before:**
<img width="1601" height="507" alt="image" src="https://github.com/user-attachments/assets/f7f208f0-cdd7-410e-87e7-32a9651df9d8" />

**After:**
<img width="1847" height="928" alt="image" src="https://github.com/user-attachments/assets/c73522d6-2632-422b-b1d1-234e6c61ed2e" />

[1]:
https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing 
[2]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 
[3]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 
[4]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 
[5]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 
[6]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575
Related:https://github.com/odoo/odoo/pull/237262

opw-5167898

Forward-Port-Of: odoo/enterprise#100142

Prior to this commit, creating a multi-action that moved a document to a
new folder and immediately triggered another action (e.g., "Create
Invoice") often failed. This occurred because the security check required
the sub-action to be explicitly embedded (pinned) on the *destination*
folder. Since the record was moved during the process, the subsequent
action failed the security check on the new folder where it wasn't pinned.

This limitation caused confusion for users setting up automation flows,
as the intent of the sequence (Move -> Action) was clear and initiated
from a valid context (the source folder), but strict per-action security
rules blocked execution.

This commit improves the `ir.actions.server` execution logic to support
this pattern by introducing a context-based security sentinel:

1. Entry Point Validation: When a Documents action (root) is triggered,
   the system enforces strict security: the action must be explicitly
   embedded on the record's current folder.
2. Context Inheritance: Once the root action is authorized and begins
   execution, it sets a secure sentinel in the context.
3. Trusted Execution: Any subsequent sub-actions (children) detect this
   sentinel and are allowed to run, regardless of the record's current
   folder location.

This ensures that if a user has the right to start the process (the root
action), they have the right to complete the defined sequence, even if
intermediate steps move the record to a folder where the sub-actions are
not explicitly pinned.

As a result, the `_can_execute_action_on_records` override in
`documents_account` is no longer necessary and has been removed.

Tests have been extended in the `documents` and `documents_account` 
modules to cover these scenarios (using Tags in the `documents`
module instead of Accounting-specific models to make the tests generic).
A new test file `test_documents_ir_actions_server.py` was created
to maintain a clean testing environment, covering nesting, move sequences,
and RPC spoofing attempts.

Task-5916630

Forward-Port-Of: odoo/enterprise#108204
Forward-Port-Of: odoo/enterprise#106702

Steps to reproduce the issue:
1. Install the module `l10n_mx_hr_payroll_account_edi`.
2. Generate a payslip for an employee.
3. The following traceback is raised at the moment to click on "Generate CFDI" button: 
```py
File "/data/build/odoo/odoo/addons/base/models/ir_qweb.py", line 858, in _render_iterall raise 
QWebError(qweb_error_info) from error odoo.addons.base.models.ir_qweb.QWebError: Error while rendering the 
template: KeyError: 'l10n_mx_ssn' Template: l10n_mx_hr_payroll_account_edi.report_payslip_mx_cfdi Reference: 
8166 Path: /t/t/div/t[2]/div[4]/table[2]/tbody/tr/td/div[5]/span[1]
    Element: <span class="ms-1" t-field="o.version_id.l10n_mx_ssn"/>
```

---
To avoid moving the `l10n_mx_ssn` field from the `hr.employee` model to `hr.version`, the `t-field` in the template is updated to `o.employee_id.l10n_mx_ssn`.

This approach is valid because an employee's SSN rarely changes. If a modification is ever needed, it can be updated directly on the employee form, where the field is already tracked.

target: saas-19.2
task-5962423

Forward-Port-Of: odoo/enterprise#108398

An accent sanitization feature was introduced in Odoo 18 [1]. It was done because it appeared the SAT replaced certain characters with their unaccented counterpart, but it's not the case. At least today, the SAT allows all characters (pointed out in [2]).

This explains why in the past 6 months this feature has been slowly undone [3][4][5], character by character, after customers run into issues.

The approach can not work, so we go back to the name with the accents the user puts on the partner. Users need to put the correct, legally registered name in Odoo. If it doesn't work then they can adapt it as needed. This way the user is in full control, and we don't block them.

This reverts the whole accent sanitization saga:

- Revert "[FIX] l10n_mx_edi - More accented characters accepted by SAT", this reverts commit 46cc41ddd258e80372478a746ea79d154a5931d9.
- Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit dcbd8797667b5be88f48045e48da86ac42db362c.
- Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit 32b8333fd3f813ec3188394c2634129e3fbfe31d.
- Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit 05ed1fb9059bd1459e38dc00b041cada6bf06ac4.

This also removes the unused frozendict import to make "Check Style" happy.

opw-5915515

[1] https://github.com/odoo/enterprise/pull/95207
[2] https://github.com/odoo/enterprise/pull/107960
[3] https://github.com/odoo/enterprise/pull/96043
[4] https://github.com/odoo/enterprise/pull/106557
[5] https://github.com/odoo/enterprise/pull/107677

Closes odoo/enterprise#107960

Forward-Port-Of: odoo/enterprise#108425
Forward-Port-Of: odoo/enterprise#108189

## Issue
When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead.

## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a Product P
    - *Subscriptions* checked
    - *Invoicing Policy*: *Delivered quantities*
3. Create a Subscription S
    - Any Customer
    - Any plan
    - Product P (any quantity)
4. Confirm the subscription S, set the amount delivered to the quantity ordered, then create and confirm the invoice
5. On the subscription S, click *Upsell*, add the product P to the upsell, and repeat step 4 on the upsell
6. **The upsell's _Invoice Status_ is still _To Invoice_, even though we invoiced it in the previous step**

## Causes

In the `SaleOrderLine._compute_invoice_status`, the following condition skips line from orders that are not considered to be "subscriptions":

https://github.com/odoo/enterprise/blob/c33e668bbba37c34d18af8c5371ab80eedf1b965/sale_subscription/models/sale_order_line.py#L51-L62

This is the case of upsells, as explained here:

https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201

---

Updating the above condition to take upsells in account is not enough. The condition to set the `invoice_status` to `invoiced` does not work as expected either.

https://github.com/odoo/enterprise/blob/5f4bb0ca22d068247540a4dcae88905c7b312f3c/sale_subscription/models/sale_order_line.py#L77-L78

In fact, when invoicing the subscription/upsell manually, there are multiple cases where the `last_invoiced_date` will be after `today`, and the subscription will be invoiced, so its status should be `invoiced`.

| Upsell | Invoiced based on delivered quantities | last_invoiced_date      |
|--------|----------------------------------------|-------------------------|
| True   | True                                   | today + 1 month         |
| False  | True                                   | today                   |
| True   | False                                  | today + 1 month - 1 day |
| False  | False                                  | today + 1 month - 1 day |

An alternative logic is to consider the subscription to be invoiced as long as the `next_invoice_date` is not reached.

---

opw-5500585

To reproduce
-------------
1. Install `l10n_es_edi_verifactu_pos`, and select the ES company
2. Make an order in PoS with a price less than 400, and don't invoice it.
3. Close the PoS session, then go to PoS > Orders, and select the previously made order
4. It will have a Verifactu generated document with invoice type as 'F2', which is correct since it's a simplified order.
5. Click invoice to invoice the order; the invoice is no longer simplified.

Notice now that the new Verifactu document has an invoice type of 'F1', which corresponds to a normal non simplified invoice. However, since the new invoice is replacing an old simplified one, it should be of type 'F3' instead.

The fix
-------
When fully invoicing, we check if the order had a linked Veri*factu document of type F2, which means we are now replacing it and should set the type of the new invoice to F3 instead of F1.

Sources:
--------
Difference between 'F1', 'F2', and 'F3' invoice types: https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html?faqId=bdbd20022fe06910VgnVCM100000dc381e0aRCRD

opw-5343973

### Steps to detect the bug:
  - Download stock apps
  - Enable "storage locations" settings under warehouse index
  - Change name of warehouse with a name composed only of numbers (ex. 01)
  - Create a product (with barcode number)
  - Insert a number of products available with smart button "on hand"
  - Create a new delivery for that product
  - Go to barcode app and search for the delivery you just created
  - Click on it and see that the name of the warehouse will be stock/01 instead of the correct 01/stock
    
### The problem:
The previous configuration used direction: rtl; on the warehouse name
element in the barcode app. So if the string contains only letters the
standard visual order is maintained, however, when the string consists
entirely of numbers the rtl property forces the browser to reorder them
from right to left.

### The reson to introduce the fix:
By removing this property, it is ensured that numerical warehouse codes are displayed in their natural sequence without being flipped.
    
opw-5730199

Steps:
- Create a price list (or existing one)
- Create (or find) a product with only one variant
- Add price list rule for that variant (Should show as Variant:... in Pricelist listing)
- Go to pricelist listing, select the pricelist
- Edit price list rule - Remove the product
- Save and check the data (applied_on, product_id, product_tmpl_id) (applied_on still 0_product_variant, product_id, and NO product_tmpl_id)

Related ticket:
opw-5411034

(Video: https://drive.google.com/file/d/1xmg9A9NgavFQkIFkUZrzuAxVF-PNqdnL/view)

Description of the issue/feature this PR addresses:
Fix corrupted data
<img width="583" height="108" alt="image" src="https://github.com/user-attachments/assets/961e75f8-b2a6-4812-a0b4-d73e02d52b08" />

Current behavior before PR:
product_tmpl_id set to None
product_id / applied_on data stays the same

Desired behavior after PR is merged:
When product_tmpl_id is removed, reset the applied_on type back to 3_global

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

Steps to Reproduce: https://www.awesomescreenshot.com/video/49329263?key=2daddfb65e4ee8dcf1a047c09c6bd2b5
- Install l10n_uk_reports module
- Keep the VAT value empty for the UK Company
- On the Tax Report (GB), click Connect to HMRC
- Establish connection with HMRC
- After a successful connection, try to send the tax report to HMRC
- Traceback will appear

<details><summary>Exact Traceback</summary>
<p>

```
RPC_ERROR

Odoo Server Error

Occured on 100710704-master-all.runbot216.odoo.com on model account.report on 2026-02-11 12:50:03 GMT

Traceback (most recent call last):
  File "/data/build/odoo/odoo/http/requestlib.py", line 632, in _serve_db
    return retrying(serve_func, env=self.env)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/http/retrying.py", line 52, in retrying
    result = func()
             ^^^^^^
  File "/data/build/odoo/odoo/http/requestlib.py", line 687, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/http/dispatcher.py", line 308, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/addons/base/models/ir_http.py", line 374, in _dispatch
    result = endpoint(**request.params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/http/routing_map.py", line 207, in route_wrapper
    result = endpoint(self, *args, **params_ok)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/addons/web/controllers/dataset.py", line 32, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/service/model.py", line 57, in call_kw
    result = method(recs, *args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_report.py", line 2825, in dispatch_report_action
    return report_to_call.dispatch_report_action(options, action, action_param=action_param, on_sections_source=False)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/account_reports/models/account_report.py", line 2836, in dispatch_report_action
    return report_method(model, *args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/l10n_uk_reports/models/account_financial_report.py", line 30, in send_hmrc
    self.env['l10n_uk.vat.obligation'].import_vat_obligations(self.env.context['client_data'])
  File "/data/build/enterprise/l10n_uk_reports/models/hmrc_vat_obligation.py", line 124, in import_vat_obligations
    self._get_vat(),
    ^^^^^^^^^^^^^^^
  File "/data/build/enterprise/l10n_uk_reports/models/hmrc_vat_obligation.py", line 111, in _get_vat
    if vat.startswith(('GB', 'XI')):
       ^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'startswith'

The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
    RPC_ERROR
        at makeErrorFromResponse (https://100710704-master-all.runbot216.odoo.com/web/assets/0a37914/web.assets_web.min.js:3225:165)
        at XMLHttpRequest.<anonymous> (https://100710704-master-all.runbot216.odoo.com/web/assets/0a37914/web.assets_web.min.js:3231:13)
```

</p>
</details> 

Reason:
- No VAT set on the current company.

Solution:
- Blocking level error for the user to set VAT on the current company.

Task-5929908

Currently, when operating in a branch company, contacts belonging to the parent company are not visible in the partner dropdown on Invoices or Vendor Bills.

### **Steps to reproduce:**
1) Create a multi-company hierarchy (Company A -> Branch B). 
2) Create a contact owned by Company A.
3) Switch the current company to Branch B.
4) Go to Accounting > Customers > Invoices and create a new invoice.
5) Try to select the contact created in step 2.

### **Current/Buggy Behavior:**
The contact does not appear in the search results.

### **Expected Behavior:**
The contact should be selectable.

### **Root Cause:**
since commit https://github.com/odoo/odoo/commit/67169c42061cb51bc68f6c74f0674a670dd04f58,
the partner model supports the standard
`check_company=True` mechanism, and record rules were updated to allow
branches to access partners of their parent company.

However, the `partner_id` field on the `account.move` form view still
retained a explicit domain: `[('company_id', 'in', (False,
company_id))]` as shown at [1].

This domain overrides the standard `check_company` behavior.
due to which it restricts the selection to partners owned by the current company
(the branch) or partners with no company set. It explicitly excludes
partners owned by the parent company.

### **Fix:**
Remove the domain at [1],
This allows the field to rely on the standard `check_company=True`
logic, which correctly handles the multi-company hierarchy and allows
branches to select parent company partners.

[1]- https://github.com/odoo/odoo/blob/6b7b83449739932aa8420ef8fcd888116e3c0f8a/addons/account/views/account_move_views.xml#L896

**opw-5484611**

Forward-Port-Of: odoo/odoo#244671

Description of the issue/feature this PR addresses:

Yahoo and other strict mail servers reject emails with `554 Invalid Subject header` when Subject headers are folded at 78 characters and contain RFC 2047 encoded-words representing non-ASCII characters.

The issue occurs because:
1. Long email subjects with accented characters (French: "arrière", "connecté", etc.) are RFC 2047 encoded
2. Python's `email.policy.SMTP` folds these headers at 78 characters per RFC 5322 SHOULD recommendation
3. Yahoo's strict validation rejects folded subjects when the fold occurs at certain positions within or between encoded-words
4. This results in customer-facing emails being rejected with no delivery failing silently, leading to missed communications.



Current behavior before PR:

> Subject: [SOS-1477030] Commande et livraison - Demande de retour - user pseudo 251003-GD1U0E - Cosmo Connected Casque Fusion avec feu =?utf-8?q?arri?==?utf-8?q?=C3=A8re_connect=C3=A9?= et accessoire (#1031590)

This subject:
- Is 168 characters when unfolded
- Is folded into 3 lines (78, 74, 60 chars)
- Contains RFC 2047 encoded "arrière connecté"
- Is technically RFC 2822 compliant
- **Gets rejected by Yahoo with "554 Invalid Subject header"**


While this is technically RFC 2822 compliant, Yahoo's strict validation rejects it.

Python's `email.policy.SMTP` folds headers at 78 characters to follow RFC 5322's SHOULD recommendation. However, when subjects contain non-ASCII characters that get RFC 2047 encoded, the folding can create patterns that strict mail servers reject.


Desired behavior after PR is merged:

- No folding of Subject headers, regardless of length
- Yahoo and all strict SMTP servers accept these emails
- Customer support emails deliver successfully

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

*: project_purchase, sale_project

---

Decription of the issue this commit addresses:

When confirming a sales order with a product-partner combination that has an Analytic Distribution Model assigned, any custom analytic distribution done on the line of the product will be lost, resetting the analytic distribution to the default value set on the Analytic Distribution Model.

---

Steps to reproduce:

1. Install sale_project,project_purchase.
2. Activate "Analytic Accounting" in the settings.
3. Create a new Product "test"; Type: Service, Create on Order: Project.
4. Create a new Analytic Distribution Models; Partner: Acme, Product: test, Analytic Distribution: anything but blank.
5. Create a new Quotation in the Sales apps; Partner: Acme.
6. Assign the Product test to the first order line. This will automatically set the analytic distrib of the Analytic Distribution Model.
7. In the Analytic Distribution cell, add a line with any non null distribution.
8. Confirm the Quotation.
9. The analytic distribution that was anually added has been removed. Only the default analytic distribution of the model remains.

---

Desired behavior after this commit is merged:

Any custom analytic distribution done on a line is never lost. The Analytic Distribution Model's distribution serves as a template but never overrides the values set by the user.

---

opw-4934291

---

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

**Steps to reproduce:**
* Install **Accounting** module.
* Create a **branch company** with a parent company.
* Create and post an invoice for the branch.
* Go to **Accounting → Reporting → Profit & Loss**.
* Switch to the **branch company**.
* Click an report line **⋮ → General Ledger**.
* Click **Download XLSX**.

**Observed behavior:**
* The exported XLSX file is **blank**.
* The report displays correctly in the UI, but the XLSX export shows no accounts.

**Cause:**
* `_get_accounts_with_move_lines` filtered accounts with `account.company_id IN company_ids`, while accounts are defined on the **parent company** and shared with branches via `check_company_domain_parent_of`. When only a branch is selected, no accounts match.
* The AML existence check used `aml.company_id = account.company_id`, but AMLs are recorded with the **branch's company_id**, not the parent’s, so the join never matches branch transactions.
* Additionally, `export_to_xlsx` passed the raw `options` to `_get_accounts_with_move_lines` instead of the regenerated `report_options`, leading to an inconsistent company context.

**Fix:**
* Search accounts using the **parent hierarchy**.
* Still filter move lines by the selected branch company.
* Branches now see parent accounts with only their own transactions in the XLSX export.

opw-5902062