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