**Steps to Reproduce**

* Install `sale_management`, `purchase`, and `stock` with demo data.
* In Inventory → Settings, enable `Dropshipping`.
* Create a product: 
     * Set a vendor under the Purchase tab. 
     * Set routes to `Dropshipping` and `Buy`
* Create and confirm a sale order for this product.
* Confirm the generated purchase order.
* Cancel the originating sale order.
* Go back to the linked purchase order.

**Observed behavior**

* Two activities are created on the purchase order when the sale order is cancelled.

**Cause**

* Both templates — `exception_on_so` (from sale_stock) and
`exception_purchase_on_sale_cancellation` (from sale_purchase) 
are triggered during sale order cancellation.

* Each module overrides `_action_cancel` and triggers its corresponding exception template.

* When both modules are installed, both templates run.

https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/sale_purchase/models/sale_order.py#L26-L32

https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/sale_stock/models/sale_order.py#L206-L208

* The template `exception_purchase_on_sale_cancellation` should only be triggered
when the PO originates from an SO and the product is a service, but
the domain lacks the required product-type condition.

**Fix**

* Add the missing condition to ensure that `exception_purchase_on_sale_cancellation`
is not triggered for dropshipped products, preventing duplicate activities.

---
`NOTE` - This issue is resolved from version 19.0 in this [commit](https://github.com/odoo/odoo/pull/212679/changes/ede2898278220a3ba4d8910ef268fe59f1587c72)

---
opw-5153488

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

Forward-Port-Of: odoo/odoo#239569

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

**Issues:**
1. Order deleted from backend When a self-order is deleted from the backend, the customer self-order UI is not updated, causing the “Order Now” button to be missing.

2. Order sent and paid from POS UI Steps:
    - Create a self-order from mobile
    - Load the order in the POS UI
    - Add additional items (eligible for preparation)
    - Proceed to payment and validate
    - Click Order in the Send for preparation popup Problem: After order validation, the customer self-order UI is not refreshed and the “Order Now” button does not reappear.

**Fixes:**
 - Ensures order deletion triggers notify calls to refresh both POS and self-order UIs
 - Synchronize deleted orders with the customer self-order UI
 - Fix the case where setting Service at = `Table` and Pay after = `Meal` in a single operation resets Pay after to `each`.

Task-5373116

Related: https://github.com/odoo/enterprise/pull/103052

Forward-Port-Of: odoo/odoo#248844
Forward-Port-Of: odoo/odoo#240523

Steps to reproduce:
===================

1. In Website > Shop, open any product.
2. Click "Edit" on the product.
3. Make a change (for example, toggle "Zoom on click") 2 times.

-> In the second time a traceback will appear `(Safari, Epiphany)`.

Cause:
======

The website builder uses two contexts:
- The **iframe** runs services (e.g. websiteEditService)
- The **parent window** runs editor plugins (e.g. EditInteractionPlugin)

They communicate via custom events on window.parent.document. The service (in the iframe) registers a listener for
"edit_interaction_plugin_loaded" on the parent document, and responds with a "transfer_website_edit_service" event carrying its service object.

When the iframe reloads after a save, the old listener was never removed from window.parent.document. The new iframe added a second listener. This meant two listeners existed on the parent document:

  1. Old listener → responds with OLD websiteEditService (stale)
  2. New listener → responds with NEW websiteEditService (correct)

Both fire when the plugin dispatches "edit_interaction_plugin_loaded". But the plugin only accepts the first response ({ once: true }), and since listeners fire in registration order, it always received the OLD stale service.

With the stale service:
- installPatches() early-returned (patches.length > 0 from session 1)
- destroy() called uninstallPatches() on the old service, removing stopInteractionByName from the old prototype
- stopInteraction() then tried to call the now-deleted method → crash: TypeError: publicInteractions.stopInteractionByName is not a function

Solution:
=========

Extract the anonymous event handlers into named functions and register a "beforeunload" listener on the iframe's window that removes them from window.parent.document. This ensures that when the iframe reloads, the old listeners are cleaned up before the new iframe registers its own, so the plugin always receives the current service.

opw-5864798

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

Forward-Port-Of: odoo/odoo#248042

**Description of the issue/feature this PR addresses:**
----------------------------------------------
When multiple messages are pinned, repeatedly right-clicking different
messages in the pinned messages panel can open multiple context dropdowns
simultaneously. This may lead to UI inconsistencies and potential crashes.

**Current behavior before PR:**
----------------------------------------------
- Multiple pinned messages can be right-clicked consecutively
- Each right-click may open an additional dropdown menu
- Duplicate dropdowns can remain visible at the same time
- This can cause unstable or inconsistent UI behavior

**Desired behavior after PR is merged:**
----------------------------------------------
- Only one dropdown menu is displayed at a time in the pinned messages panel
- Repeated right-clicks properly reuse or replace the existing dropdown
- Prevents duplicate dropdowns and avoids potential UI crashes

Task-5935503

----------------------------------------------

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

*mrp,purchase_mrp,stock

Issue
-----
MTO gets suggested by default as the replenishment route for products.

Steps to reproduce
-----
- Enable routes
- Unarchive MTO
- Create a product with a vendor and MTO route
- Open the replenishment wizard

> The default/suggested replenishment route is MTO

Cause
-----
When creating the widget, we go through its' `default_get` to set its' default route

https://github.com/odoo/odoo/blob/310897cf07ebbf484ea6877fb329215e45c481d7/addons/stock/wizard/product_replenish.py#L76-L77

the domain is computed by `_get_route_domain`, which in turn calls `_get_allowed_route_domain`

https://github.com/odoo/odoo/blob/310897cf07ebbf484ea6877fb329215e45c481d7/addons/stock/wizard/product_replenish.py#L165-L170

However, since we are creating a new, it does not have a `warehouse_id` yet, so we don't go into the `if` condition.

https://github.com/odoo/odoo/blob/310897cf07ebbf484ea6877fb329215e45c481d7/addons/stock/models/stock_replenish_mixin.py#L26-L39

We only get routes from the product, but since buy is set on the warehouse and not the product anymore, it doesn't get included.

Solution
-----
There is an override of `_get_route_domain` in `purchase_stock`

https://github.com/odoo/odoo/blob/310897cf07ebbf484ea6877fb329215e45c481d7/addons/purchase_stock/wizard/product_replenish.py#L91-L96

it filters out the buy route if there is no `seller_ids` for the product, but since the buy route cannot be a part of the domain anymore, the condition should be changed to include buy if the product has a seller.

Note: `_get_route_domain` is only ever called in `default_get`.

Other changes
-----
The same change is also applied for the manufacture route, as the logic is the same.

It makes no sens to include route that do not lead to an internal location.

-----
Ticket:
opw-5388728

Forward-Port-Of: odoo/odoo#246304

Steps to reproduce the bug:
- Create an attribute "Test":
  - Display type: Radio
  - Attribute values: X1 and X2
  - Variant creation: Dynamically

- Create a storable product "P1":
  - Attribute & variants: add X1 and X2
  - Add any vendor
  - Route: MTO

- Create a sale order with one unit of P1-X1
  - Confirm it -> the purchase order is created

- Create a second sale order with one unit of P1-X2
  - Confirm it -> the purchase order is not created

Problem:
When the Buy route is triggered, a check whether a vendor is linked to the product variant being used. However, since "product.supplierinfo" is linked to the template and also to the first variant (P1-X1), no supplier is found for the other variants, so no PO is created.

https://github.com/odoo/odoo/blob/60993a956f127af5bf988b056f9df948a5437d8b/addons/purchase_stock/models/stock_rule.py#L52-L55

https://github.com/odoo/odoo/blob/4759c5f1649b2a9bd3378b6e29cd2b806e86ea37/addons/product/models/product_supplierinfo.py#L113-L114

Solution:
When the number of variants changes for a product template, the compute of product_id in the model product.supplierinfo is triggered. In this case, product_id must be set to False when multiple variants are linked to the product template.

opw-5871195

Forward-Port-Of: odoo/odoo#248656

Issues:

- Single-day time off requests appear as multi-day events in the Calendar app when using certain times
- Full day time offs were not appearing as `allday` events in the calendar (bar over the days instead
of a block representing the hours) if the time off type had a request unit of half-days.

Causes:

The `_compute_date_from_to()` method converts user-specified dates to UTC.
https://github.com/odoo/odoo/blob/028e7228cb830e47a9726bef4c82793ba4590cd5/addons/hr_holidays/models/hr_leave.py#L316-L317
 The `_prepare_holidays_meeting_values()` method then uses these UTC datetime values (`holiday.date_from`, `holiday.date_to`)

In Los Angeles timezone, and for a one day leave on september 17 2025 this leads to:

- holiday.date_from: September 17, 2025 at 03:00 UTC
- holiday.date_to: September 18, 2025 at 12:00 UTC

causing a single-day leave to be displayed as a two-day event.

- The cause of the second issue was relying on `leave_type_request_unit`
which is a simple related to the leave's type unit which doesn't consider
cases where the time off duration could be longer than the minimal request
duration.

After fix:

- start_value: September 17, 2025 at 12:00
- stop_value: September 17, 2025 at 11:59

Steps to Reproduce:

1. Set the user timezone to "America/Los_Angeles"
2. Set the browser timezone to the same timezone
3. Create a one-day time off request (e.g., September 17, 2025)
4. Open the Calendar app: the event spans across two days

opw-4744817

Bug reproduction: When version >= 19.0, install Kenya payroll and accounting, create payslip for one of the Kenyan employee -> validate the payslip -> Reporting: P9 Report in payroll app -> Create new tax deduction card -> populate employees -> in the inside of the card: select employees and click to generate pdf -> it will not be generated 

Bug cause:
    1 - In cron parameters, context passed wrongly, it should take place in the clickable parameters
    2 - After saas-18.4 in the migration, employee.l10n_ke_pin field is removed but this field still takes place in l10n_ke_tax_reduction_card_templates.xml and it gets error when the user clicks to generate PDF.

Bug solution:
    1 - Fixing cron parameter passing
    2 - Removing PIN of employee field from P9 report since it is not available anymore.

Testing: Unit test is written to check PDF's are generated for sure.
    1 - Creating Kenya company, employees
    2 - Creating payslip for employees and validate them
    3 - Creating tax deduction card and generate declarations
    4 - Checking PDF's are created

task - 5395267

Forward-Port-Of: odoo/enterprise#104816

Steps to reproduce:
-------------------
1. Install l10n_ch_hr_payroll.
2. Switch to a Swiss company and create a new employee.
3. Create a new internal user with Payroll Officer/Manager access.
4. Log in as that user, create a contract, and click on "One-time payments".

Issue:
---------
A Traceback with AccessError:
```You are not allowed to access 'Action Window' (ir.actions.act_window) records.```

Cause:
----------
https://github.com/odoo/enterprise/blob/9e39b4b85fcb9f6ed5b21b942796b76b8a6eefdb/l10n_ch_hr_payroll_elm_transmission/models/hr_contract.py#L195
The code attempts to call `.read()` on an `ir.actions.act_window` record.
Standard users typically do not have read access to window action records,
resulting in an **AccessError** even if they have rights to the payroll data.

Solution:
-------------
Use [_for_xml_id](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L187) to return action content for the provided xml id
in a safe way by doing [sudo](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L205) internally to bypass the access restriction.

opw-5491467

Forward-Port-Of: odoo/enterprise#106598

Steps to produce:
---
- Install `accountant` and `l10n_mx` modules.
- Switch to Mexican company.
- In Settings, under `Authorized Certification Provider (PAC)`, set PAC to `Solución Factible`.
- Create new invoice > set customer to `INMOBILIARIA CVA`, payment way to `Efectivo` and product as `Large Meeting table` > confirm the invoice.
- Mark the invoice as global.
- Register the payment.
- Create a credit note and confirm it.
- Click Send(make sure CFDI is checked) and check the generated XML.

Issue:
---
- The CFDI XML sets the `Descripcion` field to the default value `Devoluciones, descuentos o bonificaciones`.

Solution:
---
- Preserve the original line description for CFDI refunds instead of forcing
  the generic label.
- For POS refunds, continue using the generic label.
- This aligns with the fix introduced in 19.0([here]).

Before:
---
<img width="519" height="60" alt="image" src="https://github.com/user-attachments/assets/75066bdb-5fba-4959-bf16-8b2953bc40d5" />

After:
---
<img width="615" height="56" alt="image" src="https://github.com/user-attachments/assets/bd93d0af-957f-47fc-b65c-3ec16c4b8f10" />



[here]: https://github.com/odoo/enterprise/pull/97681/changes/515410ec45541e6c07f892a094bb0aa57f479436
**Backport of https://github.com/odoo/enterprise/pull/97681**

opw-5870052
---

Forward-Port-Of: odoo/enterprise#107739
Forward-Port-Of: odoo/enterprise#107367

Currently, it is possible to set a DateV identifier on a partner even if it is already assigned to an archived partner. This leads to duplicate identifiers if the archived partner is later unarchived.

###  **Steps to reproduce:**
1) Install **l10n_de_reports, Contacts** App with Demo Data. 
2) Switch to a **DE company**.
3) Create a contact 'Test-A' and set `'DateV Vendor' to 123456789` in the **Accounting Section**. 
4) Archive 'Test-A'.
5) Create 'Test-B' and set `'DateV Vendor' to 123456789`. 
6) Unarchive 'Test-A'.

### **Observed Behavior:**
'Test-B' is created successfully. After step 6, both 'Test-A' and 'Test-B' are active with the same DateV identifier.

### **Expected Behavior:**
A validation error should be raised when trying to save 'Test-B', stating that the identifier is already defined.

### **Root Cause:**
Since [this commit](https://github.com/odoo/enterprise/commit/733c4ba1fd5558891ffdbc67066c3a3a5938e2f0), company-dependent fields are stored as JSONB in the database. Due to this improvement, the previous SQL constraint (which enforced uniqueness across all records) was removed and replaced with a Python constraint.

However, the new Python constraint utilizes `search_count`, which by default filters out archived records (`active=False`). This allows the reuse of identifiers belonging to archived partners, breaking the uniqueness requirement that existed in previous versions.

Fix:
Update the `_check_datev_identifier` and `_check_datev_identifier_customer` constraints to use `with_context(active_test=False)`. This ensures that the uniqueness check considers all partners, including archived ones.

opw-5474106

Forward-Port-Of: odoo/enterprise#106146

Steps to reproduce:
-------------------
1. Install l10n_ch_hr_payroll_elm_transmission.
2. Switch to a Swiss company and create a new employee.
3. Create a new internal user with Payroll Officer/Manager access.
4. Log in as that user, create a contract, and click on "One-time payments".

Issue:
---------
A Traceback with AccessError:
```You are not allowed to access 'Action Window' (ir.actions.act_window) records.```

Cause:
----------
https://github.com/odoo/enterprise/blob/9e39b4b85fcb9f6ed5b21b942796b76b8a6eefdb/l10n_ch_hr_payroll_elm_transmission/models/hr_contract.py#L195
The code attempts to call `.read()` on an `ir.actions.act_window` record.
Standard users typically do not have read access to window action records,
resulting in an **AccessError** even if they have rights to the payroll data.

Solution:
-------------
Use [_for_xml_id](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L187) to return action content for the provided xml id
in a safe way by doing [sudo](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L205) internally to bypass the access restriction.

opw-5491467

Forward-Port-Of: odoo/enterprise#106598

Steps to reproduce:
1. Install `website_knowledge`
2. Create a long, scrollable knowledge article with 20 sub-articles.
3. Share the article publicly
4. Open the public link in mobile view (logged out)
5. Toggle the sidebar using the top-left menu button
6. Scroll down

Issue:
- On mobile, the public sidebar overlaps with the article's content while scrolling.

Cause:
- the sidebar and its backdrop were positioned absolutely inside a flex container. Because they were not fixed to the viewport, the article content continued to scroll and render underneath the sidebar, causing visible overlap between the sidebar and the article body. Additionally, the sidebar’s internal scroll container was not explicitly positioned, which contributed to inconsistent scrolling behavior when the sidebar was open.

Solution:
- Update the public Knowledge sidebar css to behave as a proper mobile overlay by: Fixing the sidebar and its backdrop to the viewport using position: fixed, ensuring they are removed from the flex layout flow on mobile Explicitly positioning the sidebar’s internal scroll view to ensure correct scrolling behavior

<table>
  <tr>
    <td><strong>Before</strong></td>
    <td><strong>After</strong></td>
  </tr>
  <tr>
    <td><img width="725" height="901" alt="Before image" src="https://github.com/user-attachments/assets/33190684-5b52-4931-b01a-5044734c9cf0" /></td>
    <td><img width="686" height="916" alt="After image" src="https://github.com/user-attachments/assets/610a5aef-3467-4215-a0a0-83607375a016" /></td>
  </tr>
</table>


opw-5384026

Forward-Port-Of: odoo/enterprise#103135

Steps to produce:
---
- Install `accountant` and `l10n_mx` modules.
- Switch to Mexican company.
- In Settings, under `Authorized Certification Provider (PAC)`, set PAC to `Solución Factible`.
- Create new invoice > set customer to `INMOBILIARIA CVA`, payment way to `Efectivo` and product as `Large Meeting table` > confirm the invoice.
- Mark the invoice as global.
- Register the payment.
- Create a credit note and confirm it.
- Click Send(make sure CFDI is checked) and check the generated XML.

Issue:
---
- The CFDI XML sets the `Descripcion` field to the default value `Devoluciones, descuentos o bonificaciones`.

Solution:
---
- Preserve the original line description for CFDI refunds instead of forcing
  the generic label.
- For POS refunds, continue using the generic label.
- This aligns with the fix introduced in 19.0([here]).

Before:
---
<img width="519" height="60" alt="image" src="https://github.com/user-attachments/assets/75066bdb-5fba-4959-bf16-8b2953bc40d5" />

After:
---
<img width="615" height="56" alt="image" src="https://github.com/user-attachments/assets/bd93d0af-957f-47fc-b65c-3ec16c4b8f10" />



[here]: https://github.com/odoo/enterprise/pull/97681/changes/515410ec45541e6c07f892a094bb0aa57f479436
**Backport of https://github.com/odoo/enterprise/pull/97681**

opw-5870052
---

Forward-Port-Of: odoo/enterprise#107367

Before this PR,
`autoresizeInput` used a fixed buffer of `5px` to compensate for input borders. This caused incorrect sizing when inputs had thicker borders, leading to overflow issues.

Safari 16 and earlier versions did not include padding and border in `scrollWidth`. To work around this, browser detection via regex was used to add a hardcoded extra value.
A similar issue appeared in Firefox 145, where scrollWidth also excluded padding and border, causing inputs to overflow again.

After this PR,
The buffer is no longer hardcoded. The border width is now calculated dynamically and applied correctly to the final width. 
Browser sniffing has been removed entirely. Instead, the logic detects at runtime whether scrollWidth includes padding; if not, the missing padding is added to the computed width. This makes the behavior consistent across browsers and prevents overflow without relying on user agent checks.

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

Forward-Port-Of: odoo/odoo#241315

**Steps to Reproduce**

* Install `sale_management`, `purchase`, and `stock` with demo data.
* In Inventory → Settings, enable `Dropshipping`.
* Create a product: 
     * Set a vendor under the Purchase tab. 
     * Set routes to `Dropshipping` and `Buy`
* Create and confirm a sale order for this product.
* Confirm the generated purchase order.
* Cancel the originating sale order.
* Go back to the linked purchase order.

**Observed behavior**

* Two activities are created on the purchase order when the sale order is cancelled.

**Cause**

* Both templates — `exception_on_so` (from sale_stock) and
`exception_purchase_on_sale_cancellation` (from sale_purchase) 
are triggered during sale order cancellation.

* Each module overrides `_action_cancel` and triggers its corresponding exception template.

* When both modules are installed, both templates run.

https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/sale_purchase/models/sale_order.py#L26-L32

https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/sale_stock/models/sale_order.py#L206-L208

* The template `exception_purchase_on_sale_cancellation` should only be triggered
when the PO originates from an SO and the product is a service, but
the domain lacks the required product-type condition.

**Fix**

* Add the missing condition to ensure that `exception_purchase_on_sale_cancellation`
is not triggered for dropshipped products, preventing duplicate activities.

---
`NOTE` - This issue is resolved from version 19.0 in this [commit](https://github.com/odoo/odoo/pull/212679/changes/ede2898278220a3ba4d8910ef268fe59f1587c72)

---
opw-5153488

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

Forward-Port-Of: odoo/odoo#239569

The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts.


[A previous commit](https://github.com/odoo/odoo/commit/48d60151254045768d5aac1b29c5acf84b70cef2) modified the query responsible for the construction of the grouped reports. It only keeps the base lines of type entry which have a balance of the same sign as the tax line. Yet in our case, the CABA move is of type 'entry'. It has only one tax line with a positive amount because the taxes amounts on each line are added. But the balance of the negative line is negative. So the query will only consider the positive line hence the error.

So now, the logic is only considering lines with the same sign to avoid entries where the invoice lines and the refund lines are both there. This is why it only checks for moves of type 'entry'.

We also ignore the check for CABA moves, i.e. moves where `tax_cash_basis_origin_move_id` is defined.


Steps to reproduce:
- Activate Cash Basis in the Settings
- Create a tax based on payment
- Create an invoice with two lines:
   - One with a negative amount, an income account and the created tax
   - One with a positive amount big enough to compensate the previous line, a different income account and the same tax
- Confirm
- Click "Pay", validate the payment
- In the Dashboard > Bank journal > Create a reconciliation of the amount of the invoice
- Reconcile it with the invoice
- Accounting > Reporting > Tax Return
- Select "Group By: Account tax"

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

Forward-Port-Of: odoo/odoo#239081

The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts.

[A previous commit](https://github.com/odoo/odoo/commit/48d60151254045768d5aac1b29c5acf84b70cef2) modified the query responsible for the construction of the grouped reports. It only keeps the baselines of type 'entry' which have a balance of the same sign as the tax line.

But in our case, the CABA move is of type 'entry'. It has only one tax line with a positive amount because the taxes amounts on each line are added. But the balance of the negative line is negative. So the query will only consider the positive line hence the error.

So now, the logic of the only considering lines with the same sign is to avoid entries where the invoice lines and the refund lines are both there. This is why it only checks for moves of type 'entry'.

We also ignore the check for CABA moves, i.e. moves where `tax_cash_basis_origin_move_id` is defined.

Steps to reproduce:
- Activate Cash Basis in the Settings
- Create a tax based on payment
- Create an invoice with two lines:
	- One with a negative amount, an income account and the created tax
	- One with a positive amount big enough to compensate the previous line, a different income account and the same tax
- Confirm
- Click "Pay", validate the payment
- In the Dashboard > Bank journal > Create a reconciliation of the amount of the invoice
- Reconcile it with the invoice
- Accounting > Reporting > Tax Return
- Select "Group By: Account tax"

Community PR: odoo/odoo#239081

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

Forward-Port-Of: odoo/enterprise#101601

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)

Forward-Port-Of: odoo/enterprise#107677

Currently, it is possible to set a DateV identifier on a partner even if it is already assigned to an archived partner. This leads to duplicate identifiers if the archived partner is later unarchived.

###  **Steps to reproduce:**
1) Install **l10n_de_reports, Contacts** App with Demo Data. 
2) Switch to a **DE company**.
3) Create a contact 'Test-A' and set `'DateV Vendor' to 123456789` in the **Accounting Section**. 
4) Archive 'Test-A'.
5) Create 'Test-B' and set `'DateV Vendor' to 123456789`. 
6) Unarchive 'Test-A'.

### **Observed Behavior:**
'Test-B' is created successfully. After step 6, both 'Test-A' and 'Test-B' are active with the same DateV identifier.

### **Expected Behavior:**
A validation error should be raised when trying to save 'Test-B', stating that the identifier is already defined.

### **Root Cause:**
Since [this commit](https://github.com/odoo/enterprise/commit/733c4ba1fd5558891ffdbc67066c3a3a5938e2f0), company-dependent fields are stored as JSONB in the database. Due to this improvement, the previous SQL constraint (which enforced uniqueness across all records) was removed and replaced with a Python constraint.

However, the new Python constraint utilizes `search_count`, which by default filters out archived records (`active=False`). This allows the reuse of identifiers belonging to archived partners, breaking the uniqueness requirement that existed in previous versions.

Fix:
Update the `_check_datev_identifier` and `_check_datev_identifier_customer` constraints to use `with_context(active_test=False)`. This ensures that the uniqueness check considers all partners, including archived ones.

opw-5474106

Forward-Port-Of: odoo/enterprise#106146

Steps to reproduce:
-------------------
1. Install l10n_ch_hr_payroll_elm_transmission.
2. Switch to a Swiss company and create a new employee.
3. Create a new internal user with Payroll Officer/Manager access.
4. Log in as that user, create a contract, and click on "One-time payments".

Issue:
---------
A Traceback with AccessError:
```You are not allowed to access 'Action Window' (ir.actions.act_window) records.```

Cause:
----------
https://github.com/odoo/enterprise/blob/9e39b4b85fcb9f6ed5b21b942796b76b8a6eefdb/l10n_ch_hr_payroll_elm_transmission/models/hr_contract.py#L195
The code attempts to call `.read()` on an `ir.actions.act_window` record.
Standard users typically do not have read access to window action records,
resulting in an **AccessError** even if they have rights to the payroll data.

Solution:
-------------
Use [_for_xml_id](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L187) to return action content for the provided xml id
in a safe way by doing [sudo](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L205) internally to bypass the access restriction.

opw-5491467

Forward-Port-Of: odoo/enterprise#106598

Steps to produce:
---
- Install `accountant` and `l10n_mx` modules.
- Switch to Mexican company.
- In Settings, under `Authorized Certification Provider (PAC)`, set PAC to `Solución Factible`.
- Create new invoice > set customer to `INMOBILIARIA CVA`, payment way to `Efectivo` and product as `Large Meeting table` > confirm the invoice.
- Mark the invoice as global.
- Register the payment.
- Create a credit note and confirm it.
- Click Send(make sure CFDI is checked) and check the generated XML.

Issue:
---
- The CFDI XML sets the `Descripcion` field to the default value `Devoluciones, descuentos o bonificaciones`.

Solution:
---
- Preserve the original line description for CFDI refunds instead of forcing
  the generic label.
- For POS refunds, continue using the generic label.
- This aligns with the fix introduced in 19.0([here]).

Before:
---
<img width="519" height="60" alt="image" src="https://github.com/user-attachments/assets/75066bdb-5fba-4959-bf16-8b2953bc40d5" />

After:
---
<img width="615" height="56" alt="image" src="https://github.com/user-attachments/assets/bd93d0af-957f-47fc-b65c-3ec16c4b8f10" />



[here]: https://github.com/odoo/enterprise/pull/97681/changes/515410ec45541e6c07f892a094bb0aa57f479436
**Backport of https://github.com/odoo/enterprise/pull/97681**

opw-5870052
---

Forward-Port-Of: odoo/enterprise#107367

Steps to reproduce:
1. Install `website_knowledge`
2. Create a long, scrollable knowledge article with 20 sub-articles.
3. Share the article publicly
4. Open the public link in mobile view (logged out)
5. Toggle the sidebar using the top-left menu button
6. Scroll down

Issue:
- On mobile, the public sidebar overlaps with the article's content while scrolling.

Cause:
- the sidebar and its backdrop were positioned absolutely inside a flex container. Because they were not fixed to the viewport, the article content continued to scroll and render underneath the sidebar, causing visible overlap between the sidebar and the article body. Additionally, the sidebar’s internal scroll container was not explicitly positioned, which contributed to inconsistent scrolling behavior when the sidebar was open.

Solution:
- Update the public Knowledge sidebar css to behave as a proper mobile overlay by: Fixing the sidebar and its backdrop to the viewport using position: fixed, ensuring they are removed from the flex layout flow on mobile Explicitly positioning the sidebar’s internal scroll view to ensure correct scrolling behavior

<table>
  <tr>
    <td><strong>Before</strong></td>
    <td><strong>After</strong></td>
  </tr>
  <tr>
    <td><img width="725" height="901" alt="Before image" src="https://github.com/user-attachments/assets/33190684-5b52-4931-b01a-5044734c9cf0" /></td>
    <td><img width="686" height="916" alt="After image" src="https://github.com/user-attachments/assets/610a5aef-3467-4215-a0a0-83607375a016" /></td>
  </tr>
</table>


opw-5384026

Forward-Port-Of: odoo/enterprise#103135

Steps to reproduce:
-------------------
1. Install l10n_ch_hr_payroll_elm_transmission.
2. Switch to a Swiss company and create a new employee.
3. Create a new internal user with Payroll Officer/Manager access.
4. Log in as that user, create a contract, and click on "One-time payments".

Issue:
---------
A Traceback with AccessError:
```You are not allowed to access 'Action Window' (ir.actions.act_window) records.```

Cause:
----------
https://github.com/odoo/enterprise/blob/9e39b4b85fcb9f6ed5b21b942796b76b8a6eefdb/l10n_ch_hr_payroll_elm_transmission/models/hr_contract.py#L195
The code attempts to call `.read()` on an `ir.actions.act_window` record.
Standard users typically do not have read access to window action records,
resulting in an **AccessError** even if they have rights to the payroll data.

Solution:
-------------
Use [_for_xml_id](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L187) to return action content for the provided xml id
in a safe way by doing [sudo](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L205) internally to bypass the access restriction.

opw-5491467

Forward-Port-Of: odoo/enterprise#106598

Before this PR,
`autoresizeInput` used a fixed buffer of `5px` to compensate for input borders. This caused incorrect sizing when inputs had thicker borders, leading to overflow issues.

Safari 16 and earlier versions did not include padding and border in `scrollWidth`. To work around this, browser detection via regex was used to add a hardcoded extra value.
A similar issue appeared in Firefox 145, where scrollWidth also excluded padding and border, causing inputs to overflow again.

After this PR,
The buffer is no longer hardcoded. The border width is now calculated dynamically and applied correctly to the final width. 
Browser sniffing has been removed entirely. Instead, the logic detects at runtime whether scrollWidth includes padding; if not, the missing padding is added to the computed width. This makes the behavior consistent across browsers and prevents overflow without relying on user agent checks.

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

Forward-Port-Of: odoo/odoo#241315

Steps to reproduce
-----
- Enable locations & by products
- Create 4 locations
	- View A of type view (parent: Stock)
	- View B of type view (parent: Stock)
	- Storage A of type internal location (parent: View A)
	- Storage B of type internal location (parent: View B)
- Create a "Manufacture to A" route
	- Rule 1: Manufacture, Stock -> Stock
	- Rule 2: Push To, Internal Transfer, Stock -> View A
- Create a "By Products to B" route
	- Rule 1: Push To, Internal Transfer, Stock -> View B
- Create a "Bonus" product with route "By Products to B"
- Create a "Finished" product with route "Manufacture to A"
	- BoM with "Bonus" as by product
- Create a MO for Finished, and produce it
- Open the linked transfers' list view
- Open the "Bonus" transfer

> "Destination Location" states View B

- Open the line's details (hamburger button)

> "Store To" states View A/Storage A

Cause
-----
When retrieving the location in

https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_move_line.py#L280-L282

we pass `locations` as a context key. The problem is that `locations` contains the childs of **all** of the SMLs' locations

https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_move_line.py#L260

This means that, in `_get_putaway_strategy`, when no `putaway_location` is found, we end up defaulting to the first element of the list

https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_location.py#L370-L371

which might not be a child of the location.

Solution
-----
By removing the context key, locations get populated as such

https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_location.py#L328-L330

This is ok because we know the call to `_get_putaway_strategy` is made on a single record (`sml.move_id.location_dest_id`) so the default will correctly be a child of said location.

-----
Ticket:
opw-5359945

## Versions
18.0+
Not visible in 19.0 because the UI prevents this behavior but it still occurs in the backend.

## Issue
In eCommerce, when a customer places an order for in-store pickup at one location, then places another order for pickup at a different store, a problematic address record can be created iff they select the previously used store address (created during the first order) as the delivery address.

This leads to a third address being created with a name combining both store locations, due to improper address parent-child relationships.

## Steps to reproduce
With Admin user:
- In Inventory's "Warehouses", duplicate the existing warehous:
  - Change the duplicated one's address (create one if needed).
- Activate "Click & Collect" in Settings app;
- Setup "Pickup Locations":
  - Under "Pick up in store", add both warehouses.
- Go to a storable and published product (eg. Acoustic Bloc Screens):
  - Set On Hand quantity to at least 2 units per warehouse.

With Portal user logged in:
- Access the shop:
  - Order 1 unit of the setup product;
  - Process checkout up to Delivery step:
    - Select user's address (only available "DELIVERY ADDRESS");
    - Select a store location;
    - Confirm and finalize the order.
  - Order 1 unit of the setup product (bis);
  - Process checkout up to Delivery step (bis):
    - Select the store address (newly created "DELIVERY ADDRESS");
    - Select the other store location;
    - Confirm and finalize the order.
  - Order 1 unit of the setup product (ter);
  - Process checkout up to Delivery step (ter):
    - A third address shows up named after both store locations.

## Cause
The `_action_confirm` method looks for an existing partner based on `parent_id`: https://github.com/odoo/odoo/blob/d80628a45bcfe5192f1b95286a6758fe6616fbec/addons/delivery/models/sale_order.py#L169-L176

The issue comes from:
https://github.com/odoo/odoo/blob/d80628a45bcfe5192f1b95286a6758fe6616fbec/addons/delivery/models/sale_order.py#L164 https://github.com/odoo/odoo/blob/d80628a45bcfe5192f1b95286a6758fe6616fbec/addons/delivery/models/sale_order.py#L178-L189

On the first order:
- A new delivery address is created.
- Its `parent_id` is set to the customer (order partner).

On the second order:
- The user selects the previously created store address as delivery address.
- Odoo sets the `parent_id` of the new address to this store address (instead of the customer).
- This creates an unintended hierarchy, causing further confusion in subsequent orders.

opw-5340953

**Issue 1:**

Steps to Reproduce

- Click on the More options button in the power buttons.
- The powerbox opens, but the editor loses focus and the button receives focus.

Description of the issue:

- After clicking the power button, the button becomes focused and the editor loses focus.

Solution

- When clicking the power button, after the command is executed in the click event, explicitly restore focus to the editable area so the editor remains focused.

**Issue 2:**

Steps to reproduce

- Click More options in the Power Buttons to open the powerbox.
- Start typing `heading`.

Description of the issue:

- The powerbox does not filter commands and continues to show all commands.

Cause:
- In `search_powerbox_plugin`, commands are filtered only when `shouldUpdate` is true.
- `shouldUpdate` is set only when the powerbox is opened through `search_powerbox_plugin`.
- Power Buttons open the powerbox via `powerbox_plugin`, so `shouldUpdate` remains false and filtering is not triggered.

Solution:
- Introduced `openSearchPowerbox` in `searchPowerboxPlugin`.
- Updated the implementation to use this method instead of `openPowerbox` in `search_powerbox_plugin`.
- Instead of opening the powerbox via `powerbox_plugin`, it is now opened via `search_powerbox_plugin`, ensuring `shouldUpdate` is set correctly and commands are filtered on keypress.

task-5485088

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

This commit aligns the Italian e-invoicing (FatturaPA) generation for One Stop Shop (OSS) transactions with the requirements of the Italian Revenue Agency ( Agenzia delle Entrate).

Current behavior:
Invoices for intra-EU B2C sales (OSS) are generated with a single line containing the foreign VAT rate. This is rejected or considered non-compliant by the SDI because foreign VAT cannot be typically exposed in the standard way for Italian electronic invoices.

New behavior:
The XML generation logic has been updated to follow the specific codification required for OSS operations:

1. Invoice Lines (`DettaglioLinee`):
   - The product line is reported with 0% VAT and Nature 'N7' (VAT paid in another EU member state).
   - A new, separate line is injected to represent the VAT amount, classified with Nature 'N2.2' (Non-taxable/Other).

2. Tax Summary (`DatiRiepilogo`):
   - The original foreign tax lines are excluded from the summary.
   - Synthetic summary lines are added for the 'N7' (Taxable Base) and 'N2.2' (VAT Amount) categories.

Implementation details:
- Added `_l10n_it_is_oss_tax` helper to identify OSS taxes.
- Modified `_l10n_it_edi_get_line_values` to split OSS lines.
- Modified `_l10n_it_edi_get_tax_values` to adjust the tax summary.

task-4711509

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

With an `l10n_it` company:
- Create an invoice in a foreign currency and export the XML.

In the XML, the field `ImportoTotaleDocumento` is expressed in the invoice currency, while `Divisa` is set to the company currency.
`ImportoTotaleDocumento` must be expressed in EUR, as stated in the following document:
https://www.agenziaentrate.gov.it/portale/documents/20143/0/10FAQ+pubblicate+il+19+luglio+2019+(aggiornate+il+1+luglio+2021).pdf/6e8acb34-b7c5-730e-6a39-79c0a296e02b

> L'art. 21, comma 2, lettera l) del d.P.R. n. 633/72 specifica che
> “aliquota, ammontare dell'imposta e dell'imponibile con arrotondamento al centesimo di euro”.
> Conseguentemente, se la fattura è emessa da soggetti residenti o stabiliti il codice da inserire nel campo `<Divisa>`
> deve essere obbligatoriamente “EUR”.

> Article 21, paragraph 2, letter (l) of Presidential Decree No. 633/72 specifies that
> “the tax rate, the amount of the tax, and the taxable amount must be stated with rounding to the euro cent.”
> Consequently, if the invoice is issued by resident or established taxpayers, the code to be entered in the `<Divisa>`
> field must mandatorily be “EUR”.

As a result, we now use the **company currency amount** for the `ImportoTotaleDocumento` field
(assuming the company currency is always EUR for `l10n_it`).

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