Since the introduction of the employee versioning system, using `employee.field_name` in salary rules is no longer accurate for computations involving historical or specific periods. Accessing fields directly on the `employee` record returns the current values.

This creates an issue when a future version exists. For example, if a new version is created for February 2026 with an updated Child Support amount, generating a delayed payslip for January 2026 would incorrectly use the February value (current state) instead of the January value (historical state).

This commit updates the Python compute logic in the Australian salary rules to use `version.field_name` instead of `employee.field_name`. The `version` object ensures the data used corresponds strictly to the payslip's period.

The following rules/fields are updated to use the version object:
- Tax Treatment Category
- Additional Withholding Amount
- Extra Pay
- TFN Declaration
- Medicare (Reduction, Exemption, and Levy)
- Training Loans
- NAT 3093 Amount (Tax Offset)
- Child Support (Garnishee and Deduction)

A test case is added to verify that a payslip correctly retrieves the child support amount from the version valid during the payslip period, ignoring future updates.

Task-5002697

Forward-Port-Of: odoo/enterprise#108063
Forward-Port-Of: odoo/enterprise#106550

**Steps to reproduce:**
* Create a **Hungarian** database with **Accounting** or **Invoicing**.
* Set a valid **VAT number** on the company.
* Configure **NAV credentials** in **production mode**. (use credentials from ticket)
* Try to save the Settings.

**Observed behavior:**
* Authentication fails with error: `INVALID_REQUEST: Helytelen kérés!`
* NAV returns schema violation: `Value 'BE477472701-19110' is not facet-valid with respect to pattern '[0-9A-Z\-]{18}' for type 'SoftwareIdType'.`
* The softwareId is only 17 characters instead of required 18.

**Cause:**
* The `version` parameter was removed from the module manifest by this [commit](https://github.com/odoo/odoo/commit/717619571d1297d6b299b7c47b728841bcd81e69#diff-d96ba04bb478d9dcbade7b9bf9f07305d42a38ce7a906f3387879271cde35fecL7)
* This change shortened the module version string used to build the `softwareId`.
* Truncating the value to 18 characters therefore produced a string shorter than required.
* The NAV API requires the `softwareId` to be **exactly 18 characters**.

**Fix:**
* Pad the generated `softwareId` to **18 characters** using `ljust(18, '0')`.
* Ensures the value always complies with NAV schema validation rules.

opw-5902414

Forward-Port-Of: odoo/odoo#247737

**Steps to reproduce:**
* Install `Accounting` and `accounting_peppol` modules.
* Create Belgium company.
* Go to accounting settings and activate PEPPOL under `PEPPOL Electronic Invoicing`.
* Create and post a customer invoice.
* Click **Send & Print**.
* Select only **Email** and click **Send** to generate the PDF.
* Click **Send & Print** again.
* Select only **Peppol** (partner configured for Peppol).
* Click **Send**.

**Observed behavior:**
* The invoice is sent via **Peppol**, but the generated UBL XML does **not** contain the embedded PDF.
* The receiver gets the XML data without the PDF representation.

**Cause:**
* When a PDF already exists on the invoice, the send flow skips the document post-processing step to avoid regenerating it.
* The PDF embedding into the UBL XML relies on this post-processing step.
* Sending via Peppol after emailing the invoice therefore bypasses the PDF embedding logic.

**Fix:**
* When sending via **Peppol**, detect if a PDF already exists on the invoice.
* If so, explicitly post-process the UBL XML to embed the existing PDF before sending.
* Ensures the PDF is always included in Peppol messages, regardless of when it was generated.

opw-5495465

Forward-Port-Of: odoo/odoo#245901

Steps to reproduce:
----------------------------------------
1. Install the Recruitment module
2. Navigate to Recruitment > Applications > All Applications
3. Go to Kanban view
4. Make any application Very High Priority (3 star)
5. Refresh the page

Observation:
----------------------------------------
Applications marked as Very High Priority are not displayed on top, Applicants with higher priority should be displayed first within the same stage.

Issue:
----------------------------------------
The `_order` attribute on the applicant model is declared twice, causing the intended priority-based ordering to be overridden by `sequence`. https://github.com/odoo/odoo/blob/6fed805389d878558e4139b270ee7a70269af767/addons/hr_recruitment/models/hr_applicant.py#L28-L41

Solution:
----------------------------------------
Reorder the fields in the `_order` attribute so that priority is applied before sequence, ensuring higher-priority applicants are shown first

opw-5893371

Forward-Port-Of: odoo/odoo#249712
Forward-Port-Of: odoo/odoo#247779

Currently in saas-19.2 on start of Odoo tim_interface throws an exception and Odoo doesn't start:

```
2026-02-20 14:15:31,683 10276 CRITICAL ? odoo.modules.module: Couldn't load module iot_drivers  2026-02-20 14:15:31,684 10276 ERROR ? odoo.service.server: Failed to load server-wide module `iot_drivers`.  Traceback (most recent call last):
  File "/home/pi/odoo/odoo/service/server.py", line 1554, in load_server_wide_modules     load_openerp_module(m)
    ~~~~~~~~~~~~~~~~~~~^^^
  File "/home/pi/odoo/odoo/modules/module.py", line 488, in load_openerp_module     __import__(qualname)
    ~~~~~~~~~~^^^^^^^^^^
  File "/home/pi/odoo/addons/iot_drivers/__init__.py", line 18, in <module>     interface_thread().start()
    ~~~~~~~~~~~~~~~~^^
  File "/home/pi/odoo/addons/iot_drivers/iot_handlers/interfaces/tim_interface.py", line 61, in __init__     self.tim_api.six_initialize_manager.argtypes = [ctypes.c_int]     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'six_initialize_manager'
```

This is due to a missing 'tim' directory:
```
/home/pi/odoo/addons/iot_drivers/iot_handlers/drivers cp: cannot stat '/home/pi/odoo/addons/iot_drivers/iot_handlers/drivers/tim/libtimapi.so.3.38.0-5308': No such file or directory
```

This PR adds 'tim' directory in unzipping fixing the path


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

Steps to reproduce the issue:
=================================

1. Go to Website > Products and edit a product.
2. In the product description, add a header using the editor.
3. You can now drop an image in that place, so drop it.
4. Click on the image and try to add an anchor for it.

-> Traceback

Cause:
======

The reason an image can be dropped in that location is because the editor
added an adjacent element, such as a `<p>` or `<h1>`, which is considered
a valid drop zone by the drop zone plugin. However, when trying to
create a link, the parent element checks if it is valid to have an
anchor, but then when adding an anchor the element text is undefined,
causing a traceback.

Why can an image be dropped in that location after adding the editor?
The bug was due to passing `excludeNearParent` as a property name instead
of `excludeParent` to the `getSelectorSiblings` function, which always
evaluated to false. So it allowed dropping images in invalid locations.

Solution:
=========
Pass the correct property name.

Impact:
=======
This fix enforces the intended dropzone behavior where content snippets
(like images, buttons with `.o_snippet_drop_in_only`) cannot create
dropzones next to elements that are direct children of `.oe_structure`
containers.

Test Changes Required:
=======================
The button tests were failing after the fix because they were testing
buttons as direct children of
`<div id="wrap" class="oe_structure oe_empty">`. This was only working
before due to the bug - `excludeNearParent` was being ignored.

The fix wraps the test buttons in a `<div>` container,
making them children of a child of `.oe_structure` rather than
direct children.

opw-5489444

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

Forward-Port-Of: odoo/odoo#249707
Forward-Port-Of: odoo/odoo#244324

Currently, a user can add a timesheet entry with a negative Hours Spent 
value `exceeding six digits`.

**Steps to reproduce:**
- Install the `timesheet_grid` module.
- Open the `Timesheets` app and click `Add a line`.
- Set Hours Spent to a `negative` value with more than six digits (e.g., -1000000).

**Observation:**
The line is added without any warning, whereas entering a positive 
value with more than six digits correctly raises an `error`.

**Root cause:**
At [1], the constraint validates only positive values exceeding six digits. 
As a result, negative values with more than six digits are not checked 
and bypass the `UserError validation`.

**Fix:**
This commit updates the constraint to ensure the six-digit limit 
applies to both positive and negative values.

[1]:
https://github.com/odoo/enterprise/blob/660905872909405c0a07a8317b4eb0a42e5854ca/timesheet_grid/models/analytic.py#L46-L49

opw-5909417

Forward-Port-Of: odoo/enterprise#108182
Forward-Port-Of: odoo/enterprise#106781

Before this commit:
If IoT system clock is wrongly set (happened on a Wi-Fi environment with slow connection). The system clock will abruptly change for a date in the future which will trigger all `schedule` jobs (which will think they are several days late).

In addition to this oversight, on an IoT on which "custom IoT handlers" configuration is enabled, if the `upgrade.check_git_branch` job is called on IoT boot, it will trigger the following traceback:
```py
2026-02-17 13:53:41,751 1371 ERROR ? odoo.addons.iot_drivers.exception_logger: Exception in thread Thread-4:
2026-02-17 13:53:41,757 1371 ERROR ? odoo.addons.iot_drivers.exception_logger: Traceback (most recent call last):
2026-02-17 13:53:41,758 1371 ERROR ? odoo.addons.iot_drivers.exception_logger:   File "/usr/lib/python3.13/threading.py", line 1043, in _bootstrap_inner
    self.run()
    ~~~~~~~~^^
2026-02-17 13:53:41,759 1371 ERROR ? odoo.addons.iot_drivers.exception_logger:   File "/home/pi/odoo/addons/iot_drivers/tools/helpers.py", line 50, in run
    service.server.restart()
    ~~~~~~~~~~~~~~~~~~~~~~^^
2026-02-17 13:53:41,759 1371 ERROR ? odoo.addons.iot_drivers.exception_logger:   File "/home/pi/odoo/odoo/service/server.py", line 1622, in restart
    os.kill(server.pid, signal.SIGHUP)
            ^^^^^^^^^^
2026-02-17 13:53:41,759 1371 ERROR ? odoo.addons.iot_drivers.exception_logger: AttributeError: 'NoneType' object has no attribute 'pid'
```
Which will prevent the IoT to restart thus to load custom handlers

After this commit:
Brutal time changes (of 10 minutes (in a 3-second loop)) are detected, and jobs schedules are updated to prevent misfire calls

Forward-Port-Of: odoo/odoo#249112

### Issue:
Due to this issue, `coupon_ids` which are never used are still shown in loyalty coupons history which is confusing for users.

#### Steps to reproduce:
1- Create two promotions:
   - Promo A: 10% discount
   - Promo B: 20% discount

2- Create a SO and add a line. Then confirm the SO.
3- Click on `Reward` button.
4- A dialog should show both promos. Discard the dialog.
5- Navigate to `Discount and Loyalty`.
6- Open Promo A and B and you can see both have lines with
   `coupon_id.order_id` = `created SO` which is confusing. `Issue 1`
7- Navigate back to SO. Click on `Reward` and select Promo A, apply.
8- Navigate to Promo B. As you see the the `coupon_id` related to
   the SO is still there. `Issue 2`

### Cause and Fix:
This is due to unlinking `coupon_ids` only in SO confirm action, causing this issue on already confirmed SOs:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/sale_loyalty/models/sale_order.py#L132-L136

We can fix this issue by `unlinking` the `coupons_ids` when a reward is applied or the dialog is discarded.

However there are 2 limitations:
1- The view needs to be updated. Otherwise, `coupon_ids` will not be deleted upon clicking on `discard` button. However the fix is still stable.
2- What if the dialog is closed with the cross button or the tab is closed without selecting a reward? In that case the issue will still persist.

To fix these issues, we can show only used `coupon_ids` in `loyalty_coupon_id` list view. However that cannot be done in stable as it requires `use_count` to be stored.
NB: With some complex filters this also could be fixed on stable but not worth it.

opw-5424753

Forward-Port-Of: odoo/odoo#245534

Steps to reproduce:
-------------------
1. Enable cash rounding, only for cash payment method
   - Rounding method doesn't matter, I tested with 0.05 nearest rounding
2. In PoS, make an order with the customer account, such that the total amount is not divisible by 0.05, i.e. when rounded, it's not the same amount. For instance, $5.27.
3. Close the session and reopen it, then select that customer, and click settle due
4. Select the Bank payment method, so a NON-Cash payment method.

Notice that the amount is being rounded, even though we have only enable rounding for cash methods. If we take my example of step 2, the amount became $5.25 instead of $5.27.

That is understandable when we settle with Cash, however, for Bank (non-cash), we should not round.

The fix
-------
Now when choosing a payment method to settle due, we also round the amount if needed, in `getTotalDueOfPartner`. Before, we always set the exact amount, regardless of the payment method and the rounding settings.

We now also apply rounding on the payment screen based on the selected payment method. Previously, the change was always rounded whenever rounding was enabled, ignoring whether rounding was restricted to cash methods. This behavior made sense for normal orders—where change is typically given in cash—but not when settling a due amount, since the customer can pay using any method. During due settlement, the change represents the amount the customer must pay, so rounding must follow the rules of the chosen payment method.

opw-5222985

Forward-Port-Of: odoo/enterprise#105368
Forward-Port-Of: odoo/enterprise#100278

## Issue
When generating a batch of serial numbers, an AccessError is raised if the user does not have the *Write* access on the `ir.sequence` model.

## Steps to reproduce
1. Install *Manufacturing* (`mrp`)
2. In Settings, enable *Lots & Serial Numbers*
3. Create a Product P
    - Tracked *By Unique Serial Number*
    - Create a BoM for product P
5. As a user without *Write* access on the `ir.sequence` model:
    - Create and confirm a Manufacturing Order for product P - Quantity >= 2
    - Click *Generate Serial*, *Generate*, *Apply*
6. **An Access Error is displayed, stating that you are not allowed to modify 'Sequence' records.**

## Cause
Commit https://github.com/odoo/odoo/commit/3ff0f2e3ef4f (and https://github.com/odoo/odoo/commit/9cd0c4affeb1) changed the way the serial sequence was updated by replacing `IrSequence.next_by_id()` with manual incrementation (`IrSequence.number_next_actual += 1`). The former method requires read access but does not require write access, whereas the latter does.

https://github.com/odoo/odoo/blob/8f0a5d31d62ea6fc2a1c94be8501735a01323954/odoo/addons/base/models/ir_sequence.py#L272-L275

Since the write access should not be required to generate serial numbers, the sequence is incremented using `sudo()`.

(related to)
opw-5882578

Forward-Port-Of: odoo/odoo#249778
Forward-Port-Of: odoo/odoo#249662

Versions:
---
- 17.0+

Issue:
---
Delivery amount is doubled in stripe express payment checkout.

Steps to reproduce:
---
1- Setup a stripe payment express checkout. (In my client case it is apple pay express checkout but we also reproduced it in google pay)
2- Set fixed price on standard delivery: 10
3- Navigate to website: add a product to cart. Use express checkout.

Outcome: The delivery price is calculated twice which is wrong.

Cause:
---
This regression is due to #238574. Once `/compute_taxes` is called, there is delivery lines included in SO. As a result returning `amount_total` will cause `this.paymentContext['minorAmount']` to include delivery amount.
Then we add delivery carrier `minorAmount`:
https://github.com/odoo/odoo/blob/469220cde82ecebf4a59451cc1325add6bfc3e69/addons/payment_stripe/static/src/js/express_checkout_form.js#L188-L196 Which cause delivery amount be added twice.

Fix:
---
We could exclude delivery amount from total amount in `express_checkout_shipping_address_compute_taxes`, which is going to calculate the tax for lines excluding delivery lines.

opw-5424398

Forward-Port-Of: odoo/odoo#249551
Forward-Port-Of: odoo/odoo#248415

Go to the Planning calendar view and toggle filters such that there is no data displayed. Save the current filters as favorite. Then, reload and switch to the list view.

Before this commit, in **debug mode**, the props validation of the ResourceTag component crashed, because it received `false` as value for the `type` props, which expected a `string`.

The problem comes from the SampleServer, which only knows about the fields of the main model, but not those of co-models reachable from relational fields. In this case, there's a `resource_ids` many2many field on the main model whose relation is `resource.resource`, and there's a `type` selection field on that model. That field is required, so the code only expected `string` values, not `false`. But as the SampleModel doesn't know about that `type` field, it generates `false` as value.

Ideally, the SampleModel should know about the whole field specs (main model + relations). However, even though that would be quite easily doable for kanban and list views (unity specs), it wouldn't be the case for the other views (the SampleServer is shared between all views using sample data). So it would require non trivial architectural changes to make this work.

For that reasons, we went for the easy fix, which is to adapt the props definition to support `false`, as the value was actually already correctly handled by the Component itself.

runbot error~239951

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

This commit improves the drag and drop functionality by detecting
the closest elements when dragging. The previous implementation
only calculated distance when the cursor was outside the
rectangle, returning 0 for any position inside. This caused
issues with nested dropdowns: when a small dropdown is inside a
larger one, the quadrance of the larger one would be 0, but since
for the smaller one it is actually harder to place it perfectly inside,
the distance would be non-zero, so the larger one would be preferred.

The new implementation:
- Handles rectangle-to-rectangle overlap detection using center
  distances
- For non overlapping rectangles, returns correct quadrance
- Returns negative normalized overlap ratio for overlapping
  elements, preferring smaller elements with similar overlap
  percentages
- Supports both point queries (x, y) and rectangle queries
  (x, y, width, height)

Steps to see the issue:
- Open Website and start editing
- Drop the `s_banner` snippet
- Try to drop a button (or any other inner element) next to the
existing button in the snippet
=> The experience is not the most user-friendly

Old implementation:

https://github.com/user-attachments/assets/507c0402-b855-46a7-938d-8f05d905dd3e

New implementation:

https://github.com/user-attachments/assets/34b352b4-e08a-4a7f-a2b5-2702ee8e63ef

It might not look like an improvement in the video, but it feels actually easier now when trying to drag and drop to a relatively small dropzone.

task-5794898

## Issue
In the Planning app, users within the *Planning / User* groups could not take open shifts. The button *"I Take It"* would not be displayed when clicking on the shift.

## Steps to reproduce
1. Install the *Planning* (`planning`) app
2. In the Planning app, as an admin, create and publish an open shift
3. Log in as a *User*, open the *Planning* app, and click on the open shift
4. **The _"I Take It"_ button is not displayed**

When logging in as a user who is **not** part of the *Planning / User* group, the *I Take It* button is displayed.

## Cause

The condition for the *I Take It* button to be displayed is the following:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L282-L283

The condition that makes the button invisible is `not context.get('my_planning_action')`. When the user is part of *Planning / User*, the schedule they see when opening the *Planning* app is the *"Schedule by Resource"*, which has the following context:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L716

When a user who **is not** part of the *Plannig / User* group opens the *Planning* app, they see their own schedule, where the context is different than in the first case:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L636

Because the `my_planning_action` property is in the context (and all the other conditions are respected), the button is displayed.

opw-5451282

Forward-Port-Of: odoo/enterprise#104919

According to the Mexican Social Security Law, when an employee's total monthly earnings (including bonuses and commissions) are equal to or less than the monthly minimum wage (l10n_mx_daily_min_wage * 365 / 12), they are exempt from social security contributions and income tax, also they lost the subsidy benefit.

- The next rules are zeroed out when the gross salary is equal or less  than the minimum wage:
  - IMSS_EMPLOYEE: IMSS Total (Employee)
  - ISR: ISR (Income Tax)
  - SUBSIDY: Used Subsidy
- IMSS_EMPLOYEE and ISR are omitted from the generated XML.
- As the ISR is zero, the `totalDeducciones` attribute on the `nomina12:Nomina` node should be removed.
- The SUBSIDY should be present in the `SubsidioCausado` attribute on the `nomina12:SubsidioAlEmpleo` node, but the `Importe` attribute on the `nomina12:OtroPago` node should be 0.0.

This change requires updates to existing standard tests, as some previous test cases used amounts lower than the minimum wage.

target: 19.0
task-5226971

Forward-Port-Of: odoo/enterprise#107712
Forward-Port-Of: odoo/enterprise#104668

**Issue:**
Loading the shop page was slow due to excessive forced reflows. When a reflow occurs, the browser can't reuse the layout computed so far, and it's forced recalculate it again.

**Cause:**
In `updateVariantPreview`, the init loop wrote to the DOM (textContent, classList) then immediately read `offsetWidth` in the same iteration, forcing the browser to flush and recalculate layout once per product.
This PR tackles the 2 areas of improvement identified:
1. Reduce reflows **number**.
2. Reduce reflows performance **cost**.

[task-5177358](https://www.odoo.com/web#id=5177358&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form)

---

###  1: Reduce reflows **number**.

**Before this PR:**
Phase 1 was a single loop mixing writes and reads, triggering N layout recalculations for N products on the page.

| Performance Tab:  CSS selectors & Advanced paint instr. active (slow) |
|--------|
| <img width="1847" height="650" alt="image" src="https://github.com/user-attachments/assets/91e86e91-1209-4865-bcbd-336f792664ed" /> | 
| Timing inflated by the debug environment | 

**After this PR**
Phase 1 is split into two sub-loops. All writes first (1a) and all reads after (1b). So the browser flushes layout only once, regardless of product count, matching the batching pattern already used in phases 2 and 3.

| Performance Tab:  CSS selectors & Advanced paint instr. active (slow) |
|--------|
| <img width="1380" height="555" alt="image" src="https://github.com/user-attachments/assets/c0fefe32-d309-4fc8-a945-1a5f5c12b86e" /> | 
| Timing inflated by the debug environment | 


**Performance results**
In a page with 21 products, 11 of which with variants, the number of reflows dropped from 12 to just 2, resulting on a 82% faster rendering, roughly a 5.5X speedup.

---

###  2: Reduce reflows performance **cost**.

Reflows cannot be entirely avoided, but side-effects can be mitigated in CSS by instructing the browser how to react when this circumstance occurs. This PR add two rules to the products card:

1. `contain`: Tells the browser each product card is a layout containment boundary and inner changes "should not" affect elements outside.
2. `content-visibility`: Tells the browser to try skipping cards outside the viewport. Their layout will be eventually evaluated when cards scroll into view.

**Performance result:**
In a page with 21 products, 11 of which with variants, the performance cost of a single reflow dropped by 22%.

_note: the browser is not obliged to honor these "suggestion" and may behave differently depending by the viewport size, the content and the browser itself._




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

Forward-Port-Of: odoo/odoo#249324

Users with the project_manager role and no access on sale cannot open stock moves

Steps to reproduce:
1. Install Sales, Inventory and Project
2. Create a Sale order for any company with an address and any product and confirm it (a delivery should be automatically created)
3. Go to Settings > Users and open user Marc Demo
4. Set Marc Demo's role on Sales to "No" and on Project to "Administrator"
5. Log in as Marc Demo
6. Go to Inventory > Operations > Deliveries and try to access the delivery previously created
7. An error occurs

Problem:
https://github.com/odoo/odoo/blob/6b2d3af64a076654e04494972acc4c42d7c54bd8/addons/sale_stock/models/stock.py#L32-L38
stock.move's description is computed based on the related sale order lines which will cause an access error because users with role `project.group_project_manager` can only access sale order lines of projects or tasks because of this rule:
https://github.com/odoo/odoo/blob/3909bef741ebb5c879beb383c395e1a310ba78eb/addons/sale_project/security/sale_project_security.xml#L4-L13
even though the group `stock.group_stock_user` are expected to always have read access to sale order lines because of this right:
https://github.com/odoo/odoo/blob/3909bef741ebb5c879beb383c395e1a310ba78eb/addons/sale_stock/security/ir.model.access.csv#L6

Note that the issue doesn't happen when the user is a sale user because of this rule that adds the rights on sale order lines:
https://github.com/odoo/odoo/blob/3909bef741ebb5c879beb383c395e1a310ba78eb/addons/sale/security/ir_rules.xml#L78-L83

This fix also solves the issue for `mrp.group_mrp_user` because they inherit the group `stock.group_stock_user`:
https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/mrp/security/mrp_security.xml#L11-L16

Therefore the rule on `project.group_project_manager` needs to be
overridden when the user is a stock user

Solution:
Create a record rule with a truthy domain to force stock users to have access to sale order lines even if other rules remove this access

opw-5492232

Forward-Port-Of: odoo/odoo#247529

### Steps to reproduce:
- Download Rental and eCommerce apps.
- Install an RTL language (e.g., Arabic) on the website.
- Create a rental and go to website.
- Try to pick a date for the rental.

### Issue:
When the website is viewed in an RTL language, the navigation arrows of the date picker are displayed in the wrong direction. This happens because the date picker is not inside `o_rtl` component, but inside `o-main-components-container` component. So, when `o_rtl` is called in css (for example):
https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/web/static/lib/odoo_ui_icons/style.css#L67-L76
Since the arrows are not inside `o_rtl`, the transformation doesn't apply to them.

### Solution:
The `o_rtl` class has been appended to `o-main-components-container` class in case of a RTL language, so that had the css file contain rules for `o_rtl`, they would be applied automatically.

opw-5498615

Forward-Port-Of: odoo/odoo#249541
Forward-Port-Of: odoo/odoo#246190

### Steps to reproduce:
- Download MRP app.
- Create a product and its corresponding BOM (including at least a single operation)
- Create and confirm a manufacturing order for 1 unit of that product
- Click on the Shop Floor smart button > Click on the header of the MO
- The MO filter applied on the shopfloor search bar is removed

### Issue:
The MO search filter is removed after you click the header of the workorder order. This bug was introduced by another commit https://github.com/odoo/enterprise/pull/94584/changes/c83ab24a8d037a339db8067c7e9794cba5c16eab to remove the filter when a workorder's barcode is scanned. Hence, https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L289-L292
the change resulted in the filter being removed every time the header is clicked. In the case where a user clicks to start the workorder, we need to keep the filter.

### Fix:
Based on https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display_record.xml#L6-L8 `onClickHeader()` is called every time a shopfloor record is clicked, which (based on the reference in the previous section) removes the filter, then calls `startWorking()`. By removing `this.env.searchModel.removeMOFilter()` from this method, it's ensured that clicks preserve the user's current search context.
For https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display.js#L248-L250 since the original workflow of removing the filter in case of a barcode scan should be kept, moving `removeMOFilter()` call here with the appropriate reference of `workorder.component.env.searchModel`matches the expected behaviour.

opw-5877418

Forward-Port-Of: odoo/enterprise#107121

Before this commit, live chat visitors in mobile could not add a message reaction due to visual glitch.

This happens because there's an override in livechat to show 3 quick message actions rather than 4, and this patch also applies in mobile where there's only 1 with the "..." button.

The "Add reaction" message action in mobile, when shown as a quick action, is buggy: click on it glitches the visual of message in a way that disrupt the viewing of message... And this doesn't show the emoji picker.

This commit fixes the issue by removing the override of quick action count of live chat visitors. This overrides was added a long time ago when the "Add reaction" and "View reactions" had the same icon, and playing with the amount of quick actions was a way to avoid showing these 2 actions as quick actions with similar icons [1].

Also quick actions in chat window has been tweaked to show 2 actions at most in desktop, which is the best presentation in chat window. Removal of the override let it use this better quick action count.

[1]: https://github.com/odoo/odoo/pull/140335

Task-5953287

Before / After
<img width="399" height="767" alt="Screenshot 2026-02-19 at 17 41 21" src="https://github.com/user-attachments/assets/4f1fb8e7-fa0b-4c8c-8f41-552432224064" /> <img width="401" height="771" alt="Screenshot 2026-02-19 at 17 56 20" src="https://github.com/user-attachments/assets/5aadc9df-d858-49ec-b894-d2c424396f54" />

Forward-Port-Of: odoo/odoo#249776
Forward-Port-Of: odoo/odoo#249550

Before this commit: when formatting partially a link, the link is split
at the selection and formatted. This causes duplicated links.

After this commit: we consider links are unsplittable, thus formatting
on links will wrap the selected part in a <font> tag.


commit 2: 
[FIX] html_editor: solve infinite loop of links with color class
Before this commit: we have a fix https://github.com/odoo/odoo/commit/96bc421d30f34a8bfc10dde93c2f283809a8a3e3
which to be able to remove the style classes in the link element

After this commit: We don't consider the style class in the link element
as `hasColor`, because the style classes come from the template code,
which is hard-coded xml. Removing them, the user won't be able to add it
back. For example, on a product page, edit the `Terms and conditions`
link, do nothing and save, the muted color is forced removed.

Note that another fix https://github.com/odoo/odoo/commit/f5fc55f19f89041c8391ff81b127ffce0898f89f is also
removed cause it was a fix for https://github.com/odoo/odoo/commit/96bc421d30f34a8bfc10dde93c2f283809a8a3e3.
The tests belonging to https://github.com/odoo/odoo/commit/96bc421d30f34a8bfc10dde93c2f283809a8a3e3 are
adapted, and those of https://github.com/odoo/odoo/commit/f5fc55f19f89041c8391ff81b127ffce0898f89f are kept
as future safeguards of list coloring.


commit 3:
[FIX] html_editor: extra check on targetnode when splitting blocks
Before this commit: we only check if the current block to be split is
splittable, but not the target node.

After this commit: if the current block is splittable but the current
target node is not, we won't split the block but insert a <br>


commit 4:
[FIX] html_editor: properly fill inlineAncestors when formatting
Before this commit: when the parent node of the current node is
unsplittable, the `inlineAncestors` stays empty.

After this commit: we handle this case and push the parent node in the
list when the parent node is fully selected. We also add a fully
selected predicate in link_plugin for the case when the selection
includes all the content (except for zws) of a non-button link


task-5244810


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

Forward-Port-Of: odoo/odoo#249470
Forward-Port-Of: odoo/odoo#241871

The channel invitation has a new feature to generate a new link.

Before this commit, this was placed as an icon button next to the copy clipboard. While this looks like a good placement at first, there is some UX issues: this doesn't feel as natural as before to copy link in clipboard.

This happens because the save to clipboard was the last item, therefore it felt extremely easy to just click on it. With the new button, the generate new link is at the end, and so we are more prone to click on the renew link button than the save to clipboard. Even with the primary button, the placement of save to clipboard requires more precision than we'd expect from such a heavily used button.

This commit fixes the issue by moving the "Generate a new link" below, with the "Access restricted to" text. Justifications are:
- Other positions next to input felt off, whether swap order with save to clipboard or renew button as prefix of input.
- This button is niche, so being below matches more the niche usage of the feature.
- Overall UI of channel invitation feels more balanced.
- Moving to bottom allows to put plain text on button, making it clearer what this button means.

Before / After
<img width="626" height="243" alt="Screenshot 2026-02-23 at 15 42 46" src="https://github.com/user-attachments/assets/01bbf9b6-6fda-4981-8191-a09598e98af8" /> <img width="618" height="251" alt="Screenshot 2026-02-23 at 15 42 25" src="https://github.com/user-attachments/assets/21a797c7-c61e-404f-afe0-fcb4eefe177e" />

When prepating initial value to track value changes, do it as sudo. Indeed user access rights should not prevent from checking tracking.

Use case: hr employee update triggers an update on version records. On version model sign requests are tracked, but their access is limited to sign members. Tracking should not crash at that point.

When finalizing, "new" value of tracking is also computed as sudo. We hence ensure that all values (pre and post) are computed the same way and independently from implemented ACLs.

Reproduce steps: run 'test_employee_deletion'. It was not visible before adding a manual flush, as cr was still in "no tracking" mode (precommit data kept from creation in setupclass).

Task-5935695 ([mail, various] Cleanup and test tracking usage) Prepares Task-3645865 ([mail] In-body tracking)

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

**Issue:**

Non-admin users get an AccessError as follows

```doesn't have 'create' access to: - Default Values, Based on (Purchase Order Suggest) (ir.default: 45)... ```

when using the Purchase Order Suggest wizard.

**Cause:**

The `ir_default_user_rule` record rule restricts non-admin users to only create/modify ir.default records where
  `user_id = user.id`

However,  in  `_save_values_for_vendor` method:

https://github.com/odoo/odoo/blob/6b8a8196c63275eead6709bb20002df0be12a059/addons/purchase_stock/wizard/purchase_order_suggest.py#L199-L204

 `ir.default.set()`  is called without setting the `user_id` parameter, which defaults to an attempt to create a global default: what only admins can do.

**Steps to reproduce:**

- create a non-admin user with purchase user permissions.
- log  in as that user and create a Purchase Order
- add products to the catalog and click "Suggest.
- configure suggest parameters and click "Compute" (Note: compute is only enabled when estimated_price > 0)

An AccessError occurs

opw-5076647

Forward-Port-Of: odoo/odoo#236743
Forward-Port-Of: odoo/odoo#227643

In [1], a refactoring of the POS framework was done, but in the process some overlooked behaviors induced a complete loss of the answers given in the registration process, as long as they do not include an answer to a 'selection' question.

STEPS
=====

0. Create a new event with a few questions (no 'selection' one)
1. Add tickets so that you can buy one in the POS
2. Go in the POS (reload data if needed)
3. Buy a ticket and fill the attendee form (answer to all questions)
4. Continue the POS flow and pay for your ticket.
5. Go back to the back-end and event > attendees
6. Check your new attendee: no answers are linked to the record.

ISSUE
=====

TLDR - Two fields have the same comodel on event.registration. This breaks the use of inverseMap as both are loaded in the pos. As they are treated sequentially when connecting related records, hidden side effects occur when both are not set.

Details:

This effect is due to two main issues. First, after [1], we compute the whole model reference relations using processModelDefs method, that accounts for inverse relations of o2m, m2o fields and provides an inverseMap to be used in several places, notably on creation or deletion of relational records from the POS.

However, pos_event presents a peculiar situation, as registrations have two o2m fields, both loaded in _load_pos_data_fields, that are linked to the model event.registration.answer: registration_answer_ids and registration_answer_choice_ids, a subset of the first, just with a domain to only include answers of 'selection' questions.

Meaning that the inverseMap will only use one of the two, in this case registration_answer_choice_ids. In turn, this means that any update of registration_id on the answer model will update that field, even if the original update was done on registration_answer_ids...

Secondly, one could notice that this should still work, as the inverseMap is used in all places, we should just update the records through the field registration_answer_choice_ids.

So why does it not work and why are all answers removed? Because both fields are loaded in _load_pos_data_fields, and in _sanitazeRawData we use getFields to know which fields to update and to connect (for relations on the model), both being returned.

This means that independantly of the create values for the registration in addProductToOrder in pos_event, the 'framework' will still have two fields to connect and will do so sequentially, one field at the time.

But in the _connect logic, if a field has no value given at creation, then the 'CLEAR' command is used, as this would mean we remove the content of the relational field. But in this case, this means that as both answer fields try to update registration_id through registration_answer_choice_ids, if no value is given at creation in that field, then we clear existing ones, for instance those we just linked through the creation values in the first field registration_answer_ids, as we basically empty registration_id on those records. The answers will also be deleted of the indexedDB because of the condition in databaseTable (no linked registration -> can be removed)

FIX
===

Remove registration_answer_choice_ids from the loaded data, as it is not used anywhere except in the registration creation values. As it is a subset of the other field registration_answer_ids, only keep that one instead. Update the creation values to only use that field.

Note that this seems to highlight a limitation when it comes to having more than one o2m field on a model loaded at the same time in POS.

[1] odoo/odoo@a80a39f2ad16baf474553574c79d55948f86c453

Task-4919080

Forward-Port-Of: odoo/odoo#231293

Steps to reproduce:

- Open the website editor.
- Add a carousel snippet to a page.
- Remove content from the first slide so it is shorter.
- Save the carousel as a custom snippet.
- Open the snippet dialog and locate the custom snippet. => The preview height is too small.

Before this commit, the preview height was computed from the scaled size, so shorter slides made the preview min-height too low.

After this commit, the preview height uses the layout size so the min-height stays consistent with other slides.

----------

Steps to reproduce:
- Open the website editor.
- Open the snippet dialog and resize the window.
=> The parallax preview background shifts to the left.
- Save a snippet with a parallax zoom in/out effect as a custom snippet.
- Open the snippet dialog and locate the custom snippet.
=> The preview shows a top to bottom effect instead of zoom.

Before this commit, resizing the snippet dialog could offset the
parallax background to the left, and zoom previews looked like top to
bottom effects.

After this commit, the preview keeps the background aligned and shows
zoom in/out effects for custom snippets.

Fixed parallax is still not previewed because it would require an
oversized background in the dialog.

----------

Steps to reproduce:

- Open the website editor.
- Save a "Carousel" snippet as a custom snippet.
- Open the snippet dialog.
=> The custom snippet shows no label.

Before this commit, custom previews dropped the base label so the dialog
showed no tag for custom snippets.

After this commit, custom previews reuse the base label.

task-5156137

**To see/test the bug, the change made in https://github.com/odoo/odoo/pull/244251 must be present**

Forward-Port-Of: odoo/odoo#249163
Forward-Port-Of: odoo/odoo#244295

An improvement in September (PR #95207) began removing accents from names in documents sent to the SAT, in order to comply with their own practices.

In recent months, it has become clear that the SAT does accept accents sometimes. First with umlauts on the `ü` in October (PR #96043), then all umlauts in February (PR #106557). As this PR has found another accepted accented character `É`, it may be necessary to undo the original improvment entirely.

The [Anexo 20 Guía de llenado de los comprobantes fiscales digitales por Internet](http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Anexo_20_Guia_de_llenado_CFDI.pdf), pg 17, indicates that accented characters are maintained in legal names. At least, `Í` is allowed. At this point in time I only added the exception for `É`.

Steps to reproduce are [on the ticket](https://www.odoo.com/mail/message/999357619), as it requires a real person's tax information.

[opw-5915515](https://www.odoo.com/odoo/project.task/5915515)

----
*Edit: Miguel (mial) confirmed that names are not always sanitized, but that we expect them to be.*

Forward-Port-Of: odoo/enterprise#107677

Steps to produce:
---
- Install sales module.
- Go to Settings and enable Pricelists (make sure we have 2 pricelists
  so that we able to change the pricelist value in quotation).
- Create a new quotation > Add a customer and product.
- Change the pricelist.
- Save the record.

Issue:
---
- After saving the quotation, the `Update Prices` button becomes invisible.

Root cause:
---
- The field `show_update_pricelist`, which controls the visibility of the button, is not present in the view. As a result, when the record is saved, the field is not included in the form data and its value is not properly maintained, causing the button to become invisible.
- The field is removed from the view in this [commit].

Solution:
---
- Added the `show_update_pricelist` field to the view to ensure its value is properly maintained. This allows the `Update Prices` button to remain visible when applicable.

[commit]: https://github.com/odoo/odoo/commit/da4b588b272432095f549c012e0a0d7238f00dc0

**Enterprice PR:** https://github.com/odoo/enterprise/pull/107621

opw-5927659

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

Forward-Port-Of: odoo/odoo#249881
Forward-Port-Of: odoo/odoo#248957

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

**Steps to reproduce:**
* Install the **Accounting** module.
* Create a product category hierarchy (grandparent → parent → child).
* Set an **income account** on the grandparent category.
* Set an **expense account** on the child category.
* Leave the parent category without any accounts.
* Create a product assigned to the child category.
* Create a customer invoice using this product.

**Observed behavior:**
* The invoice line uses the **default income account** from settings instead of the grandparent category’s income account.
* The category hierarchy is not checked to retrieve parent accounts.

**Expected behavior:**
* If no account is defined on a category, Odoo should traverse the **parent categories** to find one.
* Only if no account exists in the hierarchy should it fall back to journal or default accounts.

**Cause:**
* Account lookup only checked the **immediate category**.
* Parent categories were not considered.

**Fix:**
* Traverse the product category hierarchy when searching for accounts.
* Use the first account found in the parent chain.

opw-5869592

Forward-Port-Of: odoo/odoo#249909
Forward-Port-Of: odoo/odoo#248389