Steps to reproduce:
-------------------------------------------
1. Install the Timesheet module with demo data
2. Go to any FSM task > set allocated hours to 20h
3. Fill the timesheet for the same task for 10h
4. Navigate to FSM > My Tasks > Gantt view

Observation:
-------------------------------------------
Look at the task on the Gantt chart. The shading is barely visible because it covers only 0.5% of the bar, not 50%

Issue:
-------------------------------------------
In the commit
https://github.com/odoo/odoo/pull/137570/changes/4a93d9aee957dd3feb3db0cb69eb3b8f0f4a4683 The progress field computation was changed from storing percentage values (0-100) to storing decimal values (0-1). Specifically, the `_compute_progress_hours` method was modified. This change was made to standardize the progress field storage format, with the understanding that the UI layer would multiply by 100 when displaying the value. While most views (form, list, kanban, etc.) were updated to multiply the progress by 100 for display purposes, the Gantt view's pill progress bar was missed.

Solution:
-------------------------------------------
Overrides the `enrichPill` method to multiply the `_progress` value by 100 before it's passed to the template. This ensures the Gantt pill progress bars display correctly without modifying the core web_gantt module.

Before
---------------------------
<img width="268" height="368" alt="image" src="https://github.com/user-attachments/assets/6d35927f-bd3f-47fc-9101-e2e188d419b8" />


After:
--------------------------
<img width="250" height="371" alt="image" src="https://github.com/user-attachments/assets/fe7133e0-26d1-4c5f-b903-48826fda9488" />


opw-6038983

Forward-Port-Of: odoo/enterprise#122899
Forward-Port-Of: odoo/enterprise#111270

### Steps to reproduce

- Install `sale_timesheet_enterprise`.
- Go to **Tasks → All Tasks**.
- Switch to the **Gantt** view.
- Group by **Sale Order Item** (`sale_line_id`).

### Issue

A traceback is raised when loading the Gantt view with group by `sale_line_id`:

```text
ValueError: Invalid field 'planned_hours' on model 'project.task' for 'planned_hours:sum'
```

### Root cause

The Gantt progress bar computation for the `sale_line_id` grouping performs a `_read_group()` aggregation on the `planned_hours` field of `project.task`.

However, `planned_hours` was renamed to `allocated_hours` during the saas-16.5 migration, so the former field no longer exists on `project.task`. As a result, the aggregation raises a `ValueError`.

Migration reference:
https://github.com/odoo/upgrade/blob/e638c6ce00d9d8936d034ad7130fef51565b9195/migrations/project/saas~16.5.1.2/pre-migrate.py#L10

Issued PR: https://github.com/odoo/enterprise/pull/49685

### Fix

Use `allocated_hours`, the renamed equivalent of `planned_hours`, when computing the Gantt progress bar. This restores the Gantt view when grouping tasks by **Sale Order Item** and prevents the traceback.

Forward-Port-Of: odoo/enterprise#122994
Forward-Port-Of: odoo/enterprise#122297

*: br,cl,ec,gt,it,ke,mx

**Problem:**
The POS "Edit/Create customer" Form was switched to a standalone, hardcoded form view (view_partner_form_pos_ui) that inherits nothing during [1], in the attempt to simplify the view when accessed from the PoS.

Every field that localizations and other modules add to the partner form by inheriting base.view_partner_form therefore disappeared when accessed from PoS. Some of the fields are required, for example, to invoice.

**Solution:**
Keep the simplified view as the default, but route the view selection through an overridable hook that localization can tweak case by case. The override is applied to the affected POS bridges (see module list).

Add a test to prevent future regression.

**Note:**
Another possibility is to re-inherit for each localization the new standalone view, but this fix would need to update the module to work, while this one works with just a restart.
There are still ongoing discussion with PoS team to see if we really want to go back to each localization needing to inherit backend views.

[1]: https://github.com/odoo/odoo/pull/230721/changes#diff-66cd201e7e8cfff5218a9fa93efd72f0>

opw-6244777 (many more)

Forward-Port-Of: odoo/enterprise#119316

**Issue**:
Even when creation of new Serial Numbers for components is disabled
on the Manufacturing Operation Type, it is still possible to create
them from the shopfloor application.

**Steps to reproduce**:
- Enable "Lots & Serial Numbers", on the global settings
- Create two products, one tracked by unique serial number
- Go to Inventory > Configuration > Warehouse Management > Operations Types
- Select Manufacturing and disable "Create New Lots/Serial Numbers for Components"
- Create and confirm a MO using the tracked product as component
- Go to shopfloor
- Click the "+" button next to the component, then "New"
-> No error is raised when creating a serial number

**Cause**:
The `_check_create` constraint relies on `active_mo_id`:
https://github.com/odoo/odoo/blob/494cdcfdf4ec166e0a643ee70a53c12c810d02b4/addons/mrp/models/stock_lot.py#L11-L19
However, the shopfloor does not pass this, in context:
https://github.com/odoo/enterprise/blob/54c6252a0e13b11fc297b6828883923c0f89881a/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L193-L199

As a result, the check is bypassed.

opw-6041241

Forward-Port-Of: odoo/enterprise#114641
Forward-Port-Of: odoo/enterprise#111408

**Issue**
Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request.

**Steps to reproduce**
- Have two companies A and B and two users u1 and u2
- user u2 only have access to company A
- With user u1:
	- Create two vendors v1 and v2 without any company assigned
	- Create vendor pricelists for a product for each vendor and assign the company A to the pricelist
- Add the company B for the vendor v2
- With user u2:
	- Open approval application
	- Try to create an approval for an RFQ for that product (the vendor v1 will be automatically selected)
	- Save it -> An access error is thrown

**Cause**
Saving the approval request computes `has_no_seller`, which calls `_select_seller`: https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/views/approval_product_line_views.xml#L9 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L32 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L62-L70 
Which filtered the right seller
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L759 
By preparing the sellers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L721 https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L712 
Please note that `self.seller_ids` contains both sellers (even v2) By filtering the suppliers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_supplierinfo.py#L104-L105 
But at that point, one of the supplier in `self`, can be accessed, thus an access error is thrown while trying to access its associated `partner_id`.

opw-6203910

Forward-Port-Of: odoo/enterprise#121008
Forward-Port-Of: odoo/enterprise#120251

Steps to reproduce:
1. Install eCommerce and Subscriptions.
2. Create a 21% Excluded tax.
3. Create a subscription product with a price of 45 with 21% tax and enable "Accept One-Time" in the Recurring Prices tab.
4. Publish the product on the website under the Sales tab.
5. Create a pricelist for 6 months recurring with two lines:
 - If min quantity is 0, then 0% discount
 - If min quantity is 2, then 5% discount
6. Set "Display Product Prices" to "Tax Included" in the Settings.
7. Open the product on the website, select the 6-month plan, and increase quantity to 2.

Issue:
The discount percentage displayed on the website shows 4% instead of the configured 5%.

Why this happens:
In `_get_additionnal_combination_info`, the discount is reverse-calculated from the tax-included price vs the tax-included sales price. When the 21% tax is included to both prices, it introduces a floating-point precision loss (4.9954..%), which floor() then truncates to 4%.

Fix:
When the pricelist rule uses 'percentage' discount, read `percent_price` directly from the pricing rule instead of reverse-calculating from tax-adjusted prices, as it represents the exact discount percentage the merchant configured with no floating-point involvement.

opw-6224735

Forward-Port-Of: odoo/enterprise#121654

### [FIX] knowledge: load comments on first load
There was an issue where comments are not displayed when opening an article
containing some.

How to reproduce:
- create a new article, write some text and add some comments.
- reload the page

Issue:
- comments are not displayed, but they are when switching back and forth to
  another article

Reason:
Owl2 -> Owl3 refactoring:
commit [1] replaced useRecordObserver by onWillUpdateProps, however the 2
are not equivalent, especially over the timing of the first call
(useRecordObserver callback is called during setup).

### [FIX] knowledge: batch vertical dimensions computation once
There was an issue where comments were not displayed at their correct position
(height/top) in "handler" mode.

How to reproduce:
- create an article with 3 comments over 5 lines, following a given pattern:
  - one comment on the first line
  - one comment on the second line
  - keep the third line empty
  - one comment across the 4th and 5th lines
- reload the page (issue 1)
- click successively on the 3 comments zones (issue 2)

Issue:
- issue 1: the comments on reload overlap each other while they should not
- issue 2: when clicking on the 3rd comment, the 1st and 2nd comments appear
  offset by an abnormal vertical distance (which should not exist)

Reason:
Owl2 -> Owl3 refactoring:
Commit [1] replaced reactive + batched callback with `useEffect` executing
that same batched callback, however `useEffect` is already batched starting from
the second call, effectively batching twice, which resulted in the wrong
dimensions being computed for knowledge comments in the comments_handler

[1]: https://github.com/odoo/enterprise/commit/ab1e2cad9a214a1303e13fdff0e8a62781ef56ee

task-6370985

Currently, an error occurs when a user removes the payslip date.

**Steps to Reproduce:**

 - Install `l10n_hk_hr_payroll` with demo data.
 - Switch to the `Hong Kong` company.
 - Go to `Payroll` > `Payslips` > `Payslips`.
 - Create a `payslip` and remove the `start` or `end` period.

**Error 1:**
`TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta'`

**Error2:**
`AttributeError: 'bool' object has no attribute 'month'`

When a user removes the start or end date of a payslip, the system computes the Average Daily Wage. 
Based on the payslip dates, it finds the previous year's payslips [1]. If the start or end date is not set, 
it raises an error [2].
For the second error, when computing whether to include EOY pay, it compares the company's EOY 
pay date with the end date's month. If the end date is not set, accessing its month raises an error [3].

This commit ensures that when retrieving previous-year payslips, if the start or end date is not set, 
it returns an empty payslip recordset. It also ensures that when computing whether to include EOY 
pay, if the end date is not set, `include_eoy_pay` is set to `False`.

[1]: https://github.com/odoo/enterprise/blob/ec8a009794863090351d91650aff727e6fbeab7e/l10n_hk_hr_payroll/models/hr_payslip.py#L124

[2]- https://github.com/odoo/enterprise/blob/ec8a009794863090351d91650aff727e6fbeab7e/l10n_hk_hr_payroll/models/hr_payslip.py#L209-L215

[3]- https://github.com/odoo/enterprise/blob/ec8a009794863090351d91650aff727e6fbeab7e/l10n_hk_hr_payroll/models/hr_payslip.py#L141

Forward-Port-Of: odoo/enterprise#123135
Forward-Port-Of: odoo/enterprise#120586

`sync_participants` calls `action_set_unlink` on every participant whose record is no longer in the campaign domain, and `action_set_unlink` writes "Record deleted" on each scheduled trace. The removed bucket also contains records that still exist but no longer match the campaign filter, so the cancelled trace dialog shows "Record deleted" even when the record was only filtered out.

In `sync_participants`, the to_remove participants are split between those whose record still exists in the database (filtered out by the campaign domain) and those whose record was actually deleted. `action_set_unlink` accepts an optional `trace_message` argument, defaulting to "Record deleted", and the filtered-out batch passes "Record no longer matches campaign filter" so the cancelled trace dialog reflects the real cause.

Steps to reproduce:
1. Install Marketing Automation and CRM.
2. Open Marketing Automation, create a campaign on Lead with filter Stage = New.
3. Add a begin activity to the workflow.
4. Open CRM, create a Lead in the New stage.
5. Back in the campaign, click Generate Participants.
6. In the CRM pipeline, drag the Lead from New to Qualified.
7. Back in the campaign, click Generate Participants again.
8. Open the Participants smart button, click the participant for the moved Lead.
9. Click the cancelled activity in the workflow timeline.

=> The activity dialog shows "Error message: Record deleted" although the Lead still exists.

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

Forward-Port-Of: odoo/enterprise#118692

Issue
-----
When shipping internationally with Easypost, the currency on the commercial invoice does not always match the one of the sale order.

Steps to reproduce
-----
- Install Easypost
- Create a new pricelist using a different currency from the company
- Create a SO
	- Some product with a weight & HS code
	- Customer must be in another country from company (for commercial invoice)
	- Use the new pricelist
	- Add easypost delivery
- Confirm SO
- Validate linked picking

> Commercial invoice uses company currency instead of SO's

Cause
-----
The currency being sent to Easypost is retrieved from the package in

https://github.com/odoo/enterprise/blob/4c540f450d4de8b59b871662123f85ed54cca2a9/delivery_easypost/models/easypost_request.py#L146

The package object is actually created by calling the carrier's `_get_packages_from_picking` method

https://github.com/odoo/enterprise/blob/4c540f450d4de8b59b871662123f85ed54cca2a9/delivery_easypost/models/easypost_request.py#L266-L270

Solution
-----
We could be fixing this in `stock_delivery` by creating the package with the correct currency when calling `_get_packages_from_picking`. The problem with this approach is that this might negatively affect other carrier services, as discussed in https://github.com/odoo/odoo/pull/268224.

Instead, we can apply a band-aid fix to take the currency from the picking's sale in the `delivery_easypost` module, which is the only one where the problem was reported.

-----
Ticket:
opw-6224883

Forward-Port-Of: odoo/enterprise#123083

When a live chat channel has no operators configured and the chatbot
script ends with a Forward to operator step, triggering that step
causes a traceback.

Steps to reproduce the error:
- Install ``im_livechat`` module with demo data
- Go to Live Chat > Configuration > Chatbots > Create a new chatbot >
  Add script > Step Type: Question > Set answers > Save >
  Add script > Step Type: Forward to operator >
  Only If: Set one of the above answers > Save
- Go to Live chat > Channel > Click the configure channel on YourWebsite.com > Remove the operators > Save
- Go to the chatbot > test > select the configured answer

Traceback:
```py
StopIteration
```

https://github.com/odoo/odoo/blob/8791cdcd89ea3cb56b1fac63b3e2ffbd2956a912/addons/im_livechat/controllers/chatbot.py#L65-L70
When the chatbot script reaches a Forward to operator step while no operator
is configured in the live chat channel, no chatbot message is created.
As a result, the generator iterates over an empty iterator, and
the ``next()`` call raises a ``StopIteration`` exception, causing a traceback
during the conversation.

sentry-7435424405

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

Forward-Port-Of: odoo/odoo#274615
Forward-Port-Of: odoo/odoo#261726

**Issue 1:**

Step to reproduce:
- Type ':wave' to open suggestion list
- Now click on any emoji from the suggestion list

Description of the issue:
- The selected emoji gets inserted, but the `searchNode` `:wave` does not get removed and remains beside the inserted emoji

Cause:
- When the user clicks an emoji from the suggestion list, focus shifts to the suggestion list item. As a result, `selection.extend()` is unable to properly select the searchNode in the editable area. Because the `searchNode` is not selected, `deleteSelection()` fails to remove it before inserting the emoji.

Solution:
- Added the `user-select-none` class to the suggestion list to prevent selection/focus shift on emoji click, ensuring the searchNode is properly selected and replaced by the selected emoji


**Issue 2:**

Steps to reproduce:

- Open a To-do on a mobile device.
- Type `:p` to create an emoji.
- Press Backspace.

Issue:

- When using the SwiftKey keyboard, pressing Backspace after an emoji can result in an incorrect cursor position.

Cause:
- When Backspace is pressed, a selection snapshot is cached during the `keydown` event.
- Later, `deleteBackward` converts the emoji back to its corresponding expression (:p) by triggering an undo operation, but the cached selection does not get updated. As a result, the previously cached selection is reused, causing the cursor to be placed incorrectly.

Solution:

- After performing the undo, update the cached selection to match the new cursor position.
- This ensures that the latest selection is used instead of the outdated selection captured during `keydown`.

**Issue 3:**

Steps to reproduce:
- Open a To-do on a mobile device.
- Type `:p` to create an emoji.
- Press Backspace.

Issue:
- Pressing Backspace on an emoji does not revert it to its matching expression (`:p`).

Cause:
- On mobile devices, `event.key` can be undefined in keydown. As a result, `deleteBackward` is triggered through the `beforeinput` event, which correctly reverts the emoji to its matching expression. However, after that, the `input` event is triggered and converts the expression back into the emoji again, making it appear as if the emoji was not reverted.

Solution:
- When the event type is `deleteContentBackward`, skip converting the expression back into an emoji and return early.


task-6201173

Forward-Port-Of: odoo/odoo#272565
Forward-Port-Of: odoo/odoo#263777

When a customer paid through DPO, they landed on the DPO error page ("Not Valid - this transaction is no longer valid") instead of the payment page, even though the transaction token was created correctly.

The customer is redirected to `https://secure.3gdirectpay.com/payv2.php` with the transaction token passed as the `ID` parameter. `payv2.php` answers with a 302 redirect to `payv3.php`. Per HTTP semantics, a 302 turns the request into a GET and drops the body, so when `ID` is sent in the body of a POST it never reaches `payv3.php`: the customer arrives at `payv3.php?` with no token and DPO rejects it as invalid.

This regressed with 97ec8a3e72d9d48a0a9620c53feea533421b9d67, which moved redirect providers to the generic redirect form. Before that commit, the token was part of the action URL itself (`payv2.php?ID=<token>`), so it stayed in the query string across the redirect. The refactor moved `ID` into `url_params` rendered as a hidden input, and since `http_method` was left unset the generic form defaults to POST, putting `ID` in the body.

Set `http_method` to "get" so the token is serialized back into the query string and survives the `payv2.php` -> `payv3.php` redirect, restoring the pre-refactor behavior. This also matches DPO's documented convention of passing the token in the URL query string.

opw-6312732

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

Forward-Port-Of: odoo/odoo#272890

**Issue**
Printing a credit note for a returned dropshipped tracked product could display the wrong lot/serial number on the invoice report.

**Steps to reproduce**
- Activate "Display Lots & Serial Numbers on Invoices"
- Create a product tracked by serial/lot and enable the dropship route
- Create two lots: "lot1" and "lot2"
- Create and confirm a SO for quantity 2
- Confirm the PO and validate the dropship for both lots
- Create and post an invoice
- Return "lot2" from the dropship picking
- Create and post a credit note for quantity 1
- Click on print -> The generated PDF displays "lot1" instead of "lot2"

**Cause**
While rendering `account.report_invoice_with_payments`, the report calls `_get_invoiced_lot_values` to determine which lot/serial numbers should be displayed:
https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L31-L32 `invoiced_qties = 1` since the credit is on a quantity of 1 https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L44 Three stock move lines are retrieved from the SO:
- the two original dropship deliveries,
- the return move for `lot2`. https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L63 However, none of them are considered as `is_stock_return` because the dropship locations use `supplier` instead of `internal`: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L72-L76 As a consequence:
- The two original delivery move lines each keep quantity `1`: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L69 they never pass through the return handling logic: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L77-L80 which would make it as -1 (since `qties_per_lot[sml.lot_id]` is 0 for the first iteration of `sml.lot_id`). Thus, it does not pass by this code (since quantity is greater than 0): https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L87-L90 which would make it as 0.
- for the last one, `is_stock_return = False` as it should be, thus the quantity is 1 as it should be. The quantities are therefore accumulated as:
https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L92

resulting in:
`qties_per_lot = {lot1: 1, lot2: 2}`
instead of:
`qties_per_lot = {lot1: 0, lot2: 1}`

The report then selects the first matching lot and stops: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L94-L99

opw-6230281

Forward-Port-Of: odoo/odoo#268905
Forward-Port-Of: odoo/odoo#266716

Steps to reproduce:
1. Install l10n_be and switch to BE company
2. Upload the XML document (found in ticket chatter) into the Accounting application as a Credit Note.

Issue:
 - The line is imported as a negative value which is corrected with a rounding line.
 - The 6% tax rate is applied to the negative invoice line, resulting in a negative tax amount being deducted from the total (e.g., 449.32 + (-26.96) = 422.36) instead of being added (449.32 + 26.96 = 476.28)

Expected behavior:
price_unit, quantity and the related tax amounts should all be
positive, matching a normal in_refund/out_refund line.

Why this happens:
 - In `_import_ubl_invoice_line_add_price_unit_quantity_discount`,
  `BaseQuantity` was multiplied by file_document_sign, unlike
  `PriceAmount` from the same node which is left untouched.
  This flips price_quantity to -1, which later flips price_unit to
  negative when `price_unit = price_subtotal / price_quantity`.

opw-6310442

Forward-Port-Of: odoo/odoo#271148

Steps to reproduce:
- Configure a thumb drive with a certificate read from the ETA USB tool, so l10n_eg_edi.thumb.drive.certificate is populated
- Open a customer invoice, confirm it, then Sign invoice

Before this commit, signing crashed with:

    `TypeError: encoded_data must be a byte string, not
    odoo.orm.fields_binary.BinaryValueAttachment`

raised by `asn1crypto` in `x509.Certificate.load()`, called from `_generate_signed_attrs__` and identically from `_generate_signer_info__` and `_generate_cades_bes_signature`.

Reading an attachment-backed Binary field now returns a lazy `BinaryValueAttachment` wrapper rather than raw bytes, and `asn1crypto` rejects any value that is not a bytes instance. `set_certificate` and the `l10n_eg_eta_json_doc_file` reads were already moved to the new binary API but the three certificate loads were missed and still passed the wrapper straight to asn1crypto.

Load the certificate through `self.certificate.content`, which returns the stored DER bytes.

opw-6365281

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

Forward-Port-Of: odoo/odoo#274658

Before this commit, payment transactions created from a Stripe token were assigned the payment method with code `unknown` when processing the payment data, instead of the correct card brand (e.g., VISA). This was due to the combination of two problems in Stripe's payment method resolution performed by `_apply_updates`:
- It was comparing the transaction's initial payment method code to the primary payment method code "card", while transactions created from a token directly inherit their token's brand payment method (e.g., VISA). It then assumed that "card" was selected for payment.
- Stripe's payment method mapping included an "unknown" <-> "card" correspondence meant for Express Checkout (this was never used), which wrongfully made `_get_pm_from_code` return and assign the "Express Checkout" to the transaction.

With the commit, the payment method code comparison is always performed regardless of the initially assigned payment method, which allows finding "visa" as the selected payment method. It also removes the unused "unknown" <-> "card" entry to prevent erroneous mappings in the future.

Steps to reproduce:
1. Create a log note or send a message on any record and open the full composer.
2. Set a date in the future to schedule the message for later and click schedule.
3. Click on the "Edit" button of the newly scheduled message.
4. Try dragging and dropping an image into the body, or add a file as an attachment using the button.

Issue:
- Dragging and dropping an image into the form does nothing.
- Trying to add a file as an attachment using the button triggers a traceback: `TypeError: Cannot read properties of undefined (reading 'resId')`

Why this happens:
- The failure when adding explicit file attachments occurs because the `model` and `res_id` fields were omitted from the `mail.scheduled.message` form view layout in the commit 3b985d2. Without these field  declarations, the `mail_composer_attachment_selector` widget cannot determine the record metadata parameters, causing the upload to crash.
- The failure of the drag-and-drop mechanism occurs because the scheduled message edit view uses the default `FormController` class instead of `MailComposerFormController` which is used in the `mail_compose_message` view. Consequently, the underlying `useCustomDropzone` is never instantiated on the view, leaving drop events unhandled.

Fix:
1. Specify `js_class="mail_composer_form"` to the scheduled message form view definition tag to handle drag and drop, as well as adding the missing fields
2. Assign the `resIds` variable based on the message type since it is defined as `res_id` instead of `res_ids` in `mail.scheduled.message`.

opw-6273260

Forward-Port-Of: odoo/odoo#268515

**Issue:** Installing `l10n_uy` on a demo database raises a ValidationError from the `check_use_document` constraint since 19.3+. The error occurs because `ir_module.py:write()` re-applies module-specific template data to all companies with a matching chart template after installation. At that point, `demo_company_uy` already exists with `chart_template='uy'` and posted demo invoices, so `_load_data` ends up writing `l10n_latam_use_documents=True` to a journal that has validated entries.

This write was previously suppressed by `_pre_reload_data`, which unconditionally removed journals from the data when found by xmlid. Commit 056b8e38ff84 (saas-19.3) narrowed that protection to only apply when `'type' in journal_data`. Since the module-filtered data never includes `type` (that field comes from `_get_account_journal` in the base `account` module, excluded by the module filter), the journal is no longer protected and the write triggers the constraint.

**Versions:** 19.3+

**Fix:** remove `l10n_latam_use_documents=True` from `_get_uy_account_journal`. `l10n_latam_invoice_document` already sets this field for all LATAM companies via `_get_latam_document_account_journal`; l10n_uy was setting it redundantly.

Task id: [6354499](https://www.odoo.com/odoo/project/49/tasks/6354499)

Forward-Port-Of: odoo/odoo#273930

**Problem:**
When creating a new employee, the future timesheets due to public holidays are computed. If the number of public holidays is large (i.e. if the user creates them for each year, several years in the future), then it takes excessively long and the action may not complete.

**Cause:**
The pytz method `localize` and comparing times with non-static timezones is done repeatedly and unnecessarily which becomes costly with more records.

**Solution:**
Only localize the time when absolutely necessary (determining the date of the leave in the calendar timezone).

**Performance Stats:**
|Record count|Time before|Queries before|Time after|Queries after|
|------------|-----------|--------------|----------|-------------|
|100         |3.1s       |393           |0.8s      |117          |
|1,000       |22.3s      |2,090         |1.5s      |183          |
|10,000      |Timeout    |N/A           |6.7s      |541          |

opw-6087422

Forward-Port-Of: odoo/odoo#271690
Forward-Port-Of: odoo/odoo#263953

Commit [1] introduced a `headResponseCache` for images' src, later used in commit [2], which introduced `getFetchedMimetype`. While the former guards against an empty/undefined src, it is not the case of the latter. `headResponseCache.read`, which runs a `fetch`, is called within a try/catch, but it is still awaited: with an undefined src, it returns a 404 after stalling the thread for at least 1s.

The bug can be seen from the website builder:
- Drop a text/image snippet
- Open your dev tools on the "network" tab
- Click on the image => a failed fetch (404) appears and blocks the builder from being updated quickly.

It happens because the element (in this case the `section` of the snippet) is neither an `img`, nor an element with a parallax, nor an element with a background-image, and `getImageSrc` returns an undefined src.

[1]: https://github.com/odoo/odoo/commit/bf377f3d1c58aaeb39624700b3e4754d7a6d384b
[2]: https://github.com/odoo/odoo/commit/b96a0769eeecd2e6ec14cc7a73105f8dfdb8842e

task-6247171

Forward-Port-Of: odoo/odoo#274641

Steps to reproduce:
- Add the "Supported Payment Methods" snippet on a website page
- Open the page as a public (non-logged-in) visitor => An AccessError is raised: "You are not allowed to access 'Payment
   Method' (payment.method) records".

`get_supported_payment_methods` searched `payment.method` without `sudo()`, and its JSON response embeds `image` URLs that are fetched by the browser through the public `/web/image` controller, which requires either full read access on the record so a `_can_return_content` override granting content-level access.

The root cause was introduced in [1]: that commit removed the blanket `base.group_public`/`base.group_portal`/`base.group_user` read grants on `payment.method`, replacing them with a `base.group_system`-only ACL plus a provider-scoped rule, as part of making payment methods provider-specific. It didn't account for the `website_payment` snippet controller, which relies on public read access to list the available payment methods and their logos.

Fix by:
- Using `sudo()` when searching `payment.method` in `get_supported_payment_methods`
- Overriding `_can_return_content` on `payment.method` to allow public access to the `image` field only.

[1]: bcfeed4b24f5155c111c3866e779bb2f119b9da8

# How to reproduce
- Install the Website module
- Install another module that has atleast one model with one html field,
sanitize=Flase or sanitize_form=False and groups
- Remove the field's group from the current user
- Enable dev mode
- Go to Settings > Technical > Database Structure > Models
- Pick any model (e.g. sale.order.line)
- Add a field to that model & Save
- Delete the added field & Save

> Note : Significantly harder to reproduce since :
https://github.com/odoo/odoo/commit/9a336bbb94b0a4266d84f7554c024c3abd2d1e7c
I am not sure a field as mentionned in the steps exists

# The problem
An access error is raised for the module wich access rights were
removed, even if the module is not linked in any way with the picked
model

# Cause of the issue
Deleting the field will endup calling the `unlink()` method of
`BaseModel` on the `ir.model.fields` record. This function triggers all
`@api.delete` methods defined on the model :
https://github.com/odoo/odoo/blob/5538132d9d14c4cc5031fc50ac0388ad2ab0fc92/odoo/models.py#L4548-L4552

This will call the this method :
https://github.com/odoo/odoo/blob/5538132d9d14c4cc5031fc50ac0388ad2ab0fc92/addons/website/models/website_form.py#L153-L154

That was introduced by :
https://github.com/odoo/odoo/commit/c0a827519844ec43537e4487f6abe358bb82ba9a

Which prevents a field from being deleted if it is actively used in any
website form. But this method does a search on every model return by
`_get_html_fields` which may contains models that are not accessible by
the user, so we get an access error.

# Proposed solution
Since `_check_if_used_in_website_form` should perform the same
independently from the user, we can do the search in sudo

opw-6231951

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

Forward-Port-Of: odoo/odoo#274332
Forward-Port-Of: odoo/odoo#265781

The avatar card tour asserts the systray activity counter, which only counts activities whose state is today or overdue. The test scheduled its activities without an explicit deadline, so activity_schedule fell back to context_today on the class environment, whose superuser has tz Europe/Brussels with demo data. When the test runs between 22:00 and 00:00 UTC, that deadline is tomorrow from a UTC point of view. The state of an activity is however computed in the timezone of its assigned user, and hr_user is created without one, falling back to the server date (UTC). Its activities were therefore planned instead of today, the counter stayed empty and the tour timed out. The admin iteration kept passing because demo data gives admin the same Brussels timezone as the environment that computed the deadline, which is why only half the runs failed (both occurrences at 23:56 and 23:31 UTC).

Schedule the activities with a deadline one week in the past instead: an old deadline is overdue in every timezone, whatever timezone the scheduling environment or the assigned user has, making the counter deterministic at any time of the day.

https://runbot.odoo.com/odoo/error/941407

Forward-Port-Of: odoo/odoo#274679

From saas-18.4, the expiration confirmation wizard can be triggered not only from expired lots, but also from stock move lines whose `removal_date` has passed.

For incoming receipts, tracked products use the `lot_name` field when the user is entering the lot. The corresponding `lot_id` is only created later once the receipt is validated.

As a result, it is possible for the expiration confirmation wizard to be displayed before the lot exists. In this situation, it attempts to display the product and lot information using `lot_id`, which is still empty, causing the message to show "False, False" instead of the actual lot name entered by the user.

It should use the move line information as a fallback when no `lot_id` has been created yet so it still displays the correct product and lot name.

Steps to reproduce
1. Enable Product Expiry.
2. Create a storable product with:
   - Tracking: By Lots
   - Use Expiration Date: enabled
   - Removal Time > 0
3. Create a receipt for the product.
4. Open Detailed Operations.
5. Enter a new lot number in the Lot/Serial Number field.
6. Ensure the removal date is in the past and validate the receipt.

Related Tickets: opw-6303140

Forward-Port-Of: odoo/odoo#273970
Forward-Port-Of: odoo/odoo#273143

**Problem:**
When scheduling a message using an email template with custom attachments, those attachments will not have their `res_model` and `res_id` updated to relate to the scheduled message record. This can lead to access errors.

**Cause:**
When composing a message using an email template with attachments, those attachments are created with their `res_model` and `res_id` values corresponding to the mail composer record. However, when scheduling a message, only attachments with no `res_id` value (or a value of 0) are updated to correspond to the scheduled message record. https://github.com/odoo/odoo/blob/77b180e8251fb8019e0034e1c2f485fd2c34ea4e/addons/mail/wizard/mail_compose_message.py#L1198-L1201
https://github.com/odoo/odoo/blob/30ca89b9e0d3c43d019167ec2de816c263f4bb92/addons/mail/models/mail_scheduled_message.py#L86

**Purpose:**
Modify the `mail.scheduled.message` override of `create` to not require an attachment have no `res_id` value to be properly updated.

**Steps to Reproduce in Runbot:**
1. Add an attachment to an email template.
2. Open a mail composer using that email template, then schedule the message for later.
3. Attempt to view the scheduled message with a different user.

More specific example flow:
1. Add an attachment to the Sales: Send Quotation email template.
2. Create a Quotation and send it with the Send by Email button, selecting Send Later instead of Send.
3. Attempt to view the Quotation with a different user.

opw-6293587

Forward-Port-Of: odoo/odoo#272261

Fix 1 : project, sale_timesheet: remove default_allow_billable context in Create a Project
---------------------
**Issue:**
  When a project is created from the sale app, it is not billable by default, and the sale order / sale order line are not set.

**Fix:**
 Remove default_allow_billable = False in the Create a Project

**Note:**
  default_allow_billable = True already exists in action_view_project_ids, but that default context is replaced when opening the project directly from the view. This happens because default_allow_billable = False is set in the Create a Project
  action.

Fix 2: sale_project: show only relevant project templates per company
----------------
**Steps:**
   - Install sale_project
   - Create two companies (A, B)
   - Create three project templates:
	 - Template A (company A)
	 - Template B (company B)
	 - Template C (no company → visible to all)
   - Create a sale order for company A with a service product
   - Confirm the sale order
   - Create a project and try to select a template

**Issue:**
   All project templates were visible even if the sale order had a company set.

**Fix:**
   Added a filter (domain) on the project template field so only templates for the sale order’s company or templates with   no company are shown. Users cannot select templates from other companies.

task-5074893

Forward-Port-Of: odoo/odoo#274417
Forward-Port-Of: odoo/odoo#229309

### Steps to reproduce:

- Have a company with a branch say "company1" and "branch"
- Create two products: Final product (FP), Component (Comp)
- Set the company_id of FP to "branch" and of Comp to "company1"
- Associate both products with a product category set to avco in company1 (the field is company dependant)
- Create a bom for FP with company_id set to "branch": 1 X Comp
- Impersonate a user whose only allowed and default is "branch"
- Create and confirm an MO for 1 unit of FP
- Set the qty_producing to 1 unit and validate
#### > Access Error: Access to unauthorized or invalid companies.

### Cause of the issue:

Validating the MO will, validate the component move and set its value: https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/stock_move.py#L168-L173 But, in order to determine this value, it is necessary to determine its `property_cost_method`:
https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L60-L69
Now, the issue is that the `product_template` of the component belongs to "company1" so that the user is unauthorized to read the valuation method of the product category for "company1".

opw-6216141

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

Forward-Port-Of: odoo/odoo#274108
Forward-Port-Of: odoo/odoo#272429

### Steps to reproduce:

- Have two companies: company1 and company2
- Create a producct P available in both company1 and company2
- with company1, create a kit bom for a product P
- with company2, create and confirm a sale order for 1 unit of P
- with company1, change the bom type of P from kit to manufature
#### > UserError: As long as there are some sale order lines that must be delivered/invoiced and are related to these bills of materials, you can not remove them.

### Cause of the issue:

Changing the bom type from a kit (phantom type) to a non kit will launch a call of the `_ensure_bom_is_free` in order to ensure data integrity if the kit bom was used by a relevant sale order line: https://github.com/odoo/odoo/blob/f4c76be062bec47b68ee42505d7d42fed31ac0f2/addons/sale_mrp/models/mrp_bom.py#L15-L18
https://github.com/odoo/odoo/blob/f4c76be062bec47b68ee42505d7d42fed31ac0f2/addons/sale_mrp/models/mrp_bom.py#L24-L42
However, this check does not take the company of the bom into account and in the present flow, the company of the bom is different from the company of the supposedly problematic sol.

opw-6290304

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

Forward-Port-Of: odoo/odoo#273839
Forward-Port-Of: odoo/odoo#271119

*: mrp_subcontracting_{dropshipping, purchase}

### Steps to reproduce:

- In the settings: Enable subcontracting, dropshipping
- Create a storable dropshipped product FP with a set vendor for 5$ and subcontracting BOM: 1 X COMP. Value this product in avco perpetual
- Set the component to resupply subcontractor and standard price to 2$
- Create and confirm a sale order for 1 unit fo FP
- Validate the resupply to the subcontractor and then the dropship
> The FP standard price shoul dhave been updated to 5$ + 2$ = 7$
- Create and post a bill from the PO for 10$ rather than 5
#### > The FP standard price should have been updated to 11$ rather than 12$

Cause of the issue:

Posting the bill will call the `_set_value` method to re-evaluate the product in terms of the newly recorded `account.move`: https://github.com/odoo/odoo/blob/161715c850496d3683baa5d1600380470d0b5ff5/addons/stock_account/models/stock_move.py#L393-L395 Now, the issue is that due to our config, there are two relevant moves linked to the `order_line`: the final move of the subcontracted production (which `is_in`) and the dropship move going from the subcontractor to the customer. When it comes to the subcontracted move, it is appropriately valuated at 12$ by the `_get_value_from_account_move` because of this override which adds the components value via the extra cost since the move has a `production_id`:
https://github.com/odoo/odoo/blob/161715c850496d3683baa5d1600380470d0b5ff5/addons/mrp_subcontracting_purchase/models/stock_move.py#L14-L38 However, the dropship move will not add this extra cost (as no override sets it to have the same value as the subcontracted production it comes from) so that this move is valuated at 10$. This explains why the value of the avco product is then updated to 11$ since (12 + 10) /2 = 11

Note that the issue is not reproducible in the case of regular subcontracting since in that case the receipt from `subcontractor` to `stock` is not valuated.

opw-6318035

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

Forward-Port-Of: odoo/odoo#273137
Forward-Port-Of: odoo/odoo#272813

## Issue
In the attendance view of an employee, a recap of the current extra hours is displayed, showing four values:
1. Total Extra Hours Worked
2. Total Compensable Extra Hours
3. Time Off Taken from Extra Hours
4. Remaining Extra Hours

Each of the above values can be negative but the last one, which can seem odd as it appears to be calculated from the other values.

<img width="299" height="168" alt="6293174-before" src="https://github.com/user-attachments/assets/4377e2fd-f5f2-41a4-a82b-6f2598378499" />

## Steps to reproduce
1. Install *HR Attendance Holidays* (`hr_holidays_attendance`)
2. In Settings, toggle *Absence Management* and *Display Extra Hours*
3. For an employee E:
    - In the Payroll tab, set the Working Hours to the *Standard 40 hours/week* schedule
    - In the Settings tab, set the Overtime Ruleset to the *Default Ruleset*, and toggle the *Give back as time off* action for the *Employee Schedule Rule* rule
4. Create an attendance for employee E:
    - Any day where they are expected to work 8 hours
    - From 10am to 5pm (6 hours with lunch)
5. In the Employees app, go to employee E and click the *Monthly Hours* smart button
6. __In the *Balance* recap above the list of attendances, the *Remaining Extra Hours* row shows 00:00, which seems wrong compared to the other fields above (*Total Extra Hours Worked* and *Total Compensable Extra Hours*) which appear negative.__

## Cause
The `unspent_overtime` (*Remaining Extra Hours* in the balance recap) is computed by adding positive values, making it strictly positive.

https://github.com/odoo/odoo/blob/30c9e8c5b1e34b94c8aab8681e2c051a3b70f013/addons/hr_holidays_attendance/models/hr_employee.py#L62-L65

This was added by https://github.com/odoo/odoo/commit/2144bcfba1ac53c82fc7f2870a72bb13abee97e4, with no justification on why this value needs to be positive.

## Impact on "Time Off taken from Extra Hours"
Before this change, after following the above steps, a value of `-2:00` would be displayed in the *Time Off Taken from Extra Hours* row. This is no longer the case after this fix, since the `'unspent_compensable_overtime'` (*Remaining Extra Hours*) value is used to compute that row:

https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/hr_holidays_attendance/static/src/views/extra_hours_list_view.js#L39-L42

Instead, a value of `00:00` is shown. Before, we were substracting 0 hour of `unspent_compensable_overtime` to the -2 hours of `compensable_overtime`, now we are subectracting -2 hours of `unspent_compensable_overtime` to the same -2 hours of `compensable_overtime`. This is a side effect that was ignored, as it seems to make at least as much sense as showing `-2:00`.

<img width="321" height="179" alt="6293174-after" src="https://github.com/user-attachments/assets/907d5fb8-0c36-4b2e-bca7-1cec41baf22b" />


opw-6293174

Forward-Port-Of: odoo/odoo#274172
Forward-Port-Of: odoo/odoo#271272