## Context
On the website page of a product, users can transform a picture in various ways (shape, size, cropping, etc.) when uploading it.

## Issue
When uploading a new picture, users can only replace the image or reorder it, but they cannot reshape it, crop it, or edit its size.

## Steps to reproduce
1. Install the *eCommerce* (`website_sale`) app.
2. Create a product and set a picture for it.
3. Go to that product's page in the Website app and open the website editor.
4. Click on the picture and replace it.
5. **The options to transform the picture are not displayed.**

## Cause
The transformation options are disabled due to the following static `exclude` variable in `ImageToolOption`:

https://github.com/odoo/odoo/blob/2b6b937c1c6d92e4e8b4657ae62127f0f8a7eb56/addons/html_builder/static/src/plugins/image/image_tool_option.js#L16

## Solution
We should prevent the transformation options from being displayed **only** when the image is external. In such cases, certain options from the `ImageToolOption` (such as the `ImageTransformOption` or the `ImageShapeOption`) cannot be applied. This is confirmed by the message displayed when trying to crop an external image:

https://github.com/odoo/odoo/blob/2b6b937c1c6d92e4e8b4657ae62127f0f8a7eb56/addons/web_editor/static/src/js/wysiwyg/widgets/image_crop.js#L164-L173

We can determine whether an image is external by looking at its `data-attachment-id` property. If it is present, the image was recently uploaded to Odoo.

On top of updating the `exclude` variable, we need to filter out the options that cannot be used on images from the eCommerce. These options are:
- Description
- Tooltip
- Transform (*"Transform the picture"*)
- Size

## Tests
The test checks that the behavior matches the one from previous versions: the options to edit an image are not displayed before replacing the image, but are displayed after. Both the test `image field should not be editable, but the image can be replaced` (shown below) and the new test from this PR fail if the modified `exclude` variable allow to edit the image before replacing it.

https://github.com/odoo/odoo/blob/dea5a1d28a1935c2b4d87c3c6e8c07cd874c7d6b/addons/html_builder/static/tests/image_field.test.js#L7-L16

## Options displayed
|   | Before this commit  | After this commit  | Previous versions |
|---|---|---|---|
|  **Before replacing the image**  | Media, Re-order | Media, Re-order  | Media, Re-order
|  **After replacing the image**  | Media, Re-order | Media, Re-order, Shape, Transform (crop), Filter, Format, Quality | Media, Re-order, Shape, Transform (crop), Filter, Format, Quality


opw-5251864

Forward-Port-Of: odoo/odoo#247706
Forward-Port-Of: odoo/odoo#241071

**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#259039
Forward-Port-Of: odoo/odoo#251190

[FIX] point_of_sale: detect refund+eWallet orders as refunds for invoice signs
Refund orders paid through eWallet top-up can have a net total of 0, which
made refund detection based only on negative totals inconsistent. As a result,
some refund flows were treated as normal invoices and refund tax/invoice signs
were incorrect.

Steps to reproduce:
-------------------
* Configure an eWallet program in POS.
* Create and pay a POS order for one product, then invoice it.
* Refund that order and choose eWallet as refund payment method (refund + top-up).
* Validate and inspect the generated accounting document.

> Observation:
The refund flow may not be consistently treated as a refund when the order’s
net amount is 0, causing incorrect invoice move type/sign handling and wrong
tax booking behavior.

Why the fix:
------------
Refund detection now also relies on `refunded_order_id` in key paths:
* `_compute_prices`: apply refund factor when order is linked to a refunded order
  (or already negative), so totals/taxes keep refund semantics.
* `_prepare_invoice_vals`: create `out_refund` when the order is linked to a
  refunded order (or has negative total), ensuring a credit note is produced.
* `_prepare_base_line_for_taxes_computation`: consider refund context with
  `is_refund` or negative total for tax base sign consistency.

This keeps existing negative-total refund behavior while correctly handling
refund+eWallet cases where the arithmetic total can be 0.

opw-5426818

Forward-Port-Of: odoo/odoo#259217
Forward-Port-Of: odoo/odoo#247948

This commit addresses two valuation issues with respect to transit/internal locations without specific warehouses (such as the subcontracting location):
1. The `avg_cost` (unit cost) of products can drastically differ from its expected value since the valued quantity considered in the product total value is not necessarily the `qty_available` but the avg cost is computed as such: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L272-L273
2. The `value` of stock.quants is unexpectedly impacted by the quantity present these other locations for the same reasons: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/stock_quant.py#L57-L65

### Steps to reproduce:

- In the settings enable Multi-Steps Routes
- Create a storable with an avco perpetual valuation with a cost of 5$
- Click the `On hand` smart button > Update Quantity
- Put 1 unit in WH/Stock and 2 units in Subcontracting
- Go to Inventory > Reporting > Stock
#### > The unit cost of your product is 15$ instead of 5$
- Click on locations on the line and remove the `internal` filter
#### > The value in WH/Stock is 15$ instead of 5$ and the one in Subcontracting is 30$ instead of 10$

### Cause of the issue:

The total value of a product is computed with an additional valuation context in order to consider valuated locations and dates properly: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L202-L205 https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L231-L247 https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L264-L266 However, the `avg_cost` is computed by dividing this total value by the `qty_available` with apriori completely different context: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L271-L273 In teh present use case, the `qty_available` outside of the valuation context is 1, while the valuated quantity was 3 (as it did consider all of the internal valuated locations (e.g. Subcontracting)) because of these lines:
https://github.com/odoo/odoo/blob/93095e1e9507fde18aefe91aac8c9cb53cadc2f3/addons/stock_account/models/product.py#L202-L205 https://github.com/odoo/odoo/blob/93095e1e9507fde18aefe91aac8c9cb53cadc2f3/addons/stock_account/models/product.py#L361-L363

### Additional issue:

The variable definition in this loop is incorrect: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L251-L262 Since `prodcuts` is defined just above:
https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L202-L205 and is expected to be used as such unaltered:
https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L264-L266 In particular, the current variable declaration lead only to a valid process of the last `cost_method` group. As this variable is only introduced for the purpose of the loop computation we rename it.

opw-5959720
opw-5883980

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

Forward-Port-Of: odoo/odoo#257103

**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#259486
Forward-Port-Of: odoo/odoo#250294

Steps to reproduce:
- Set the cookies bar
- Do not accept nor reject it
- On the website homepage, click on the search button 
=> Check the cookies: website_cookies_bar=true is set.

`Popup` initializes `cookieValue` to `true` and writes it in `onHideModal()`. If the cookies bar is closed before any explicit consent choice, it can therefore recreate the legacy invalid value `website_cookies_bar=true`.

This happens because the search button uses `data-bs-toggle="modal"`, which is controlled by Bootstrap: if it is opened while another bootstrap modal is already open on the page, the latter is hidden. This in turn calls the popup interaction's `onHideModal()`, which sets `website_cookies_bar=true` as `cookieValue` hasn't been changed.

That value is later treated as invalid and cleared repeatedly during website rendering, which can accumulate duplicate `Set-Cookie` headers in the same response and lead to `upstream sent too big header` behind nginx.

Avoid persisting that legacy value by returning early from `CookiesBar.onHideModal()` while `cookieValue` is still the inherited default `true`.

opw-6037573

Forward-Port-Of: odoo/odoo#258938

Before this commit, when message actions are displayed from right-click, triggering a right-click on the message again would keep displaying the message actions.

Right-click on message to show the actions is useful in many cases, but sometimes the user wants to trigger the browser context menu.

Currently browser context menu is shown on links and when there are some text selection, but there might be some other potential cases where seeing the browser context menu is desirable. In practice users could trigger it through SHIFT + right-click but they are not necessarily aware of it.

This commit let double right-click on same message open the browser context menu, so that if users really want to have the browser context menu then doing it twice will show it.

Before
![before](https://github.com/user-attachments/assets/23c6ba1d-a8a1-4999-9ac0-308282f2f617)

After
![after](https://github.com/user-attachments/assets/fae4ff2e-13bf-4eb6-8f0d-c2d4858fd470)

Forward-Port-Of: odoo/odoo#258699

**Steps to reproduce:**
* Install the **l10n_in** module.
* Create a **branch company** under an Indian company.
* Switch to the branch company only.
* Create a user with **Accounting Administrator** access (and bank validation rights) and also give permission of this branch company.
* Login from this user .
* Create and confirm a vendor bill in the branch company.
* Click **TDS Entry** and select any TDS section.

**Observed behavior:**
* An **AccessError** is raised when selecting the TDS section.

**Cause:**
* In `_compute_amount` (wizard), currency is taken from `tax_id.company_id`.
* For branch setups, taxes (and related accounts) belong to the **parent company**, so `tax_id.company_id` points to the parent.
* The user operating in the branch company does not have access to the parent company, triggering an access error.

**Fix:**
* Use the wizard’s `company_id` instead of `tax_id.company_id` when determining currency.
* The wizard `company_id` is correctly computed based on the active company, ensuring proper access rights.

**Note:**
* Regression test is not feasible due to ORM cache behavior:
  * In tests, `mock` environments share a transaction-level cache.
  * `compute_sudo=True` fields populate cache with superuser access.
  * By the time `_compute_amount` runs, values are already cached.
  * No database fetch occurs, so record rules are not evaluated and the AccessError cannot be reproduced.

opw-6095312

Forward-Port-Of: odoo/odoo#259091

Steps to reproduce
------------------
1. Have two PoS configs in the same company (e.g. Bar with QR+ordering and Restaurant)
2. Open Bar, go to its self-order mobile menu, place an order
3. Go back, open Restaurant, click on Orders tab

-> The Bar's self-order shows up in the Restaurant's order list.

What's happening
----------------
In the `getServerOrders` override added by 6782262a4d96, the domain used to fetch tableless self-orders filters by `company_id` instead of `config_id`, so it pulls in self-orders from ALL configs in the company.

But we only want self-orders that are of type "kiosk" to be shown in other configs, while the ones of type "mobile" should only be shown in the config they belong too (or a trusted config).

The fix
-------
We adjust the domain by stop fetching company-wise mobile orders in other configs, we only keep fetching the kiosk ones. Note that mobile ordres belonging to the current config (or trusted ones) are still fetches in the main `getServerOrders` method.

opw-6068187

Forward-Port-Of: odoo/odoo#258712

This commit addresses two valuation issues with respect to transit/internal locations without specific warehouses (such as the subcontracting location):
1. The `avg_cost` (unit cost) of products can drastically differ from its expected value since the valued quantity considered in the product total value is not necessarily the `qty_available` but the avg cost is computed as such: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L272-L273
2. The `value` of stock.quants is unexpectedly impacted by the quantity present these other locations for the same reasons: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/stock_quant.py#L57-L65

### Steps to reproduce:

- In the settings enable Multi-Steps Routes
- Create a storable with an avco perpetual valuation with a cost of 5$
- Click the `On hand` smart button > Update Quantity
- Put 1 unit in WH/Stock and 2 units in Subcontracting
- Go to Inventory > Reporting > Stock
#### > The unit cost of your product is 15$ instead of 5$
- Click on locations on the line and remove the `internal` filter
#### > The value in WH/Stock is 15$ instead of 5$ and the one in Subcontracting is 30$ instead of 10$

### Cause of the issue:

The total value of a product is computed with an additional valuation context in order to consider valuated locations and dates properly: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L202-L205 https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L231-L247 https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L264-L266 However, the `avg_cost` is computed by dividing this total value by the `qty_available` with apriori completely different context: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L271-L273 In teh present use case, the `qty_available` outside of the valuation context is 1, while the valuated quantity was 3 (as it did consider all of the internal valuated locations (e.g. Subcontracting)) because of these lines:
https://github.com/odoo/odoo/blob/93095e1e9507fde18aefe91aac8c9cb53cadc2f3/addons/stock_account/models/product.py#L202-L205 https://github.com/odoo/odoo/blob/93095e1e9507fde18aefe91aac8c9cb53cadc2f3/addons/stock_account/models/product.py#L361-L363

### Additional issue:

The variable definition in this loop is incorrect: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L251-L262 Since `prodcuts` is defined just above:
https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L202-L205 and is expected to be used as such unaltered:
https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L264-L266 In particular, the current variable declaration lead only to a valid process of the last `cost_method` group. As this variable is only introduced for the purpose of the loop computation we rename it.

opw-5959720
opw-5883980

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

Forward-Port-Of: odoo/odoo#257103

Steps to reproduce:
- Set the cookies bar
- Do not accept nor reject it
- On the website homepage, click on the search button 
=> Check the cookies: website_cookies_bar=true is set.

`Popup` initializes `cookieValue` to `true` and writes it in `onHideModal()`. If the cookies bar is closed before any explicit consent choice, it can therefore recreate the legacy invalid value `website_cookies_bar=true`.

This happens because the search button uses `data-bs-toggle="modal"`, which is controlled by Bootstrap: if it is opened while another bootstrap modal is already open on the page, the latter is hidden. This in turn calls the popup interaction's `onHideModal()`, which sets `website_cookies_bar=true` as `cookieValue` hasn't been changed.

That value is later treated as invalid and cleared repeatedly during website rendering, which can accumulate duplicate `Set-Cookie` headers in the same response and lead to `upstream sent too big header` behind nginx.

Avoid persisting that legacy value by returning early from `CookiesBar.onHideModal()` while `cookieValue` is still the inherited default `true`.

opw-6037573

Forward-Port-Of: odoo/odoo#258938

### 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#259076
Forward-Port-Of: odoo/odoo#257012

Steps to reproduce
------------------
1. Have two PoS configs in the same company (e.g. Bar with QR+ordering and Restaurant)
2. Open Bar, go to its self-order mobile menu, place an order
3. Go back, open Restaurant, click on Orders tab

-> The Bar's self-order shows up in the Restaurant's order list.

What's happening
----------------
In the `getServerOrders` override added by 6782262a4d96, the domain used to fetch tableless self-orders filters by `company_id` instead of `config_id`, so it pulls in self-orders from ALL configs in the company.

But we only want self-orders that are of type "kiosk" to be shown in other configs, while the ones of type "mobile" should only be shown in the config they belong too (or a trusted config).

The fix
-------
We adjust the domain by stop fetching company-wise mobile orders in other configs, we only keep fetching the kiosk ones. Note that mobile ordres belonging to the current config (or trusted ones) are still fetches in the main `getServerOrders` method.

opw-6068187

Forward-Port-Of: odoo/odoo#258712

…e_journal_ids and it differs from the current journal_id

This resolves an issue that occurs when a user changes the invoice’s company and only one suitable_journal_ids is available. In such cases, the journal_id is not displayed, preventing the user from updating it. As a result, the following error appears: "Invoice belongs to company 'A' while 'Journal' (journal_id: 'Journal of Another Company') belongs to another company."

Description of the issue/feature this PR addresses:

The Invoice Journal is not displayed when the Invoice’s Company is changed, preventing the user from updating it. This leads to the error: "Invoice belongs to company 'A' while 'Journal' (journal_id: 'Journal of Another Company') belongs to another company."

Current behavior before PR:

When there is only one suitable Journal for the Invoice after changing the Company, the Journal field is hidden, even if the current Journal value does not match the suitable one. This prevents the user from updating the Journal.

Desired behavior after PR is merged:

When there is only one suitable Journal for the Invoice after changing the Company, the Journal field should be displayed if it differs from the only suitable Journal, allowing the user to update it.


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

Forward-Port-Of: odoo/odoo#259573

**Steps to reproduce:**
* Install the **l10n_in** module.
* Create a **branch company** under an Indian company.
* Switch to the branch company only.
* Create a user with **Accounting Administrator** access (and bank validation rights) and also give permission of this branch company.
* Login from this user .
* Create and confirm a vendor bill in the branch company.
* Click **TDS Entry** and select any TDS section.

**Observed behavior:**
* An **AccessError** is raised when selecting the TDS section.

**Cause:**
* In `_compute_amount` (wizard), currency is taken from `tax_id.company_id`.
* For branch setups, taxes (and related accounts) belong to the **parent company**, so `tax_id.company_id` points to the parent.
* The user operating in the branch company does not have access to the parent company, triggering an access error.

**Fix:**
* Use the wizard’s `company_id` instead of `tax_id.company_id` when determining currency.
* The wizard `company_id` is correctly computed based on the active company, ensuring proper access rights.

**Note:**
* Regression test is not feasible due to ORM cache behavior:
  * In tests, `mock` environments share a transaction-level cache.
  * `compute_sudo=True` fields populate cache with superuser access.
  * By the time `_compute_amount` runs, values are already cached.
  * No database fetch occurs, so record rules are not evaluated and the AccessError cannot be reproduced.

opw-6095312

Forward-Port-Of: odoo/odoo#259091

Currently an error is generated when the user tries to save an
appointment as follows:
- Install the appointment_google_calendar module without demo data
- Create a new appointment as below:
      - Remove Organizer (user_id)
      - Set the Google Meet link inside VideocallURL, e.g., https://meet.google.com/aaa-aaa-aaa
- An error occurs in the log and a message is shown to the user when save the record
- Also, an error occurs when trying to preview `Appointment: Attendee Invitation`
  after creating appointment as follows:
      - Set the Google Meet link inside Videocall URL > save
      - Remove Organizer (user_id)

Error: 
```
test odoo.addons.mail.models.mail_render_mixin: Failed to render QWeb template for Mail Template: 'Appointment: Appointment Booked' (ID: 12) - Context language:en_US
Target Model: calendar.event
Error: Error while render the template
ValueError: Expected singleton: res.users()
```


This is because the method `is_google_calendar_synced` expected a single
record, but since we removed `user_id` from the event (appointment),
it will generate a singleton error.

This commit will fix the above issue by not calling `is_google_calendar_synced`
when the event does not have `user_id`.

sentry-7393595716

Forward-Port-Of: odoo/enterprise#113966

Relativedelta on UTC dates or time-zoned dates doesn't return the same result. 
In order to calculate consistent prices (price for 1 month in December = price for 1 month in January), we need to work on time-zoned dates.

Example: 
Consider a website in UTC+1 (Brussels timezone DST off).
And a rental from the 01/12/2025 to the 31/12/2025 = by design, from the 01/01/2025 00h00 (start_date) to the 31/12/2025 23h59 (end_date). 
Converted in UTC for the back-end, we have:
from the 30/11/2025 23h00 to the 31/12/2025 22h59.
relativedelta(end_date, start_date) = time between the 2 dates is calculated as follow:
30/11/2025  23h00 + 1 month = 30/12/2025 23h00 +23h59 = 31/12/2025 22h59. 
Time difference = 1 month, 23 hours, 59 minutes. 
Price = 2 months. 

Consider a second rental from the 01/01/2026 to the 31/01/2026. 
31/12/2025 23h00 + 30 days = 30/01/2026 23h + 23h59 = 31/01/2026 22h59. 
Time difference = 30 days, 23 hours, 59 minutes.
Price = 1 month. 

opw-5130762

Forward-Port-Of: odoo/enterprise#102109
Forward-Port-Of: odoo/enterprise#98571

When sending an invoice by email template, dynamic report attachments do not use their configured Printed Report Name. Instead, they fall back to a default naming pattern (e.g. report name + invoice number).

This is due to a difference in flow: sales use the standard mail.compose.message wizard, which correctly applies each report’s print_report_name, while invoices use the dedicated account.move.send flow. In this flow, dynamic report filenames are not computed from the report itself.

To fix this, the send flow is updated so _get_placeholder_mail_template_dynamic_attachments_data computes the filename from each dynamic report. When a print_report_name is defined, it is used. Otherwise, the previous fallback behavior is preserved.

The fix will ensure extra dynamic reports follow their configured printed name.

Steps to reproduce:
1. Go to Settings > Technical > Reporting > Reports and duplicate the standard Invoice report.
2. In the duplicated report, set a custom value in Printed Report Name (e.g. 'CUSTOM_NAME_TEST').
3. Go to Settings > Technical > Email > Templates and open “Invoice: Sending”.
4. Add the duplicated report under Dynamic Reports.
5. Create a customer invoice and confirm it.
3. Click Send (or Send & Print) to open the email preview.

Related Ticket:
opw-6058716

Forward-Port-Of: odoo/odoo#259597
Forward-Port-Of: odoo/odoo#259267

Currently, when a subscription payment is processed through a provider
configured to use as outstanding account the bank default account,
the resulting invoice may remain in an 'open' state even though
the payment transaction is 'done'.
This type of configuration is usually done when users want to skip
the bank reconciliation process, and just create payments without
the need to reconcile the payments with transactions.

Steps to reproduce:
- In Settings, under Sales > Invoicing, disable Automatic Invoice
- Activate demo payment method
- In the main Bank account add the default account as outstanding
  account for demo payment method.
- Create a sales order with a subscription product
- Open Preview
- Pay
- Go back to the sales order and open the created invoice

Issue:
The invoice is created and the payment is registered, but
the invoice remains 'Not Paid'.

Analysis:
The invoice and the payment move lines are not automatically reconciled
during the post-processing of the transaction, leaving the invoice
unbalanced.

opw-5869303

**Steps to reproduce:**
* Install the **l10n_in** module.
* Create a **branch company** under an Indian company.
* Switch to the branch company only.
* Create a user with **Accounting Administrator** access (and bank validation rights) and also give permission of this branch company.
* Login from this user .
* Create and confirm a vendor bill in the branch company.
* Click **TDS Entry** and select any TDS section.

**Observed behavior:**
* An **AccessError** is raised when selecting the TDS section.

**Cause:**
* In `_compute_amount` (wizard), currency is taken from `tax_id.company_id`.
* For branch setups, taxes (and related accounts) belong to the **parent company**, so `tax_id.company_id` points to the parent.
* The user operating in the branch company does not have access to the parent company, triggering an access error.

**Fix:**
* Use the wizard’s `company_id` instead of `tax_id.company_id` when determining currency.
* The wizard `company_id` is correctly computed based on the active company, ensuring proper access rights.

**Note:**
* Regression test is not feasible due to ORM cache behavior:
  * In tests, `mock` environments share a transaction-level cache.
  * `compute_sudo=True` fields populate cache with superuser access.
  * By the time `_compute_amount` runs, values are already cached.
  * No database fetch occurs, so record rules are not evaluated and the AccessError cannot be reproduced.

opw-6095312

Forward-Port-Of: odoo/odoo#259091

Currently an error is generated when the user tries to save an
appointment as follows:
- Install the appointment_google_calendar module without demo data
- Create a new appointment as below:
      - Remove Organizer (user_id)
      - Set the Google Meet link inside VideocallURL, e.g., https://meet.google.com/aaa-aaa-aaa
- An error occurs in the log and a message is shown to the user when save the record
- Also, an error occurs when trying to preview `Appointment: Attendee Invitation`
  after creating appointment as follows:
      - Set the Google Meet link inside Videocall URL > save
      - Remove Organizer (user_id)

Error: 
```
test odoo.addons.mail.models.mail_render_mixin: Failed to render QWeb template for Mail Template: 'Appointment: Appointment Booked' (ID: 12) - Context language:en_US
Target Model: calendar.event
Error: Error while render the template
ValueError: Expected singleton: res.users()
```


This is because the method `is_google_calendar_synced` expected a single
record, but since we removed `user_id` from the event (appointment),
it will generate a singleton error.

This commit will fix the above issue by not calling `is_google_calendar_synced`
when the event does not have `user_id`.

sentry-7393595716

Forward-Port-Of: odoo/enterprise#113966

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

**Issue:** In Odoo 18/19, purchase move lines default to the WH's main stock location (`lot_stock_id`) as the `location_final_id`. However, when a user configures a sub-location on the Receipt Operation Type, the picking destination is correct, but the move lines are defaulted to the main warehouse. This mismatch causes the Forecasted Quantity to not increment for the intended sub-location

**Solution:** Prioritize the `default_location_dest_id` before falling back to the default stock location

opw-6032018

### **Current behavior before PR:** 
When confirming a PO, the `location_final_id` on stock moves defaults to the `lot_stock_id`, regardless of the specific destination set on the Operation Type. This causes a mismatch in 1-step receiving flows where a sub-location (e.g., WH/Stock/Test) is intended, since the move lines revert to the root warehouse location (WH/Stock). Thus, the forecasted quantity for the specific sub-location doesn't increment as expected.

### **Desired behavior after PR is merged:** 
The `_get_final_location_record` method will now evaluate if the Operation Type's `default_location_dest_id` is a child of the warehouse's main stock. If it is, the sub-location is used as the `location_final_id` for the moves and move lines. This ensures that the forecasted quantity reflects the intended destination upon PO confirmation while still maintaining the fallback to the warehouse root for standard multi-step routes.




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

Forward-Port-Of: odoo/odoo#256725
Forward-Port-Of: odoo/odoo#254527

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

The workcenter planning logic in _get_first_available_slot can become inefficient when searching for very short available slots. The method repeatedly builds small candidate time windows and checks them against existing workorder and leave intervals, potentially iterating many times before finding a free slot.

This leads to unnecessary computational overhead in scenarios where a large number of busy intervals exist and the remaining duration to schedule is small.

### Current behavior before PR:

The planner checks for conflicts by computing the intersection between the candidate window and the busy intervals. When a conflict is detected, the candidate window is shifted forward (or backward) to the end (or start) of the intersection, and the process is repeated until a free slot is found.

This approach requires repeatedly performing full interval merge operations, which becomes disproportionately expensive when the candidate windows are very small and the loop iterates many times.

### Desired behavior after PR is merged:

The planner uses a new Intervals.conflicting() helper to retrieve the entire busy interval that overlaps with the candidate window. Instead of advancing only to the end of the intersection slice, the planner can jump directly to the end (or start) of the full busy interval.

This avoids repeated full-merge work, reduces the number of iterations needed to find a valid slot, and prevents pathological performance slowdowns in short-duration planning scenarios.

### Benchmarks

Profiling _get_first_available_slot with different workorder durations. Database has multiple months that are fully booked. Speedup is more dramatic with shorter durations but there is at minimum minor improvements across the board.

| Work Order Duration | Before | After |
| --- |---|---|
| 1sec | ~2.5min | <1sec |  
| 1min | ~2sec | <1sec |

### References

opw-5437256


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

Steps to reproduce:
-------------------
1. Activate JPY and create a JPY bank journal with ISO20022 as an
   outgoing payment method
2. Create a vendor (with a country) and add a trusted bank account
3. Create and confirm a vendor bill in JPY (e.g. ¥1000), and pay it
   using the ISO20022 method on the JPY journal
4. Create a batch payment containing that payment, with Batch Type
   Outbound, on the JPY journal, with ISO20022 as payment method
5. Validate the batch — the XML file is generated and attached
6. Download it

-> The `<InstdAmt Ccy="JPY">` node outputs `1000.00`, while JPY has
no decimals. The file is rejected by banks.

The fix:
--------

Backport of 8da91d94ed1e8fad0e827f96172e3785e9f0e28d:

> Generating the xml file for iso20022 always generates the amount with
two decimals which is hard coded and can cause error for currencies without decimals for example JPY.
> The fix is to have the currency decimal number dynamically set through
the currency decimal places field.

opw-6103849

When using a flexible working schedule, the month view for timesheets shows a deficit even when all working days are fully completed.

### **Steps to reproduce:**
1) Install Timesheet Grid.
2) Assign a flexible working schedule (40 hrs/week, 8 hrs/day) to an admin.
3) Enter timesheets with 8 hours per weekday for a full month (except Feb).
4) Open the timesheets grid month view.

Note: current formula correctly calculates for feb month **((40/7)** * **28) = 160**

### **Observed behavior:**
The weekly view shows correct totals, but the monthly view displays a deficit (176 h with -1:08 h), despite all working days being fully completed.

<img width="1920" height="366" alt="image" src="https://github.com/user-attachments/assets/df98c3e0-ee89-455d-86c6-7941ba0cb7a8" />


### **Expected behavior:**
The monthly view should correctly calculate the required hours i.e 176 h

<img width="1909" height="357" alt="image" src="https://github.com/user-attachments/assets/c082953a-62ad-4096-8774-76d9ff7b3b25" />


### **Root Cause:**
The method [_count_daily_working_hours](https://github.com/odoo/enterprise/blob/3cf76350794078f807fc07cd0b42d0bb0315ccab/timesheet_grid/models/hr_employee.py#L82) calculated `full_time_required_hours` for a period by dividing the weekly required hours by 7 (including weekends) and multiplying by the total calendar days in the period at [1]. This gave incorrect required hours for months that have extra weekend days.

[1]- https://github.com/odoo/enterprise/blob/3cf76350794078f807fc07cd0b42d0bb0315ccab/timesheet_grid/models/hr_employee.py#L115

### **Fix:**
Update the computation to divide the weekly `full_time_required_hours` by `5` (standard working days) and multiply by the actual number of weekdays in the requested period.

**Example calculation for the month March 2026:**

|  | Formula | Values | Calculation | Result |
|--------|--------|--------|--------|--------|
| Before Fix | round(full_time_required_hours / 7 * (delta.days + 1), 2) | full_time_required_hours = 40, delta.days + 1 = 31 | round(40 / 7 * 31, 2) | **177.14 h** |
| After Fix | round((full_time_required_hours / 5) * working_days_in_period, 2) | full_time_required_hours = 40, working_days_in_period = 22 | round((40 / 5) * 22, 2) | **176.00 h** | 

**opw-5966769**

Steps to reproduce:
- Set the cookies bar
- Do not accept nor reject it
- On the website homepage, click on the search button => Check the cookies: website_cookies_bar=true is set.

`Popup` initializes `cookieValue` to `true` and writes it in `onHideModal()`. If the cookies bar is closed before any explicit consent choice, it can therefore recreate the legacy invalid value `website_cookies_bar=true`.

This happens because the search button uses `data-bs-toggle="modal"`, which is controlled by Bootstrap: if it is opened while another bootstrap modal is already open on the page, the latter is hidden. This in turn calls the popup interaction's `onHideModal()`, which sets `website_cookies_bar=true` as `cookieValue` hasn't been changed.

That value is later treated as invalid and cleared repeatedly during website rendering, which can accumulate duplicate `Set-Cookie` headers in the same response and lead to `upstream sent too big header` behind nginx.

Avoid persisting that legacy value by returning early from `CookiesBar.onHideModal()` while `cookieValue` is still the inherited default `true`.

opw-6037573

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

Backport of: https://github.com/odoo/odoo/pull/258938

Forward-Port-Of: odoo/odoo#259585

1. Send an invoice that will return an error when send to IAP
2. Send the invoice
3. Click "Fetch Peppol Invoice status" on the dashboard
4. There is a traceback (see the bottom of this message)

To create an invoice that will return an error I locally removed the EndpointID from the UBL generation (and the constraint to check that during the genreation).

```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/odoo/http.py", line 2167, in _transactioning
    return service_model.retrying(func, env=self.env)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/service/model.py", line 157, in retrying
    result = func()
             ^^^^^^
  File "/home/odoo/src/odoo/odoo/http.py", line 2134, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/http.py", line 2382, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
    result = endpoint(**request.params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/http.py", line 754, in route_wrapper
    result = endpoint(self, *args, **params_ok)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/addons/web/controllers/dataset.py", line 42, in call_button
    action = call_kw(request.env[model], method, args, kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/api.py", line 535, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/addons/account_peppol/models/account_journal.py", line 34, in peppol_get_message_status
    edi_users._peppol_get_message_status()
  File "/home/odoo/src/odoo/addons/account_peppol/models/account_edi_proxy_user.py", line 287, in _peppol_get_message_status
    processed_message_uuids = edi_user._peppol_process_messages_status(messages_to_process, uuid_to_record)
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/addons/account_peppol_response/models/account_edi_proxy_user.py", line 180, in _peppol_process_messages_status
    peppol_response = uuid_to_record[uuid]
       ^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: 'document_type'
```

task-None

This is a backport of https://github.com/odoo/odoo/pull/243029 The same bug is reproducible in 17.0

Processing a buy-receive-bill process in a foreign currency and with an auto-standard product will lead to an incorrect valuation

To reproduce the issue:
(Company in USD)
1. Enable EUR and define the rates as followed:
   - Yesterday: 2
   - Today: 2.5
2. Create a product category:
   - Method: Standard
   - Valuation: Automated
3. Create a product P in that category
   - Cost: 10 USD
4. [Yesterday] Confirm a PO in EUR with 1 x P
5. [Yesterday] Receive it
6. Bill

Error: the stock valuation has two entries: one with 10 USD debit, the receipt. Another one with 2 USD credit, the currency exchange rate difference. The second one is a mistake, in a standard configuration, the stock valuation should be impacted by nothing but the cost defined on the product form.

Since https://github.com/odoo-dev/odoo/commit/bae7feefcb08db7329d52bc36517dfd73f3347a7, in some conditions the method `_get_exchange_account` returns the stock valuation account. This is what happens here, but it's a mistake since in the above case, we should stick with the classic account (i.e. the `super` call). The conditions must be more strict.

opw-5905197