**Steps to reproduce:**
* Install the *Purchase* module
* Create a product and set an *Reference* and
  Under the *Purchase* tab, add a vendor and define a *Vendor Product Code*.
* Create a Purchase Order with the same vendor set as on the product.
* Add the configured product to the *Purchase Order Lines*.
* Add the same product again on a second line and save the order.
* Activate debug mode
* Go to the view:Form and add a limit to have only 1 POL per page
* Return to your PO
* Go to the second page

**Observed behavior:**
* The *product display name* in the purchase order lines is different on
  the second page compared to the first page.

**Cause:**
* On the first page, purchase order lines are fetched via a web_read on the
purchase order.
* On subsequent pages, lines are fetched via a web_read directly on the
purchase order lines.
* The client requests both name and product_id.display_name.
product field context includes partner_id, causing
product_id.display_name to be computed as the vendor name.
* As both values resolve to the vendor name, the original product
name is lost, leading to inconsistent display across pages.

**Note:**

A similar issue was addressed in this commit : https://github.com/odoo/odoo/commit/28d53e0e565e266ca3fa2b67e359b4383fa42c36
* but its consequence it breaks the search using the vendor code/name in POL.

* That change was reverted in this commit duo to the there consequence : https://github.com/odoo/odoo/commit/c9e8a802315be27a076ae677b9191c075e4c239d

**Fix:**
* This ensures the product name is propagated correctly in the form
view while preserving search by vendor code or name.

---

opw-5170924

Forward-Port-Of: odoo/odoo#258467
Forward-Port-Of: odoo/odoo#240515

Steps to produce:
---
- Install `Sales` module.
- Create a sale order, set a product, and assign Marc Demo as salesperson in the Other Info tab.
- Confirm the sale order and create an invoice.

Issue:
---
- In the email notification sent to the salesperson, the record reference displays as False and the amount shows as 0.00.

Root cause:
---
- Here at [1], the record name is False because the invoice is still in draft state.
- In [18], _sync_invoice sets amount_currency = line.balance for new
  lines, but balance is precomputed as 0 before the INSERT because
  _compute_balance returns 0 for invoice lines. In [17] it read
  price_subtotal directly, which is always correct.
- In 17.0 the same mail fires at the same moment, but _sync_invoice
  had already set balance = −295 and amount_currency = −295 from
  price_subtotal, so the email reads the correct 295.00.

Solution:
---
- Use record.display_name instead of record.name, as display_name is always present regardless of the record state.
- Use the tax totals amount instead of amount_total, which is not yet computed on draft invoices.

[1]https://github.com/odoo/odoo/blob/0bcc34ec2f92b9b95cde321423d810002bb317ce/addons/account/models/account_move.py#L6478
[18]https://github.com/odoo/odoo/blob/b0a50104a12b205958316d382b4c7b2176395877/addons/account/models/account_move_line.py#L1566-L1610
[17]https://github.com/odoo/odoo/blob/73c076893de79df5a86aa970fde46a7aacbeaf3d/addons/account/models/account_move_line.py#L1536-L1585


Before:
---
<img width="400" height="175" alt="image" src="https://github.com/user-attachments/assets/48c2dc03-765a-49c3-bad3-fd0b14405786" />

After:
---
<img width="400" height="175" alt="image" src="https://github.com/user-attachments/assets/53682171-155f-46b3-85dd-0c7c98482067" />


opw-6023827
---

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

Forward-Port-Of: odoo/odoo#258375
Forward-Port-Of: odoo/odoo#254862

**Steps to reproduce:**
* Install `l10n_hr_edi` module.
* Generate an invoice and validate it.
* Generate a credit note from that invoice.
* Without a recipient bank account, try to send the credit note to Mojeracun.

**Observed behavior:**
* Two errors are raised before the XML is generated:
  1. `AttributeError: 'NoneType' object has no attribute 'get'` in `_invoice_constraints_eracun_new` when checking for whitespace in the bank account number.
  2. `ValueError: The following child node is not defined in the template: CreditNote/cac:BillingReference/cbc:IssueDate` during XML serialization.

**Cause:**
* issue 1 : https://github.com/odoo/odoo/commit/96cf6626d2b3e75637b908244cf2fa4da615c16b#diff-16f43166a8e5a637cb57b5695a1332845ba5440d989e25fcd59c828aa55cb036R81
* In the mentioned commit `_invoice_constraints_eracun_new`, `node.get('cac:PayeeFinancialAccount', {})` returns `None` instead of `{}` when the key exists but its value is explicitly set to `None` (which happens when no bank account is set). Chaining `.get()` on `None` raises `AttributeError`.
* issue 2 : https://github.com/odoo/odoo/commit/47ef0c2cb96be9fffdc4985255661807980839c6#diff-16f43166a8e5a637cb57b5695a1332845ba5440d989e25fcd59c828aa55cb036R146
* In the mentioned commit in `_ubl_add_billing_reference_nodes`, `cbc:IssueDate` was added as a direct child of `cac:BillingReference`. The UBL template only allows `cac:InvoiceDocumentReference` as a child of `BillingReference`, while `cbc:IssueDate` belongs inside `cac:InvoiceDocumentReference`.

**Fix:**
* Replace `.get('cac:PayeeFinancialAccount', {})` with `.get('cac:PayeeFinancialAccount')` to safely handle an explicitly `None` value before chaining further calls.
* Move `cbc:IssueDate` inside `cac:InvoiceDocumentReference` in the `BillingReference` node, matching the structure defined in `ubl_21_common.py`.

opw-6088424

Forward-Port-Of: odoo/odoo#258057

### Issue before this commit:
When creating an invoice using the child contact of a parent contact that has a different language with respect to the father, the label of the invoice line was not always displayed in the child contact language but in the father's contact language.

### Steps to reproduce the issue:
1. Activate at least 2 languages (X and Y)
2. Create a product and set the translation for that product in the activated languages
3. Create a Contact with the language X
4. Create a child contact (invoice adress type) for that contact with language Y
5. Create a new invoice setting the customer as the child contact
6. Add the product you created
7. See the label is displayed in the language of the parent contact

### Cause of the issue:
The computation of the invoice line name relied on line.partner_id.lang. However, the partner_id of the move line is automatically set to the commercial partner that can be different (can be the father's contact) to the contact used on the invoice. As a result, the product description was translated using the wrong language.

### Reason to introduce the fix:
To ensure that invoice line labels are correctly translated according to the language of the selected invoice contact, the computation now uses the language of move_id.partner_id instead of line.partner_id. This guarantees consistent and expected behavior in multilingual environments, especially when using different contacts under the same commercial partner.

opw-5955875

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

Forward-Port-Of: odoo/odoo#258458
Forward-Port-Of: odoo/odoo#254833

Currently, payments may remain in the 'in_process' state even when the
associated vendor bills are fully paid. This occurs primarily when using
early payment discounts (EPD) and journals without outstanding accounts.

Steps to reproduce:
- Create an early payment term.
- Create a Vendor Bill with EPD and post it.
- Register a payment for this bill (no outstanding account set on
  journal => no move created).
- Create a bank transaction fully paying the bill.
- Reconcile the transaction with the bill.

Issue: Access the payment of the bill. The payment state remains
'in_process' instead of 'paid'.

Analysis: The issue occurs because the reconciliation process misses the
trigger to set the payment state to 'paid'. Specifically:
- The payment amount does not match the bill total due to the EPD.
- The payment compute method does not monitor 'reconciled_bill_ids',
  causing it to ignore the status of linked vendor bills.

This change adds 'reconciled_bill_ids' to the compute dependencies and
ensures that if a payment is reconciled with any moves (invoices or
bills), their payment_state is considered to determine the final state
of the payment.

Test in enterprise: https://github.com/odoo/enterprise/pull/112398

opw-5881976

Forward-Port-Of: odoo/odoo#256486

Steps to reproduce:
- Use a Luxembourg company
- Post a P&L result for the year and do the year-end affectation (Dr 142 / Cr 1412)
- Open the Luxembourg balance sheet (full or abbreviated)

Issue:
Line "V. Profit or loss brought forward" shows incorrect values.

Cause:
The `accounts` expression for that line used `account_codes` engine with formula `-14`,
which only sums accounts by code prefix. Account 1412 ("Results brought forward (assigned)")
was typed as `equity`, so its balance was carried forward as an initial balance instead of
being captured as retained earnings in the formula.

Solution:
- Set account 1412 to `equity_unaffected`, consistent with account 142.
- Change the `accounts` expression of Line V in both the full and abbreviated balance sheet
  to use the `domain` engine:
  `['|', ('account_id.code', '=like', '14%'), ('account_id.account_type', '=', 'equity_unaffected')]`
  with subformula `-sum`.
  This correctly captures the balance of all 14x accounts and any `equity_unaffected` accounts,
  which covers the standard year-end affectation workflow.

opw-5883505

Forward-Port-Of: odoo/odoo#253559

Description of the issue/feature this PR addresses:

During a module update (-u ModuleName), the check introduced by #220983 patches temporarily a field with "company_dependent=True" because the overriding module is not loaded yet.

But currently it is logged as a warning and makes Odoo.sh production branch appears in yellow (warning state), while the update is actually fine.

Current behavior before PR:

Logs may contain warnings such as:

- Patching res.partner.ref with company_dependent=True
- Patching product.template.sale_ok with company_dependent=True
- Patching product.product.default_code with company_dependent=True

even though there is no actual issue (ok normal behavior)

The main problem is that this makes Odoo.sh production branches appear not with green status, while the update module is actually fine.

Desired behavior after PR is merged:

Keep the same mechanism, but lower the log level from WARNING to DEBUG.
This aligns the behavior with the "translate=True" patch logic, which is already logged at DEBUG.
Having the production branches green.



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

Forward-Port-Of: odoo/odoo#258444
Forward-Port-Of: odoo/odoo#258326

Before this commit, when in inbox mobile and scrolling & swiping on inbox notifications, the message actions was displayed at the same time.

Steps to reproduce:
- have Admin with "Handle in Odoo" Notification preferences
- have some messages in Inbox (e.g. receive @ mentions from chatter)
- open Inbox in Discuss app in mobile, and scroll up / swipe horizontally on each message

=> this opens message actions in bottom sheet

This happens because when scrolling up/down or swiping left/right on a message, this is triggering a longpress. The longpress has some dedicated code to detect that there's no scrolling or swipe at the same time, however since 1 the action swiper was changed and made this regression. This happens because 1 introduced some
`ev.stopPropagation()` on touch event, which are crucial for the hook useLongPress() to determine whether a scroll or swipe is occuring. Because the events have been stopped, the useLongPress() wrongly assumes the user triggers a long press.

One could think we could use capture in useLongPress(), which is generally the way to prevent this issue. However, ActionSwiper is stopping propagation at the capture mode, therefore giving no chance for useLongPress() to detect the touch events.

Thankfully the capture event listener target is the `ActionSwiper` itself, so one solution is to register in capture mode in a broader scope like `window`. This commit fixes the issue by registering on `capture` of the touch event on `window` for `useLongPress()`.

Task-6008171

Scroll up in inbox, Before / After:
![before](https://github.com/user-attachments/assets/14453752-e6bb-41ed-8947-969680222588)
![after](https://github.com/user-attachments/assets/5bc5ce81-4088-4b37-bb37-c18ffd2d5da7)

Forward-Port-Of: odoo/odoo#258172

Steps to produce:
---
- Install the `E-commerce` module.
- Configure a product with a very large price.
- Open the product on the website, add it to the cart, and navigate to the cart.

Issue:
---
- The quantity input group appears visually stretched, and the border rendering is inconsistent.

Root Cause:
---
- After upgrading from Bootstrap 5.1 to 5.3, border utility behavior changed. Classes like `border-end-0` no longer apply unless a base border class is also present.

Solution:
---
- Explicitly add the `border` class alongside `border-end-0` on the affected elements to restore the intended border styling.

Before:
---
<img width="822" height="185" alt="image" src="https://github.com/user-attachments/assets/6478083e-f5c1-4374-9c9a-979254eaee3d" />

After:
---
<img width="828" height="188" alt="image" src="https://github.com/user-attachments/assets/5a1cb138-c9a5-4508-ad34-64d988904407" />


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

Forward-Port-Of: odoo/odoo#258777
Forward-Port-Of: odoo/odoo#256797

When buttons (`a.btn` elements) are translated inline, or badges (`span.s_badge`), the background color that shows the status of the translation appears under the background of the button/badge. The status is thus only visible on the surrounding text, and completely invisible when the button is alone (unless it has a transparent background).

This commit adds a plugin in translate mode which adds a span with the color of the translation status in the problematic elements if they are inside a translation span and have a background color.

Steps to reproduce:
- Open website builder
- Drop the `s_banner` snippet (or add a button by typing `/button`)
- Add a second language
- Open in translate mode
- Bug: the text of the button does not have the green/yellow highlight that shows the translation state (technically, it is hidden under the background of the button, which you can see if you set a transparent background on the button)

`o_translate_inline` on links:
  - 8fe88de0d5cc61395721cd8bda7b7ef2ea961760
  - f65ac79631180e77aca5a53fc557b3e1acfcbd65
  - 6aef5ee411656ec400e92fcc2bbd62e420645e0e

task-6038029

Forward-Port-Of: odoo/odoo#258396
Forward-Port-Of: odoo/odoo#254000

**Problem:**
cogs is 0 if the delivery is multi steps with only first 
picking validated. 

**Steps to reproduce:**
- set the warehouse as 2 steps delivery
- create a tracked product avco perpetual
- set a cost of 10$ and a positive quantity
- create and confirm a SO for 1 quantity
- validate only the first picking
- create and confirm the invoice

**Current behavior:**
there is no cogs lines in the invoice

**Expected behavior:**
there should be cogs line for a cost of 10$

**Cause of the issue:**
to compute the unit price of the cogs we use 
_get_cogs_value()
https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/account_move.py#L122
Inside _get_cogs_value(), because there is done moves, 
we use _get_cogs_price_unit()
https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/account_move_line.py#L67-L68
But because there is no valued quantity (because the done 
moves are internal), the return value will be 0.
https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/stock_move.py#L251-L253
So the cogs will have an amount of 0 and no line will be created
https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/account_move.py#L125-L126

**fix**
The fix for consigned products introduced by this PR https://github.com/odoo/odoo/pull/255043
was working for the wrong reasons. 
_get_valued_consigned_qty() only works if the 
moves are partially consigned. 
If the move is fully consigned, _is_consigned_value_line() 
will return False for every move line.
https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/stock_move.py#L650-L651
That's because if the move is fully consigned, _is_in() 
and _is_out() will return False. 
https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/stock_move_line.py#L72-L74
So it only works if the move is not fully consigned 
because _is_in() or _is_out() will be True thanks to 
the non consigned line.
https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/stock_move.py#L511-L519

However, _get_cogs_price_unit() still worked fine for fully 
consigned moves because if the move is fully consigned, 
total_qty will be 0 and the return value will be 0
https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/stock_move.py#L251-L253

But this was hacky and prevented us to address the issue of this PR. 
The logic should be:
If there is no quantity to value (consigned + not consigned) 
we fallback on the standard price (just as if there is no move).
This solves the issue of this PR because no moves were 
valued moves in our use case.
If there is a quantity to value (and we're in a case where we want
the average move value), we use the average move value (which 
will be 0 if all the moves are consigned)

opw-6001694

Forward-Port-Of: odoo/odoo#256383

# How to reproduce
- Go to Website app > Configuration > Websites > Select your website > Custom Code
- In the "Custom <head> code" section add the script given at the last section of this PR (with a proper TAG_ID)
- Go to a new Incognito Tab and go to the Website front page
- Refuse the optionnal cookies
- Open the browser's console and go to Application > Storage > Cookies

# The problem
The Google Ads cookies are present (prefixed by _ga)

# Why
This commit introduced the blocking of 3rd party cookies :

https://github.com/odoo/odoo/commit/958b41c4acec7e1700ca4d6e0b25ee0ad2aac9f1

It works by doing 2 things, but none of them works in our case :

First, it edits the view rendering to replace the `src` value with "about:blank" for watched
tags, but this does not work for `website.custom_code_head` (our case) and `website.custom_code_footer` because it is t-out'ed which bypasses this code :

https://github.com/odoo/odoo/commit/958b41c4acec7e1700ca4d6e0b25ee0ad2aac9f1#diff-a27798e1ecfe96676dd48766e0aa9d12fbc0784e328ac1a3ec82b1ce199fc58bR121-R166

Second, it adds a script in the head of the page that patches the setter for the `src`
property of the script tags. If the value that we try to set is a URL to a site that we
block and the cookies are not yet accepted, we replace the `src` value with "about:blank".

https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/website/static/src/js/content/cookie_watcher.js#L8

This sadly does not work for parser-inserted scripts that are directly parsed from the HTML.
Indeed, they do not use the setter of `HTMLScriptElement.prototype`.

It is possible to verify this by adding a `MutationObserver` that checks for new script
insertions and adding breakpoints in this observer and in the patched setter. For the
first scripts of the page, the breakpoint in `MutationObserver`is triggerred while the
 one in the setter is not.

# Proposed solution
We move this code into new helper functions :
https://github.com/odoo/odoo/blob/95dc247ecd773044ef9c9f1512c7d86d73df836c/addons/website/models/ir_qweb.py#L130-L135

And use these helper functions to create another helper function that allows us to check
an html field for trackers that would need to be removed

We then use this helper function on `website.custom_code_head` and `website.custom_code_footer`

# The script
```html
<!-- Google tag (gtag.js) -->
  <script async src="[https://www.googletagmanager.com/gtag/js?id=TAG_ID"></script](https://www.googletagmanager.com/gtag/js?id=TAG_ID%22%3E%3C/script)>
  <script>
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments);}
    gtag('js', new Date());

    gtag('config', 'TAG_ID');
  </script>
```
Source : https://developers.google.com/tag-platform/gtagjs

opw-6007810

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

Forward-Port-Of: odoo/odoo#258469
Forward-Port-Of: odoo/odoo#256808

Currently, in the mass mailing editor, an error occurs when a user replaces an image with an illustration.

Steps to reproduce:
1. Open the mass mailing editor
3. Drag and drop a snippet containing an image
4. Double-click on the image
5. In the image search bar, type "test" and press `Enter`
6. Select an illustration

=> A traceback is raised.

When an illustration is selected, it is automatically stored as an attachment with the mimetype `image/svg+xml; charset=utf-8`. The editor then loads the image using the attachment URL (e.g. `/html_editor/shape/illustration/usability-testingsvg-258?...`).

When the media dialog is closed (via `on_media_dialog_saved_handlers`), the editor attempts to process the image and calls the `/html_editor/get_image_info` route to retrieve the image info. This route retrieves the corresponding attachment from the database using the attachment url, but filters results based on a predefined set of allowed mimetypes.

The issue arises because this set does not account for valid mimetypes that include optional parameters such as `charset=utf-8`. As a result, the attachment is not found, preventing the image from being processed and ultimately causing the crash. To fix the issue, we will update the domain used to retrieve image attachments so that it accepts valid mimetypes with optional parameters (e.g. `image/svg+xml; charset=utf-8`).

During image processing, the transformed image is temporarily encoded in base64 and stored in the src attribute. When the record is saved, this base64 image is converted into a new attachment via the `/html_editor/modify_image/<id>` route. **This conversion step is necessary because many email clients have limited support for SVG images. Converting the illustration to PNG ensures better compatibility and visibility across mail clients.**

After conversion, the image url is then set to `/html_editor/shape/illustration/335/usability-testingsvg-258?...` This URL is handled by the `html_editor/shape/<module>/<path:filename>` route. Its purpose is to process SVG files and dynamically adjust their colors based on query parameters (e.g. the `c1` parameter).

However, once the image has been converted to PNG, this logic no longer applies. To address this, an additional conditional check will be introduced: if the file is not an SVG, the route will bypass the SVG-specific transformation logic and instead serve the image directly.

Task-5977962

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

Forward-Port-Of: odoo/odoo#255134

## Issue:
When viewing purchase order lines, the system attempts to compute the unit
price for downpayment lines. This results in unintended behavior.

## Cause:
PR https://github.com/odoo/odoo/pull/236669 introduced the `price_unit_product_uom` field 
along with its compute method `_compute_price_unit_product_uom` to manage PO comparison.
Although the compute method correctly skips section and note lines, it does
not exclude downpayment lines. Downpayment lines are identified by the
`is_downpayment` field, which was introduced earlier in PR https://github.com/odoo/odoo/pull/176137.
As a result, the computation is incorrectly applied to downpayment lines.

## With this commit:
The UoM price computation is prevented for purchase order lines where
is_downpayment is set to True. Downpayment lines are now treated
similarly to section and note lines to prevent unintended price recalculations.

Steps to reproduce : [Video](https://drive.google.com/file/d/1JrMN8x-i86QjRfMnaeYu-Jac03iFoJs3/view?usp=drive_link)

OPW - 5930652

Forward-Port-Of: odoo/odoo#251259
Forward-Port-Of: odoo/odoo#249989

**Description of the issue/feature this PR addresses:**
The `Store.getMentionsFromText` method fails to identify mentions for users with special characters (&, <, >) in their names. Because the function processes raw HTML, these characters are encoded as entities, causing them to be [filtered out](https://github.com/odoo/odoo/blob/a2b3a10255dba290ea462b9193ae11c54d8dd5e0/addons/mail/static/src/core/common/store_service.js#L599-L601)

In order to resolve this, I translate the entities back into their normal representation, allowing our includes to find them.

**Steps to reproduce bug:**
1) Create a user with a name containing &, <, >
2) Set it so they receive emails for notifications
3) Mention them in a long note
4) Observe that no email is sent

**Current behavior before PR:**

https://drive.google.com/file/d/1itBlz6havFmFi2G3mbOm3qh2_WH6uM76/view?usp=drive_link

**Desired behavior after PR is merged:**

https://drive.google.com/file/d/1PC2_hjBAhhC6ZSOEzs9SPYjSHrZbaplp/view?usp=drive_link

opw-5895188

Forward-Port-Of: odoo/odoo#258499
Forward-Port-Of: odoo/odoo#249350

**Steps to reproduce:**
* Install `l10n_sa_edi` module.
* Create a parent company and a child company, both with the same VAT number.
* Onboard the parent company's Sales journal with ZATCA.
* Onboard the child company's Sales journal with ZATCA. Create a journal for the child if there is no journal.
* Change the child company's ZATCA API mode to any other mode.

**Observed behavior:**
* Changing the child company's API mode resets and unboards the parent company's Sales journal as well.

**Cause:**
* In `res.company.write`, when `l10n_sa_api_mode` changes, journals to reset are fetched using `_check_company_domain(company)`.
* `account.journal` uses `check_company_domain_parent_of`, which returns journals where `company_id` is a parent of the given company — so passing a child company also matches journals belonging to the parent.

**Fix:**
* Replace `_check_company_domain(company)` with a direct `('company_id', '=', company.id)` filter, so only journals strictly owned by the company being modified are reset.

opw-6099340

Forward-Port-Of: odoo/odoo#258750
Forward-Port-Of: odoo/odoo#258006

In version 19.1, an error occurs when inviting a new user via General Settings and then clicking Manage Users:
"The operation cannot be completed: A user cannot be linked to multiple employees in the same company."

This happens even when logged in as an admin user with an existing linked employee. The issue stems from the `employee_id` field in the `res_users` model being a context-dependent computed field.

The `self.env.cache` lacks the employee data,
specifically `'res.users.employee_id': {(1, (2, True)): {2: None}}`.

To resolve this, i've used invalidate_recordset for proper clean the cache,
and again get the value of employee_id.

Clicking directly on "Manage Users" sometimes we cannot face an error, possibly a caching issue.
Inviting a user before accessing "Manage Users" results in an error,

<img width="1885" height="964" alt="2026-03-25_16-21" src="https://github.com/user-attachments/assets/8cd7d094-b0ce-42ca-a43f-1081de7ddc70" />

[opw-6041866](https://www.odoo.com/odoo/project/70/tasks/6041866)
[upg-4031096](https://upgrade.odoo.com/odoo/request/4031096)

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

**Steps to reproduce:**
* Install the *Purchase* module
* Create a product and set an *Reference* and
  Under the *Purchase* tab, add a vendor and define a *Vendor Product Code*.
* Create a Purchase Order with the same vendor set as on the product.
* Add the configured product to the *Purchase Order Lines*.
* Add the same product again on a second line and save the order.
* Activate debug mode
* Go to the view:Form and add a limit to have only 1 POL per page
* Return to your PO
* Go to the second page

**Observed behavior:**
* The *product display name* in the purchase order lines is different on
  the second page compared to the first page.

**Cause:**
* On the first page, purchase order lines are fetched via a web_read on the
purchase order.
* On subsequent pages, lines are fetched via a web_read directly on the
purchase order lines.
* The client requests both name and product_id.display_name.
product field context includes partner_id, causing
product_id.display_name to be computed as the vendor name.
* As both values resolve to the vendor name, the original product
name is lost, leading to inconsistent display across pages.

**Note:**

A similar issue was addressed in this commit : https://github.com/odoo/odoo/commit/28d53e0e565e266ca3fa2b67e359b4383fa42c36
* but its consequence it breaks the search using the vendor code/name in POL.

* That change was reverted in this commit duo to the there consequence : https://github.com/odoo/odoo/commit/c9e8a802315be27a076ae677b9191c075e4c239d

**Fix:**
* This ensures the product name is propagated correctly in the form
view while preserving search by vendor code or name.

---

opw-5170924

Forward-Port-Of: odoo/odoo#258467
Forward-Port-Of: odoo/odoo#240515

Steps to produce:
---
- Install `Sales` module.
- Create a sale order, set a product, and assign Marc Demo as salesperson in the Other Info tab.
- Confirm the sale order and create an invoice.

Issue:
---
- In the email notification sent to the salesperson, the record reference displays as False and the amount shows as 0.00.

Root cause:
---
- Here at [1], the record name is False because the invoice is still in draft state.
- In [18], _sync_invoice sets amount_currency = line.balance for new
  lines, but balance is precomputed as 0 before the INSERT because
  _compute_balance returns 0 for invoice lines. In [17] it read
  price_subtotal directly, which is always correct.
- In 17.0 the same mail fires at the same moment, but _sync_invoice
  had already set balance = −295 and amount_currency = −295 from
  price_subtotal, so the email reads the correct 295.00.

Solution:
---
- Use record.display_name instead of record.name, as display_name is always present regardless of the record state.
- Use the tax totals amount instead of amount_total, which is not yet computed on draft invoices.

[1]https://github.com/odoo/odoo/blob/0bcc34ec2f92b9b95cde321423d810002bb317ce/addons/account/models/account_move.py#L6478
[18]https://github.com/odoo/odoo/blob/b0a50104a12b205958316d382b4c7b2176395877/addons/account/models/account_move_line.py#L1566-L1610
[17]https://github.com/odoo/odoo/blob/73c076893de79df5a86aa970fde46a7aacbeaf3d/addons/account/models/account_move_line.py#L1536-L1585


Before:
---
<img width="400" height="175" alt="image" src="https://github.com/user-attachments/assets/48c2dc03-765a-49c3-bad3-fd0b14405786" />

After:
---
<img width="400" height="175" alt="image" src="https://github.com/user-attachments/assets/53682171-155f-46b3-85dd-0c7c98482067" />


opw-6023827
---

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

Forward-Port-Of: odoo/odoo#258375
Forward-Port-Of: odoo/odoo#254862

### Issue before this commit:
When creating an invoice using the child contact of a parent contact that has a different language with respect to the father, the label of the invoice line was not always displayed in the child contact language but in the father's contact language.

### Steps to reproduce the issue:
1. Activate at least 2 languages (X and Y)
2. Create a product and set the translation for that product in the activated languages
3. Create a Contact with the language X
4. Create a child contact (invoice adress type) for that contact with language Y
5. Create a new invoice setting the customer as the child contact
6. Add the product you created
7. See the label is displayed in the language of the parent contact

### Cause of the issue:
The computation of the invoice line name relied on line.partner_id.lang. However, the partner_id of the move line is automatically set to the commercial partner that can be different (can be the father's contact) to the contact used on the invoice. As a result, the product description was translated using the wrong language.

### Reason to introduce the fix:
To ensure that invoice line labels are correctly translated according to the language of the selected invoice contact, the computation now uses the language of move_id.partner_id instead of line.partner_id. This guarantees consistent and expected behavior in multilingual environments, especially when using different contacts under the same commercial partner.

opw-5955875

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

Forward-Port-Of: odoo/odoo#258458
Forward-Port-Of: odoo/odoo#254833

Steps to produce:
---
- Install the `E-commerce` module.
- Configure a product with a very large price.
- Open the product on the website, add it to the cart, and navigate to the cart.

Issue:
---
- The quantity input group appears visually stretched, and the border rendering is inconsistent.

Root Cause:
---
- After upgrading from Bootstrap 5.1 to 5.3, border utility behavior changed. Classes like `border-end-0` no longer apply unless a base border class is also present.

Solution:
---
- Explicitly add the `border` class alongside `border-end-0` on the affected elements to restore the intended border styling.

Before:
---
<img width="822" height="185" alt="image" src="https://github.com/user-attachments/assets/6478083e-f5c1-4374-9c9a-979254eaee3d" />

After:
---
<img width="828" height="188" alt="image" src="https://github.com/user-attachments/assets/5a1cb138-c9a5-4508-ad34-64d988904407" />


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

Forward-Port-Of: odoo/odoo#258572
Forward-Port-Of: odoo/odoo#256797

Steps to reproduce:
- Use a Luxembourg company
- Post a P&L result for the year and do the year-end affectation (Dr 142 / Cr 1412)
- Open the Luxembourg balance sheet (full or abbreviated)

Issue:
Line "V. Profit or loss brought forward" shows incorrect values.

Cause:
The `accounts` expression for that line used `account_codes` engine with formula `-14`,
which only sums accounts by code prefix. Account 1412 ("Results brought forward (assigned)")
was typed as `equity`, so its balance was carried forward as an initial balance instead of
being captured as retained earnings in the formula.

Solution:
- Set account 1412 to `equity_unaffected`, consistent with account 142.
- Change the `accounts` expression of Line V in both the full and abbreviated balance sheet
  to use the `domain` engine:
  `['|', ('account_id.code', '=like', '14%'), ('account_id.account_type', '=', 'equity_unaffected')]`
  with subformula `-sum`.
  This correctly captures the balance of all 14x accounts and any `equity_unaffected` accounts,
  which covers the standard year-end affectation workflow.

opw-5883505

Forward-Port-Of: odoo/odoo#253559

# How to reproduce
- Go to Website app > Configuration > Websites > Select your website > Custom Code
- In the "Custom <head> code" section add the script given at the last section of this PR (with a proper TAG_ID)
- Go to a new Incognito Tab and go to the Website front page
- Refuse the optionnal cookies
- Open the browser's console and go to Application > Storage > Cookies

# The problem
The Google Ads cookies are present (prefixed by _ga)

# Why
This commit introduced the blocking of 3rd party cookies :

https://github.com/odoo/odoo/commit/958b41c4acec7e1700ca4d6e0b25ee0ad2aac9f1

It works by doing 2 things, but none of them works in our case :

First, it edits the view rendering to replace the `src` value with "about:blank" for watched
tags, but this does not work for `website.custom_code_head` (our case) and `website.custom_code_footer` because it is t-out'ed which bypasses this code :

https://github.com/odoo/odoo/commit/958b41c4acec7e1700ca4d6e0b25ee0ad2aac9f1#diff-a27798e1ecfe96676dd48766e0aa9d12fbc0784e328ac1a3ec82b1ce199fc58bR121-R166

Second, it adds a script in the head of the page that patches the setter for the `src`
property of the script tags. If the value that we try to set is a URL to a site that we
block and the cookies are not yet accepted, we replace the `src` value with "about:blank".

https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/website/static/src/js/content/cookie_watcher.js#L8

This sadly does not work for parser-inserted scripts that are directly parsed from the HTML.
Indeed, they do not use the setter of `HTMLScriptElement.prototype`.

It is possible to verify this by adding a `MutationObserver` that checks for new script
insertions and adding breakpoints in this observer and in the patched setter. For the
first scripts of the page, the breakpoint in `MutationObserver`is triggerred while the
 one in the setter is not.

# Proposed solution
We move this code into new helper functions :
https://github.com/odoo/odoo/blob/95dc247ecd773044ef9c9f1512c7d86d73df836c/addons/website/models/ir_qweb.py#L130-L135

And use these helper functions to create another helper function that allows us to check
an html field for trackers that would need to be removed

We then use this helper function on `website.custom_code_head` and `website.custom_code_footer`

# The script
```html
<!-- Google tag (gtag.js) -->
  <script async src="[https://www.googletagmanager.com/gtag/js?id=TAG_ID"></script](https://www.googletagmanager.com/gtag/js?id=TAG_ID%22%3E%3C/script)>
  <script>
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments);}
    gtag('js', new Date());

    gtag('config', 'TAG_ID');
  </script>
```
Source : https://developers.google.com/tag-platform/gtagjs

opw-6007810

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

Forward-Port-Of: odoo/odoo#256808

Description of the issue/feature this PR addresses:

During a module update (-u ModuleName), the check introduced by #220983 patches temporarily a field with "company_dependent=True" because the overriding module is not loaded yet.

But currently it is logged as a warning and makes Odoo.sh production branch appears in yellow (warning state), while the update is actually fine.

Current behavior before PR:

Logs may contain warnings such as:

- Patching res.partner.ref with company_dependent=True
- Patching product.template.sale_ok with company_dependent=True
- Patching product.product.default_code with company_dependent=True

even though there is no actual issue (ok normal behavior)

The main problem is that this makes Odoo.sh production branches appear not with green status, while the update module is actually fine.

Desired behavior after PR is merged:

Keep the same mechanism, but lower the log level from WARNING to DEBUG.
This aligns the behavior with the "translate=True" patch logic, which is already logged at DEBUG.
Having the production branches green.



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

Forward-Port-Of: odoo/odoo#258444
Forward-Port-Of: odoo/odoo#258326

**Steps to reproduce:**
* Install `l10n_sa_edi` module.
* Create a parent company and a child company, both with the same VAT number.
* Onboard the parent company's Sales journal with ZATCA.
* Onboard the child company's Sales journal with ZATCA. Create a journal for the child if there is no journal.
* Change the child company's ZATCA API mode to any other mode.

**Observed behavior:**
* Changing the child company's API mode resets and unboards the parent company's Sales journal as well.

**Cause:**
* In `res.company.write`, when `l10n_sa_api_mode` changes, journals to reset are fetched using `_check_company_domain(company)`.
* `account.journal` uses `check_company_domain_parent_of`, which returns journals where `company_id` is a parent of the given company — so passing a child company also matches journals belonging to the parent.

**Fix:**
* Replace `_check_company_domain(company)` with a direct `('company_id', '=', company.id)` filter, so only journals strictly owned by the company being modified are reset.

opw-6099340

Forward-Port-Of: odoo/odoo#258750
Forward-Port-Of: odoo/odoo#258006

The _compute_cumulated_balance() method performs a query over every
existing move lines to get a dict associating the record id with
the cumulated sum at this point.

When there is a lot of move lines, the result returned by fetchall()
hits the memory limit and the server crashes.

We propose to encapsulate the original query to only return
the result for the account move lines present in self.

Benchmarks
---------------

The following benchmarks were generated with a customization of
the account.move.line list view to display the cumulated_balance
field.

Memory usage during the self.env.cr.execute and the dictionary
population:

|     Operation | Before the fix | After the fix |
|---------------|----------------|---------------|
| populate dict |         1.5 GB |       17.1 MB |
| execute query |         430 MB |        8.3 MB |

100 000 lines were displayed at the same time to get a significant
size.
So the number of records in self is more than 7 000 000 without
the fix and 100 000 with the fix.

Time spent in the _compute_cumulated_balance method:

| No of AML | Before the fix | After the fix |
|-----------|----------------|---------------|
| 7 000 000 |         10.4 s |         6.8 s |

opw-6053720

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

Forward-Port-Of: odoo/odoo#256658
Forward-Port-Of: odoo/odoo#255780

Bug reproduction:
    1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
    2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
    3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
    4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.

Bug cause:
    1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
    2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear

Bug solution:
    1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"

Tests:
    1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
    2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)

Last Test Update:
    1 - I noticed that contract date changes was not affecting the warning appearance directly
    2 - Unit test is expanded with contract date change and observing the warning appearance

Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.

task - 6006693

Forward-Port-Of: odoo/enterprise#113566
Forward-Port-Of: odoo/enterprise#112758

In German location with Fiskaly setup.
POS users hit an AccessError on read when closing the session from the frontend,
then had to finish closing in the backend with admin (base.group_erp_manager) rights.

Steps to reproduce:
-------------------
* Enable Germany + Fiskaly POS (l10n_de_pos_cert), with a company registered for Fiskaly
* Use a user with POS rights only (no Access Rights)
* Open POS, sell, then close the session from the POS UI

> Observation:
A warning redirects to the back end; manual close shows: insufficient rights to read l10n_de_fiskaly_api_secret on res.company (operation read).

Why the fix:
------------
The guard only needs to know whether the company is in the Germany + Fiskaly flow; that is
already expressed by l10n_de_is_germany_and_fiskaly(), without reading API credentials.
Fiskaly RPC helpers on res.company continue to use sudo() where secrets are required;
this change fixes unnecessary reads of protected fields in the tax helper,
not the security model of the credentials themselves.

opw-6074960

**Steps to reproduce:**
- Set up an event, go put it's state to Annonced
- Set up any online payment method (Demo also triggers the bug)
- Go to a PoS that sells the event tickets
- Purchase one and pay with the online payment method
- Once on the ticket screen, the button to download the event tickets is not displayed

**Why the fix:**
The normal flow only works for offline payment methods, because we check if the ordered is either paid or invoiced before setting all the values needed by the frontend regarding the ticket registration.

The problem is that with an online payment method, once we enter the **read_pos_data** method that sets
the values for the frontend, the order is still in draft, so we just return without doing anything.

We now set the values regardless of the order's status and send the confirmation mail in the same way as if it was an online payment.
In the case of an online payment, the mail will be sent by the **action_pos_order_paid** function that is called once the payment is processed.

A test might be a bit weird to make as we don't have a bridge for pos_online_payment and pos_event, and that we would need to mock the server's answer to be able to pay for the online payment and check that we have the needed values. So the setup for pos_event would have to be copied into pos_online_payment to test it and it would only be ran if both modules are installed.

opw-5438432

Forward-Port-Of: odoo/odoo#249306

**Problem:**
When printing an invoice in English (LTR report) with a product whose name contains Arabic text and parentheses (e.g., لوحة توزيع كهربائية 100 أمبير (شنايدر )), the brackets appear in the wrong position in the generated PDF.

**Steps to reproduce:**
1. Create a product named: لوحة توزيع كهربائية 100 أمبير (شنايدر )
2. Create an invoice with that product
3. Print the invoice PDF in English
4. Observe the brackets are misplaced in the description column

**Current behavior:**
Parentheses appear detached from the Arabic word they enclose, floating at the wrong end of the text.

**Expected behavior:**
Parentheses correctly wrap the enclosed Arabic text.

**Cause of the issue:**
Odoo's report CSS sets `direction: ltr` on elements that are ancestors of the line description span. When CSS `direction: ltr` targets the same element as `dir="auto"`, wkhtmltopdf's WebKit engine lets the CSS rule win, keeping the paragraph base direction as LTR. The Unicode BiDi algorithm then resolves parentheses (neutral characters) using LTR as the base direction, misplacing them.

**Fix:**
Placing `dir="auto"` directly on the `<span>` that renders the line description — rather than the parent `<td>` — avoids the CSS override. wkhtmltopdf then detects the first strong character (Arabic) and uses RTL as the base direction for that span, allowing the BiDi algorithm to correctly position the brackets.

opw-5884712

Forward-Port-Of: odoo/odoo#257881
Forward-Port-Of: odoo/odoo#251190

Steps to produce:
---
- Install the `Sales` module.
- Enable discounts from settings.
- Create a Sale Order with a negative discount on an order line.
- Preview the Sale Order and click on the view details button.

Issue:
---
- Negative discount values are not shown in the preview (portal view), but they are displayed in the generated PDF.

Root cause:
---
- At [1], the portal template includes a condition to display discounts only when they are greater than 0, while the report templates lack this check, leading to inconsistent behavior.

Solution:
---
- Applied the same condition in the report templates to align the PDF output with the portal preview behavior.

Before:
---
<img width="787" height="136" alt="image" src="https://github.com/user-attachments/assets/d32311be-4aec-4d6f-b905-d5e52f712ba4" />

After:
---
<img width="775" height="139" alt="image" src="https://github.com/user-attachments/assets/2614a8ad-dca6-49ca-b720-5c234aa91cf6" />


[1]https://github.com/odoo/odoo/blob/0f463fd247d2f5da79d6ec2b6bec18774f6f600b/addons/sale/views/sale_portal_templates.xml#L539

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

opw-6061568

Forward-Port-Of: odoo/odoo#258614
Forward-Port-Of: odoo/odoo#255735

Bug reproduction:
    1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
    2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
    3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
    4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.

Bug cause:
    1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
    2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear

Bug solution:
    1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"

Tests:
    1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
    2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)

Last Test Update:
    1 - I noticed that contract date changes was not affecting the warning appearance directly
    2 - Unit test is expanded with contract date change and observing the warning appearance

Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.

task - 6006693

Forward-Port-Of: odoo/enterprise#113566
Forward-Port-Of: odoo/enterprise#112758

Currently, customers report errors when connecting or refreshing a
Shopee account through the `sale_shopee` module.

**Steps to reproduce:**
- Install and configure the `sale_shopee` module
- Attempt to connect a Shopee account via the onboarding flow
- Complete the authorization process

**Observed behavior:**
An error is raised during the authorization callback, preventing the
Shopee account from being connected or refreshed.

**Root cause:**
In `onboarding.py`, the `shopee_return_from_authorization` controller
incorrectly uses `utils.with_context(authorization_code=code)`. Since
`utils` is an imported Python module, calling `with_context` on it
attempts to set the context on the module itself rather than on a
model instance, which raises an error.

**Solution:**
Move the `with_context` call from the `utils` module to the `temp_shop`
record, which is the appropriate model instance that needs the context.

Additionally, this commit adds regression tests for the controller to
prevent future regressions, as this functionality was previously
untested.

opw-6092524

**Steps to reproduce:**
1. Install `invoice` module.
2. Create a Vendor Bill, confirm it, and register payment.
3. Observe that Bill is marked `Paid`, but Payment status remains `In Process`.

**Issue:**
When paying a Vendor Bill, the payment remains in the `In Process` state even after the Bill is fully paid, unlike Customer Invoices where the payment correctly transitions to `Paid`.

**Cause:**
The discrepancy occurs because the system checks linked invoices to update the payment status but fails to check linked bills.

In `account.payment`, the `_compute_state` method only checks [reconciled_invoice_ids] to determine if the payment should transition from `In Process` to `Paid`. It ignores `reconciled_bill_ids` (Vendor Bills).

**Fix:**
Update code to check both `reconciled_invoice_ids` and `reconciled_bill_ids`. If all linked invoices or bills are paid, the
payment status is updated to `Paid`.

Related PR : [#231243](https://github.com/odoo/odoo/pull/231243/changes#diff-143d17de807d23650088a8c12f0a5b5cc2246b1b51e0bb7634e85247b6e535eaR392)


opw-5865798

The invoice outstanding credits/debits widget currently displays all reconcilable items for a partner across the same account, regardless of the company they belong to.

In multi-company environments, specifically when accounts have been merged, this allows users to see
and try to reconcile payments from Company A into an invoice from Company B. This action eventually triggers a validation error stating that entries must belong to the same company.

This commit adds a company filter to the widget's logic to ensure only relevant outstanding payments are suggested, preventing cross-company reconciliation errors and improving UX.

**Description of the issue/feature this PR addresses:**
This PR fixes a validation error in multi-company environments where the invoice_outstanding_credits_debits_widget suggests payments or credit notes belonging to a different company than the current invoice.

The issue typically arises when a partner has outstanding transactions in multiple companies and the accounts (e.g., Account Receivable) have been merged, allowing the widget to query lines that are not valid for the current record's company context.

**Current behavior before PR:**
When viewing an invoice for Company A, the "Outstanding Credits/Debits" widget displays all reconcilable account.move.line records for that partner that match the account type, regardless of their company_id.

If a user clicks "Add" on a payment that belongs to Company B, Odoo attempts to reconcile them, resulting in a traceback or a validation error:

"Invalid Operation: All tracebacks/entries must belong to the same company."

This creates confusion for the end-user, as they are presented with "ghost" credits that cannot actually be applied.

**Desired behavior after PR is merged:**
The invoice_outstanding_credits_debits_widget (and the underlying logic in account.move) will strictly filter the suggested outstanding items by self.company_id.

Users will only see and be able to reconcile payments, credit notes, or debits that belong to the same company as the invoice they are currently processing. This ensures data integrity and a seamless UX in multi-company setups.

**Steps to reproduce:**
1) Enable Multi-Company: Ensure you have at least two companies (e.g., Company A and Company B) active in your database.

2) Chart of Accounts Setup:

In both companies, use the same account for Receivables (or merge them so they share the same ID/Code if testing a migrated environment).

3) Ensure the account is marked as Allow Reconciliation.

4) Create a Payment in Company B:

5) Post the payment so it remains as an "Outstanding Receipt".

6) Create an Invoice in Company A

7) Confirm/Post the invoice.

8) Check the Widget:
Scroll down to the bottom of the Invoice form in Company A.

9) Observe the "Outstanding Credits" widget.

The Error:
The payment from Company B will appear as an available credit for the invoice in Company A.

10) Click on "Add".

A validation error (UserError) will pop up: "All entries must belong to the same company."

**video**
https://drive.google.com/file/d/1PfBxupP8t-t21wsP2FIgNXFnTP0Zq140/view

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

### Issue before this commit:
When generating the electronic invoice XML (FatturaPA) with units of measure containing non-standard Unicode characters (e.g. m², m³), the resulting XML fails validation, as these characters are not accepted by the SdI format.

### Steps to reproduce the issue:
1. Download Italian loc + electronic invoicing
2. Activate UoM option in settings
3. Set a product UoM in any unit that has an apex/power of (ex. m2, m3)
4. Invoice this product
5. Create the XML for SdI
6. Check format with Fex > apex is not recognised as a valid character

### Cause of the issue:
The UoM name is exported as-is into the XML. Non-standard Unicode characters are preserved during formatting and are not compatible with the allowed character set defined by the FatturaPA specifications.

### Reason to introduce the fix:
Ensure that units of measure are normalized into a compatible representation before being included in the XML, so that the generated file complies with SdI validation rules.

opw-6075119

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

Forward-Port-Of: odoo/odoo#257012

Pre-requisites:
------------------------------------------
1. Install `sale_project` and `project_account_budget` modules
2. Have two companies configured in the system
3. Enable Timesheets from the Settings app
4. Create two projects (one for each company)
5. Ensure the following settings are enabled on both projects:
     * Timesheets
     * Billable

Steps to Reproduce:
------------------------------------------
1. Switched to Company A
2. Create a product with:
    * Type: Service
    * Create on Order: Task
    * No company restriction
3. Set the product's `project_id` to Company A's project
4. Switch to the newly created company (Company B)
5. Set the product's `project_id` to Company B's project
6. Enable Analytic Distribution from SOL Optional
7. Create a sale order with the configured product, and delete the auto-fetched
Analytic Distribution account for the sale order (Company B's project)
8. Now confirm the sale order

Observation:
----------------------------------------
The SOL's analytic distribution uses the analytic account from Company A's project instead of Company B

Issue:
----------------------------------------
The `project_id` field on `product.template` is `company_dependent=True`, meaning it stores different values per company. However, in `_compute_analytic_distribution()`, the code accesses `line.product_id.project_id` without calling `with_company`, so it resolves the field using the wrong company context

Solution:
----------------------------------------
using `with_company()`, the correct company context is applied when accessing
`project_id`, preventing inconsistencies in multi-company environments and
ensuring the appropriate project is used for the corresponding company.


opw-5864452

__ISSUE__:
- FIFO balance miscalculation for non-overlapping allocations. cumulative_allocated_days was partitioned globally by (employee, leave_type), but taken_per_allocation scoped leaves to each allocation's date range. This caused the FIFO formula to silently absorb leaves from one period into another's allocation capacity.

ex:
    Alloc A (20 days) 2025, taken leaves 15 days
    Alloc B (20 days) 2026, taken leaves 5 days

    report: 2025: (15 taken), (5 left)
            2026: (7 taken), (20 left)

- Left" rows shifted by one year in non-UTC timezones. Allocation date_from/date_to (Date fields) were cast to timestamp as midnight UTC. In negative-UTC /positive-UTC timezones midnight UTC of Dec 31 renders as the prev/next day.

__FIX__:
- detect overlap groups using a running MAX(date_to) and partition the cumulative sums within each overlap group. This way non-overlapping allocations are treated as independent, while overlapping or open-ended allocations still share FIFO within their group.

- offset allocation dates by 12 hours so no timezone can shift them across a day boundary.

- opw-5169606
- opw-5352114

**Description of the issue this PR addresses:**

On mobile devices, the chat composer becomes unresponsive when the navigation menu `navbar-toggler` is open.


https://github.com/user-attachments/assets/8ef01ec6-4a44-41d3-8b86-74f68caf47ef


Steps to reproduce:
1. Open the website in a mobile view.
2. Tap the navbar toggler to open the mobile menu.
3. Without closing the menu, open the chat window.
4. Tap on the message composer text area.

→ The composer is not accessible.

This happens because the bootstrap `Offcanvas` (used by the `navbar-toggler`) traps focus by listening for `focusin` events bubbling up to the document. When the composer is tapped, the Offcanvas intercepts the event and immediately steals focus back to itself, dismissing the virtual keyboard.

This commit stops the event propagation at the composer level, ensuring the composer can reliably retain focus in responsive views without interference from active menus.

Task-[5954657](https://www.odoo.com/odoo/project/1519/tasks/5954657)

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

Forward-Port-Of: odoo/odoo#250294

# How to reproduce
- Go to the website editor
- Add a Masonry block
- Add a Form inner block in the Masonry block
- Select any fields of the form
- Set it's visibility to Hidden
- Save

# The problem
The field is still visible.

# Cause
When a field has its visibility set to hidden, it is applied the
`.s_website_form_field_hidden` CSS class which applies `display: none`.

https://github.com/odoo/odoo/blob/995629db3231de944710751c3184bf1b8b1355c7/addons/website/static/src/snippets/s_website_form/001.scss#L26-L28

But that CSS rule is overriden by the masonry's
`.s_masonry_block[data-vcss='001'] .row > div` CSS class.

https://github.com/odoo/odoo/blob/995629db3231de944710751c3184bf1b8b1355c7/addons/website/static/src/snippets/s_masonry_block/001.scss#L1-L3

https://github.com/odoo/odoo/blob/995629db3231de944710751c3184bf1b8b1355c7/addons/website/static/src/scss/website.scss#L3246

# Proposed solution
We set `display: none` with `!important` to prevent it from being overidden.
We also need to add `!important` to its edit mode
counter-part so that the field is still visible in that mode.

opw-6038955

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

Concurrent processing of emails with the same `Message-Id` can create duplicate records.

### Steps to reproduce

1. Configure multiple mail aliases (e.g., two helpdesk teams).
2. Send one email with both aliases as recipient.

The Mail Transfer Agent may invoke `odoo-mailgate.py` once per recipient, resulting in concurrent processing of the same email in separate transactions.

We expect one record per alias/team, but duplicates may be created.

### Cause

This is a race condition in the `Message-Id` deduplication logic, caused by concurrent transactions and PostgreSQL snapshot isolation.

Odoo uses the `REPEATABLE READ` isolation level. This means that each transaction takes a snapshot of the database at its first query and cannot see changes committed by other concurrent transactions.

When two concurrent transactions process the same email:

1. Both enter `message_process` and take their snapshot.
2. Both search for the `Message-Id`. Because their snapshots don't include each other's work, both find nothing.
3. Both create records.

Even if one transaction commits before the other performs the check, the second transaction still uses its original stale snapshot and create duplicates.

### Fix

After the initial duplicate check, attempt to acquire a transactional advisory lock on a hash of the `Message-Id` using `pg_try_advisory_xact_lock`. If another transaction is already processing the same email and holds the lock, the call returns false and the email is treated as a duplicate. If the lock is acquired, processing continues as normal.

opw-5116492

[FIX] project_timesheet_holidays: Exclude archived employees from time-off 

# Description of the issue/feature this PR addresses:
## Steps to Reproduce:
1. Create a time off for Employee A (it should affect the timesheets).
2. Create a new public holiday (global time off) that overlaps with Employee A’s time off.
3. Archive Employee A.
4. Delete the public holiday created in step 2.
5. An error related to timesheet generation appears.

## Expected Behavior:
- The public holiday / global time off should be deleted without any error.

# Desired behavior after PR is merged:
## Fix (Implemented):
When regenerating timesheets due to changes in holidays or time off, leaves related to archived employees should not be taken into account. A check was added inside the `_generate_timesheets` function in `project_timesheet_holidays/models/hr_holidays.py` to exclude leaves belonging to archived employees.

## Alternative Fix (Not Implemented):
Instead of filtering out leaves linked to archived employees, we could delete those leaves when an employee is archived. However, this approach is not ideal, as archived employees may be reactivated later and would still need their previously requested time off to be preserved.

 ## Version:
 This bug appears in both version 17.0 and 19.0. I assumed that it also appears in 18.0  but didn't directly test

## Task:

[5474038](https://www.odoo.com/odoo/project/4105/tasks/5474038)

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

### Description of the issue/feature this PR addresses:

This error only exists in the 17.0 version
- In the 16.0 version, it doesn’t select other companies in the navigation bar and doesn’t give an access error as well
- In the 17.4 and 18.0 versions, it selects other companies in the navigation bar and doesn’t give an access error as well

I backported the fix from the below-attached PRs:
- https://github.com/odoo/odoo/pull/157399/files#diff-706c5300f0b758ed43a362c85fa84a655c8bae12339bd882e98dc419623facc2R207
- https://github.com/odoo/odoo/pull/160730/files#diff-c28b3e2d6bbe6f94bf95e9cbbe228f61664ca6e1d9a4048f951d8769e2d22752L124

### Steps to reproduce the bug:
1) Create 2 companies: Company A and Company B
2) Assign Company A to the company_id field on the contact form for Company A. 
3) Assign Company B to the company_id field on the contact form for Company B. 
4) Create a user and add both companies to the allowed companies in the user record. 
5) In the navigation bar, select only one company (e.g., Company A). 
6) Attempt to open the user record from the user form, it will give an access error.

### Current Behavior before PR:
An AccessError is raised when attempting to open the user record after selecting only one company in the navigation bar.

### Desired behavior after PR is merged:
When navigating to a user record after selecting only one company in the navigation bar, the system should:
1) Automatically select the other company [similar to the behavior in version 18] 
2) Reload the page before redirecting to the specific user record 
3) Open the user record page without giving any access error.

opw-4449964



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