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

1. Create a contact (with minimal details).
2. Create a customer invoice for that contact **last month** with `quantity = 300`.
3. Create a credit note for that invoice **this month**.
4. Create another customer invoice for the same contact **this month** with `quantity = 100`.

In the FAIA report (XML), within the General Ledger section, the partner is incorrectly classified as a supplier instead of a customer.

In the method _saft_fill_report_partner_ledger_values from account_saft, he partner type is determined based on whether the balance is negative.

However, a negative balance can result from a credit note, where the partner is still a customer and not a supplier. Furthermore, a partner can be both a supplier and a customer.

This commit allows a partner to be both a customer and a supplier. If both receivable and payable are 0 we set the partner type to customer to keep the behavior from e9640caf29e967fe7d8c6fe303b5a8d7a866437e

opw-5360924

Forward-Port-Of: odoo/enterprise#106559
Forward-Port-Of: odoo/enterprise#100749

**Steps to reproduce:**
- Create a DB with l10n_ar and l10n_ar ecommerce
- Go to Settings > Invoicing > Fiscal Localization
- Select the 'Argentina - Argentine Generic Chart of Accounts for Registered Accountants' package
- Create a website, and a portal user
- Add a main and a secondary address to the user using the website form in 'My Account'
- Go to the secondary address and change any field
- Click on Save Address
- Multiple errors will appear on the form (reproducible with other similar config)
(and in logs: `UserWarning: unsupported operand type(s) for "==": 'l10n_latam.identification.type()' == '1'`)

**Issue:**
In `address_form_fields` some hidden input field are used to add specific non-editable values to the forms.

This breaks the address validation of `CustomerPortal` in `def _validate_address_values` due to the following comparison: `partner_sudo[commercial_field_name] != address_values[commercial_field_name]`
which try to compare recordsets with the given ids.

**Fix:**
Cast relational field to their id values to ensure they can be properly compared to the website form values.

related fix which introduces the input issue: https://github.com/odoo/odoo/commit/0ee91631214c34b650342a0210ee8db27764f252

opw-5247171

Forward-Port-Of: odoo/odoo#244532

__Before commit__
When using `makeButtonHandler`, a loading effect is applied to the
button if the handler takes more than 400ms to execute. However, if
the handler finishes sooner, the effect is still briefly added and
removed, triggering a DOM mutation.

If a button is clicked and the website builder opens immediately
after, this mutation may be recorded in the current history step
despite being unnecessary.

This causes the `design-themes` tour `theme_menu_hierarchies` to fail
in a non-deterministic way with the following warning:
"should not have any 'characterData', 'remove' or 'add' mutations in
current step when you update the selection"

__Fix__
Ensure the loading effect is never added if the handler execution
time is shorter than the debounce duration.

This fix is applied to both `makeButtonHandler` functions in the
codebase. The test case is only added for the interaction use case,
as the other instance resides in legacy code.

runbot-229803

Forward-Port-Of: odoo/odoo#248242

Currently, an error occurs when user tries to validate a domain with no field name.

Steps to install:
- Install `sale_management` > Open sale order list view > Turn on debug mode.
- Click on search bar > Custom filter > Click on field and remove its field name written below the list of fields.
- Click validate.

Error:
```
TypeError: Empty field name in condition ('', '=', 1)
```

Cause:
- As the field name was emptied by the user the [line] will raise a TypeError during the domain validation.
- Till `19.0` any error during domain validation was handled  through [here] which was later changed to handle only ValueErrors through this [commit].

Solution:
- Handled TypeErrors during domain validation.

[line]: https://github.com/odoo/odoo/blob/260b9c0417ed2278429fcdd7f50d61786d4e9beb/odoo/orm/domains.py#L841

[here]: https://github.com/odoo/odoo/blob/a220fb71c036c93fa1e75d4d37127e5eda0118f9/addons/web/controllers/domain.py#L34

[commit]: https://github.com/odoo/odoo/commit/a1434c32e9f4dd226d512677fd96e3051b908d8b#diff-e5da86414a8020b2843fb359453238e4977027d30f73f1fa792ca63ddd8fa2a7L34-R23

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

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

Forward-Port-Of: odoo/enterprise#107920

In the `industry_fsm_report` and `quality_control_worksheet` modules, worksheet fields created during onboarding was moved from XML to Python (https://github.com/odoo/enterprise/commit/d619aa4d0d042be3f899b777081b7fb90f851c84). They were noupdate=1 before moving to Python ([quality_control_worksheet](https://github.com/odoo/enterprise/blob/d619aa4d0d042be3f899b777081b7fb90f851c84/quality_control_worksheet/data/quality_worksheet_demo.xml#L3), [industry_fsm_report](https://github.com/odoo/enterprise/blob/d619aa4d0d042be3f899b777081b7fb90f851c84/industry_fsm_report/data/fsm_report_demo.xml#L3)).

The issue is without this patch, the dbs which loaded those fields in version `19.0` will have referencing xmlid, with noupdate=0. On the other side as they do not have record in xml files, during the upgrade to > 19.0 it will introduce an issue like this:

```
odoo.upgrade.util.exceptions.UpgradeError: 💥 It looks like you forgot to call `util.remove_field` on the following fields: x_project_task_worksheet_template_2.x_worker_signature
2026-02-15 20:17:38,149 23 INFO db_3904048 odoo.service.server: Initiating shutdown
```

tbg-2468

Forward-Port-Of: odoo/enterprise#108276

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

Forward-Port-Of: odoo/odoo#242274

Steps to reproduce:
1. Setup an employee with a bank account where the account holder is different from the employee (e.g., a spouse).
2. Generate a payslip for this employee.
3. Print the payslip (PDF) or generate a payment export (SEPA, NACHA, ABA, CSV).
4. Observe that the employee's name is displayed instead of the account holder's information.

Issue:
Payroll reports and payment exports were frequently hardcoded to use the employee's legal name or work contact ID. This is incorrect when a bank account belongs to a different partner, as payment records should reflect the actual account holder.

Solution:
Unified logic across standard and localized payroll modules (AU, BE, CH, IN, SA, US) to prioritize the bank account's linked partner:
- Updated QWeb templates to display bank.partner_id.name for account allocations.
- Modified payment wizards (CSV, NACHA, ABA, SEPA) to use the bank account's partner ID.
- Ensured a fallback to the employee's legal name remains in place.

opw-5357652

Forward-Port-Of: odoo/enterprise#106718