## **Steps to Reproduce:**
1) Install `l10n_ch_hr_payroll`, `hr_payroll_account_iso20022` with demo data. 
2) Switch to the Swiss company and rename it.
3) create employee with address in switzerland and setup bank details with
   running contract.
4) Generate a payrun, validate it, then download the Swiss payment report.

#### **Note: Detailed video to generate this issue on v18 is attached on the ticket**

## **Obeserved Behavior:**
The report still uses the old company name instead of the renamed one.

## **Expected Behavior:**
The report should use the current company name.

## **Root Cause:**
In the payment report the `iso20022_initiating_party_name`, is set using
`iso20022_get_company_name` method at [1] and `iso20022_initiating_party_name`
was only initialized on `create` at [2], so later company renames did not
update the stored initiating party name when it matched the previous company name.

[1]- https://github.com/odoo/enterprise/blob/a86b98ea4fbc060cbe2666bc87f215a680ce54e7/account_iso20022/models/account_journal.py#L442-L446

[2]- https://github.com/odoo/enterprise/blob/7df2e86541a69d3160bc7165223227bde70d7291/account_iso20022/models/res_company.py#L16-L24

## **Fix:**
Update the stored ISO20022 initiating party name on company write whenever it still matches the previous sanitized company name.

**opw-6159675**

Libmagic version 0.46 (currently available in Debian Trixie/Forky and Ubuntu Resolute) introduced a regression regarding ZIP file detection. While it correctly identifies a ZIP file when reading directly from a file path, it fails when reading the exact same content from a buffer, returning a generic 'application/octet-stream' instead.

Because `guess_mimetype` primarily evaluates buffers, this upstream bug breaks MIME type detection for ZIP files (and related formats like docx, xlsx, etc.) in Odoo environments running this libmagic version.

Since we cannot directly fix the library itself, this commit adapts Odoo's `guess_mimetype` to fallback to our custom implementation when libmagic returns the generic 'application/octet-stream' to workaround this library's bug.

Upstream libmagic fixes:
- https://github.com/file/file/commit/f1adef05b8a85be50d28965b1fd21fcceacf7a4e
- https://github.com/file/file/commit/60b2032b96fc185b37fb0f2152e834efb2edad6e

Upstream python-magic issue:
- https://github.com/ahupp/python-magic/issues/354

runbot-938197

Forward-Port-Of: odoo/odoo#269506

Problem:
- `s_three_columns` is not rendered correctly in Outlook Desktop when the equal-height option is enabled.
- Button padding, border radius, and background color are not rendered properly in Outlook Desktop.

Solution:
- Set the `height` attribute on `td.card-body` along with `valign` so columns keep the same height in Outlook Desktop.
- Use `v:roundrect` to support rounded corners (`arcsize`) and background colors (`fillcolor`), making buttons render consistently with the editor in Outlook Desktop.

Before:
<img width="1249" height="1297" alt="image" src="https://github.com/user-attachments/assets/828bc42b-1e21-404c-a5ae-81d4ee688802" />
After:
<img width="1249" height="1309" alt="image" src="https://github.com/user-attachments/assets/263a1c30-fe86-4e40-b3c2-476abc2bf84a" />

Steps to reproduce:
- Add the `s_three_columns` snippet with one card containing more content than the others.
- Add some buttons.
- Send or preview the email in Outlook Desktop.
- Observe that column heights and button styling are not rendered correctly.

opw-6044725

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

Forward-Port-Of: odoo/odoo#269791
Forward-Port-Of: odoo/odoo#269274

Currently, access rights for `mail.message` rely on a set of layered rules. If an administrator attempts to manage (edit, delete, or duplicate) a message record—and fails all of these contextual evaluations, they are ultimately blocked by an AccessError.

For example:
- Mitchell Admin sends a mass mailing via CRM app.
- The email fails to send.
- Marc Demo (an administrator with no access to CRM) tries to edit, delete, or duplicate the failed email. Because he fails the specific contextual access rules for that message, he is blocked.

This behavior is overly restrictive. Administrators already possess the power to elevate their privileges, grant themselves access to any app, or log in as other users. Blocking them from managing critical communications (like a stalled mass mailing queue) forces them to use unnecessary workarounds.

This commit resolves the issue by short-circuiting the `_check_access` method. If the environment is in admin mode (`self.env.is_admin`), we bypass the complex rule evaluations entirely and grant immediate access.

We specifically implemented this via a Python override rather than modifying `ir.rule` records in `security.xml`. This ensures the fix can be safely backported to stable versions without requiring a forced XML data update on existing databases. It also keeps this specific security bypass centralized within the mail module's existing architecture.

Module: l10n_it_pos

Steps to reproduce:
- In the POS settings, enable "Automatic Receipt Printing";
- Enable "ePos Printer" to make the "Skip Preview Screen" option appear;
- Disable "Skip Preview Screen";
- Disable "ePos Printer";
- Set up an Italian Fiscal Printer;
- Open a POS session and process a first order. Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required.

Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required.

Cause:
When "Automatic Receipt Printing" is true but "Skip Preview Screen" is false, a race condition occurs. `afterOrderValidation` triggers a print job while simultaneously transitioning to the `ReceiptScreen`. When the `ReceiptScreen` mounts, it triggers a second fiscal print job before the first has resolved. This creates a deadlock in `toHtml` of  `renderService`, permanently blocking the printer queue.

Solution:
Since the italian localisation sending the receipt to the fiscal printer is mandatory, the printing route is now tied to the "Skip Preview Screen" option.

Enterprise PR: https://github.com/odoo/enterprise/pull/112654

[opw-5979212](https://www.odoo.com/odoo/project/49/tasks/5979212)

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

Module: l10n_it_pos

Steps to reproduce:
- In the POS settings, enable "Automatic Receipt Printing";
- Enable "ePos Printer" to make the "Skip Preview Screen" option appear;
- Disable "Skip Preview Screen";
- Disable "ePos Printer";
- Set up an Italian Fiscal Printer;
- Open a POS session and process a first order.

Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required.

Cause:
When "Automatic Receipt Printing" is true but "Skip Preview Screen" is false, a race condition occurs. `afterOrderValidation` triggers a print job while simultaneously transitioning to the `ReceiptScreen`. When the `ReceiptScreen` mounts, it triggers a second fiscal print job before the first has resolved. This creates a deadlock in `toHtml` of  `renderService`, permanently blocking the printer queue.

Solution:
Since the italian localisation sending the receipt to the fiscal printer is mandatory, the printing route is now tied to the "Skip Preview Screen" option.
UI settings are adjusted to hide the redundant auto-print checkbox when an IT fiscal printer is configured.

Community PR: https://github.com/odoo/odoo/pull/256932

[opw-5979212](https://www.odoo.com/odoo/project/49/tasks/5979212)

Steps to reproduce
------------------
1. Set a default tax on the "Cash Difference Gain" account (e.g. a 25%
   sales tax) -- required in some countries like Denmark (cf 5972690).
2. Open a PoS session, count more cash than expected at closing.
3. Try to close the session.

-> Error message shows up "The journal entry reached an invalid
state..." ... "The journal entry must always have exactly one journal
item involving the bank/cash account"

What's happening
----------------
PoS creates a bank statement line with the gain account as counterpart,
resulting in 2 lines: cash +10, gain -10. Since the gain account has a
default tax, `_sync_tax_lines` adds a tax line of -2.5 on top, which
makes the move unbalanced by 2.5. Then `_sync_unbalanced_lines` adds a
4th line to fix it, on the line returned by
`_get_automatic_balancing_account`, which is `journal.default_account_id`,
i.e. the cash account itself for a cash journal.

So we end up with 2 lines on that same cash account, which a bank
statement line move doesn't allow -> Error.

The fix
-------
In `_post_statement_difference`, precompute the base and tax split
ourselves and build the statement line's `line_ids` directly (e.g. for
+10 and a 25% tax: cash +10, gain -8, tax -2). The move is balanced
from creation, so `_sync_tax_lines` and `_sync_unbalanced_lines` don't
have to touch it.

Note that we force the tax computation to be in 'force_price_include'
mode, as the counted cash difference is a gross amount (physical money
in the drawer). This way the tax is always extracted from the cash
amount, regardless of how the tax is configured (included or excluded
in price). Same pattern is already used by `hr_expense` (cf
`hr_expense.models.account_move_line._compute_totals`).

opw-5972690

Behavior before:
Adjusting physical inventory quantities for reserved packages takes time when linked to large delivery orders (e.g., 400+ lines). The user interface freezes, causing a poor warehouse user experience during stock counts.

Behavior after:
Inventory adjustments on reserved packages process faster. The UI remains responsive, and package records are updated instantly without performance degradation.

Root Cause:
When an inventory adjustment triggers '_free_reservation', it processes move lines sequentially. Inside this loop, Odoo recursively runs '_check_entire_pack()', forcing a full database evaluation of all 400+ delivery lines for every single line adjusted. This results in heavy, redundant processing.

Fix:
Used a context flag `bypass_entire_pack=True` to silence the '_check_entire_pack()' validation while looping through individual line adjustments. Once the loop completes, the package validation is called exactly once in batch for all affected pickings, preserving data integrity while eliminating redundant database queries.

Steps to Reproduce:
1. Have a product tracked by Lot and Package.
2. Have an open delivery order in Ready state (stock reserved) containing 400 or more lines of this product, one package per line.
3. Go to Inventory → Physical Inventory.
4. Set the counted quantity of any reserved bag to 0.
5. Click Apply.
6. Observe that the system takes time to process this single change.
7. Unreserve the delivery order.
8. Perform the same steps as mentioned above.
9. Inventory adjustment is much faster.

opw-6234885

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

## The Problem
When grouping messages, the code was accumulating recordsets using the `|=` union operator inside a loop. Since each union call internally builds an `OrderedSet` over all previously accumulated IDs, the performance degraded quadratically relative to the number of document records. This caused bottlenecks on databases with large message volumes.

## The Solution
* Replaced the `|=` recordset accumulation with a plain Python dictionary of ordered sets to store IDs per operation, while keeping same behavior.
* Deferred the `browse()` call until after the loop is complete.
* Reduced the overall complexity from **$O(N^2)$** to **$O(N)$**.

---

## Benchmarks
*Tested on a customer database grouping by "Created By" and "Created On":*

| Record Count | Before | After | Improvement |
| :--- | :--- | :--- | :--- |
| **300k records** | 83.00s | **1.00s** | **-99%** |
| **30k records** | 0.60s | 0.25s | (Minor) |

**Note:** The performance gains become exponentially more significant as the record count grows.

**OPW-6123758**

Forward-Port-Of: odoo/odoo#260147

The translate button next to a translatable field saves the record before opening the translation dialog for its id. Since https://github.com/odoo/odoo/commit/a85ca9679e3855936afc66b034d05d75f672dd26 it saves record.model.root rather than the record itself. When the field belongs to a new record still edited inside an x2many, for example an answer added in the survey question popup, saving the root only saves the parent and the new line keeps no database id. The dialog then opens with the id set to false and calls update_field_translations on it, which builds WHERE id = false and the database rejects it with operator does not exist: integer = boolean.

Such a record gets no id of its own, and after a save and reload there is no reliable way to match the saved line back to the one that was clicked, so the dialog can never open for it. A canTranslate getter in TranslationButton returns false for a new record whose model root is another record, which is exactly a line still edited inside an x2many, and the template only renders the button when it is true. The variant in editable lists, where model.root is a list rather than a record, was handled in https://github.com/odoo/odoo/commit/cb34b318004c3ca9db755d8dbbad429609220df3.

Steps to reproduce:
1. Activate a second language in Settings > Translations > Languages
2. Open the Surveys app and create a survey
3. Add a question, then in the Answers tab add a line and type a value
4. Click the EN button next to the answer, fill the second language, and Save

=> RPC error operator does not exist: integer = boolean from WHERE id = false

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

[FIX] mail_alias_domain: prevent capitalization in domain names to avoid email routing issues
    
Currently, we allow capitalization in the name / display_name field for Email Domains (mail.alias.domain), which allows for capitalized domains in email aliases. When the system receives incoming emails via mail_thread.py's message_route,
the reply_to email addresses are sanitized (all lowercase). We then use the case-sensitive 'in' to identify
message routes, which will always fail for capitalized email domains.

This PR applies sanitizing to the name field so that users cannot save capitalized email domains.

Other options are not viable because:
1. we don't have a case-insensitive equivalent of the 'in' operator
2. altering the current logic to be case-insensitive would decrease performance
3. altering the current logic would change the structure of message_route

Fixes #opw-5401633

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

Steps to reproduce:
===================
1. Edit a job page.
2. Delete every `s_rating` block.
3. Save.

=> Validation Error: Document is empty.

Cause:
======
Deleting the last snippet inside an editable HTML field (e.g. the last `s_rating` block in the `website_rating` field of a job page) leaves the field's editable container with only whitespace text nodes. On save, it writes that whitespace to the record and then calls `_copy_custom_snippet_translations`, which does
`html.fromstring(lang_value)` on the whitespace and raises `lxml.etree.ParserError: Document is empty`, re-raised as `ValidationError`. The user sees a "Validation Error" dialog and can't finish saving.

The previous fix for the analogous "Document is empty" symptom on product description editing (commit [1])
added a `cleanupEmptyStructures` `on_removed_handlers` that strips whitespace from `.oe_empty` containers after element removal. That selector covers `oe_structure.oe_empty` containers but not editable HTML field savables (`[data-oe-type="html"]`), which don't carry an `oe_empty` class when they originally had content. As a result, fields like `hr.job.website_rating` still hit the failing parse path.

Solution:
=========
Extend the cleanup selector to also include `[data-oe-type="html"]` so HTML-field editables are normalized to genuinely empty after the last inner snippet is removed.

[1]: https://github.com/odoo/odoo/commit/53d5cc7eed635f64038bf0315f6863011879c529

opw-6244892

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

**Steps to reproduce:**
- Install the `l10n_de` module and switch to a `DE Company`.
- Enable `Peppol` in the Invoicing app settings.
- Open the `DE Company` customer record.
- In the `Invoicing` tab, change the Peppol ID code from `Germany VAT` 
  to `Germany Leitweg-ID` and set a code (e.g., `13075957-K000-52`).
- In the `Contacts & Addresses` tab, create an invoice-type contact named `test`.
- Create a new invoice using the `test` contact.
- Send the invoice via Peppol.
- Download the generated `XML` and inspect the `BuyerReference` field.

**Observation:**
The `<cbc:BuyerReference>` field is set to `N/A` instead of the configured `Leitweg-ID`.

**Root Cause:**
At [1], the `BuyerReference` node is populated using `vals['customer']`. 
For invoices addressed to an invoice-type contact, the contact itself 
does not contain the Peppol configuration, which is stored on the 
commercial partner. As a result, the code fails to retrieve the 
customer's `Leitweg-ID` and leaves the `BuyerReference` field empty.

**Fix:**
This commit ensures that the configured Leitweg-ID is correctly added to the 
`BuyerReference` field for child contact.

[1]:
https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_xrechnung.py#L87-L97

opw-6269478