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

This PR improves the cost of `/forum/my-forum-1/my-slug-1234` by ~48%.

This has a huge impact on odoo.com

The `/forum/...` routes are the `#1` on odoo.com in terms of absolute count and in terms of CPU and SQL cost. They are called several million times a day. 

The average total time for `/forum/my-forum-1/my-slug-1234` goes from ~358ms to ~187ms (sql: 107ms -> 52ms - cpu 250ms -> 135ms)

This has been tested by extracting 30k real forum post urls from odoo.com logs and replaying them on a staging server. That day `/forum/...` routes were called 2.8M times

## before
<img width="1343" height="122" alt="image" src="https://github.com/user-attachments/assets/2b8264b7-4f26-40a7-a20a-20d478f5a93a" />

## after
<img width="1339" height="124" alt="image" src="https://github.com/user-attachments/assets/7c73aeb0-a4b4-45b8-ae98-093ac70c438e" />



### First commit

before
<img width="1857" height="946" alt="image" src="https://github.com/user-attachments/assets/63b9d966-f5fd-4047-b4cb-533b7e9491bc" />


after

<img width="1844" height="867" alt="image" src="https://github.com/user-attachments/assets/9494efe0-0b7c-419d-b918-dcfe5e942e63" />


query plan for most used tags as public user:

- with the index https://explain.dalibo.com/plan/gbf9fbd358687f3e
- without the index https://explain.dalibo.com/plan/da5gg6cd27f67496

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

Forward-Port-Of: odoo/odoo#272716

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

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

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

# 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

**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

Issue before this commit:
=========================
When splitting a done picking that contains at least one stock move whose
done quantity is less than the demanded quantity (product_uom_qty),
an expected singleton traceback occurs.

Steps to Reproduce:
=========================
- Install the stock module with demo data.
- Create a delivery picking for any product with a demand of 5.
- Set the done quantity to 2.
- Validate the picking without creating a backorder.
- Try to split the validated/done picking.
- An expected singleton traceback is raised.

Cause of the issue:
=========================
Previously, attempting to split a done picking simply returned because 
there was nothing left to split.

After this [PR](https://github.com/odoo/odoo/pull/224952), the split action calls **message_post()** to post a note on the original picking 
of the generated backorder. However, no backorder is created when splitting a done picking
since there is no remaining quantity to split. As a result, message_post() is called on 
an empty recordset, leading to an expected singleton traceback.

With This Commit:
=========================
Splitting a done picking has no functional purpose, as there is nothing left to split.
In this case, simply return without performing any action. This preserves the 
previous behaviour and prevents the traceback.

Forward-Port-Of: odoo/odoo#274382

This PR is needed for the fix of https://github.com/odoo/odoo/pull/272411

**Problem:**
lot's standard price are not correct 
when the product is fifo and move have 
different values and multiple lots

**Steps to reproduce:**
- product fifo tracked and valued by lots
- 20 IN @ 100 (all in lot 1)
- 10 IN @ 10 (5 in lot 1 and 5 in lot 2)
- on the product form click on the 
lot/serial number smart button and 
select lot 1

**Current behavior:**
the average cost of lot1 is 64
back on the product form the standard price is 
55

**Expected behavior:**
the average cost of lot 1 should be 20 * 100 (from move1) + 
5 * 10 (from move 2) / 25 = 2050 / 25 = 82
the standard price of the product should be 
2100 / 30 = 70

**Cause of the issue:**
Because the product is fifo, to compute 
the avg_cost of the lot we call _run_fifo()
https://github.com/odoo/odoo/blob/456026b5ef99388b1cf5bdd78cee8d1ad3d51304/addons/stock_account/models/stock_lot.py#L47
which calls _run_fifo_get_stack() to get the fifo
stack specific to this lot.
https://github.com/odoo/odoo/blob/456026b5ef99388b1cf5bdd78cee8d1ad3d51304/addons/stock_account/models/product.py#L545

Issue 1) 
run_fifo_get_stack() stores the on hand quantity (for the lot 
if a lot is given as param) in fifo_stack_size and, 
as long as there is moves and fifo_stack_size>0, 
adds move (starting from the last one in date) to the stack
and removes the quantity of the move from fifo_stack_size.
It then returns the moves stack and the remaning quantity 
on the first move of the stack (for the rest we know it's the 
full quantity)
https://github.com/odoo/odoo/blob/456026b5ef99388b1cf5bdd78cee8d1ad3d51304/addons/stock_account/models/product.py#L612-L618

Inside run_fifo_get_stack(), to do this, because 
we're only considering the quantities from 
this specific lot we should only remove the quantity from 
the move that went in lot, but currently 
we're removing the quantity from the entire move.
https://github.com/odoo/odoo/blob/456026b5ef99388b1cf5bdd78cee8d1ad3d51304/addons/stock_account/models/product.py#L615-L618
So, at the first iteration of the while loop (for the move 
with 10 quantities), instead of doing 
fifo_stack_size(25) -= 5, we do fifo_stack_size(25) -= 10
The next move is the last one, so it's the one on which
remaining_qty_on_first_stack_move will be based on. 
remaining_qty_on_first_stack_move will be the minimum 
between the move's quantity and the fifo_stack_size. 
So because the fifo_stack_size is now wrongfully 
15 instead of 20 that's the value that will be returned
by _run_fifo_get_stack.

So inside run_fifo(), qty_on_first_move will be 15 instead of 20
https://github.com/odoo/odoo/blob/456026b5ef99388b1cf5bdd78cee8d1ad3d51304/addons/stock_account/models/product.py#L545

Issue 2) 
Another issue is that inside _run_fifo when calling
_get_valued on the move, we don't use the lot 
parameter. So we use the entire quantity of the move 
instead of the quantity specific to the lot. 
https://github.com/odoo/odoo/blob/b07ff5843ee87741b293d9e67f72a77a2ed2ed88/addons/stock_account/models/product.py#L561-L562
And we use the full value of the move instead of 
the pro rata of the value for the quantity specific 
to the lot


As a consequence, inside _run_fifo the computation 
for the fifo_cost will be 
15 (because of issue1)  * 100 $ [first iteration of the while loop]
 \+ 10 (because of issue 2) * 10$ [second iteration of the while loop]
= 1600$
Instead of 20 *100 + 5 *10$ = 2050$

Therefore the avg_cost of the lot is wrong and the 
standard price of the product will also be false.

side note: those two issues balance each other if the price unit 
of the moves are the same

needed for PR of opw-6311341

Forward-Port-Of: odoo/odoo#273728

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

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:
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

# 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

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

# 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

`_l10n_tr_nilvera_add_pdf_to_invoice` writes the response from `client.request('GET', '.../pdf')` directly into `ir.attachment.raw`. The Nilvera client sets `Accept: application/json` on the session and calls `response.json()` by default, so the returned value is a Python `str` holding the base64-encoded PDF body, not raw binary bytes.

The previous code wrote to the base64-aware `datas` field, which auto-decoded its input. An earlier fix switched to `raw` to work around a `binascii.Error` from Python 3.14's stricter base64 validation in the `datas` auto-decode path. That switch silently changed what ends up on disk (`datas` decodes its input, `raw` does not)

Storing that string in the binary `raw` field encodes it as UTF-8, so the file on disk ends up as the literal ASCII of the base64 text. The attachment is served as `application/pdf` but the browser receives base64 ASCII and cannot preview or download the PDF.

Call `b64decode(response)` before storing so the attachment contains the actual PDF bytes.

OPW-6302803

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#274501
Forward-Port-Of: odoo/odoo#270759

Description of the issue/feature this PR addresses:
This PR resolves an integration failure with the Nilvera e-invoicing provider when a company’s primary currency is configured to a foreign currency (e.g., USD) rather than the local currency (TRY). Nilvera strictly requires a valid exchange rate relative to Turkish Lira (TRY) to be included inside the XML nodes of every posted invoice utilizing a foreign currency.

Functions affected:

def _add_invoice_exchange_rate_nodes(self, document_node, vals):

def _l10n_tr_get_currency_conversion_rate(self, invoice):

Current behavior before PR:
When generating an invoice where both the company's main currency and the invoice currency are foreign (e.g., USD), the system does not calculate or embed a TRY conversion/exchange rate into the invoice payload. Because this mandatory local currency reference mapping is missing, Nilvera rejects the invoice submission.

Desired behavior after PR is merged:
For every invoice processed via the Nilvera localization, the system will explicitly calculate and inject the exchange rate between the active invoice currency and TRY into the posted document nodes, regardless of what the underlying company's primary currency is set to.




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

Forward-Port-Of: odoo/odoo#270531

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

# How to reproduce
- In the settings, enable Absence Mangement
- Create an employee with a Contract
- Create a Time off for that employee for yesterday
- Manually run the scheduled action "Attendance: Detect Absences for employees"
- Go to the attendance dashboard for that employee

# The issue
An attendance with no overtime was created for yesterday for that employee with a log note
saying "This attendance was automatically created to cover an unjustified absence on that day."
However, the absence was justified as the employee took a time off.

# Cause of the issue
When running the `_cron_absence_detection` cron job, we create "empty" attendances for the employees
that were absent yesterday. If those attendance's `overtime_hours` are 0, then we unlink them :
https://github.com/odoo/odoo/blob/a73428187112b3948a11810abae2a3c82c9c7bcd/addons/hr_attendance/models/hr_attendance.py#L659-L666

But, since `check_in` and `check_out` cannot be the same, we cannot really create an empty attedance.
We instead create an attendance of 1 second :
https://github.com/odoo/odoo/blob/a73428187112b3948a11810abae2a3c82c9c7bcd/addons/hr_attendance/models/hr_attendance.py#L652-L653

This will create an overtime of 0.003 seconds if there was a leave that day (which is our case).
This duration will be reflected in the attendance's `overtime_hours`. The issue is that we simply do
`== 0` when trying to find the attendances without overtime, so we don't unlink them.

The issue was introduced by :
https://github.com/odoo/odoo/commit/8d7859a569d9ac7303ca0b9be6c56496be14c544

Because `round(0.003, 3)` => 0 but `round(0.003, 4)` => 0.003

The issue is not present in 18.0+ because we don't create overtime if the duration is
`float_is_zero(overtime_duration, 2)` :
https://github.com/odoo/odoo/blob/39cce855aa27aa4af9225a61a3e1425383a9f49f/addons/hr_attendance/models/hr_attendance.py#L405

opw-6321883

Forward-Port-Of: odoo/odoo#272089

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

Issue:
    - When the attendance is flexible, the weekly expected hours shown in reports are incorrect.
    - This happens because the calculation is based only on the `Average Hour per Day` and doesn't take into account the `Hours per Week` set on the employee resource. It ignores the weekly limit defined in the employee's working schedule. -As a result, if an employee works more days than expected, the report may show more than the allowed weekly hours.

    Example:
    - An employee has a 32h/week contract and 8h/day.
    - If they work 5 days, the system still counts 8h as expected for each day — totaling 40h instead of 32h.

Steps To reporduce:
    - Set up a flexible contract with 32 hours/week (8 hours/day) for an employee.
    - Log 5 attendances in one week with 8 worked hours each.
    - Go to report and filter by employee by week, notice the current behavior yields 5 x 8 = 40 hours in expected_hours.

Solution:
    - Check the weekly hours cap defined in `resource_calendar_id.full_time_required_hours`.
    - If total `expected_hours` from earlier attendances this week exceeds that limit, set expected_hours = 0 for any excess.

OPW-4583064

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

Forward-Port-Of: odoo/odoo#218384

**Steps to reproduce:**

- Create a product A, tracked by lots
- Create a kit product, include a component A
- Change the UoM to 0.5
- Go to the PoS, order this kit product
- Also order the component A, with a quantity of 2
- Pay for it, ask for an invoice
- Go to the created picking
- The Demand column is correctly computed and is 0.5
- The Quantity column is wrong and is 2

**Why the fix:**

When getting the data from https://github.com/odoo/odoo/blob/e0d84c7fbb270d0d1f82572daefa96c2978d3785/addons/point_of_sale/models/stock_picking.py#L283 
we always get the component's line, as the move's product is the component, even if it used to be the kit product's move. This is because when exploding a kit's moves, it gets the kit's component as a product instead of keeping the kit product.

This was introducing a weird behavior because we took the quantity from the component line, and not from the kit line, meaning the kit would always have the same quantity as the component.

We now check if the move is actually a kit product's move, and if it is we adapt the qty to correct one by fetching the correct line's qty, and adapting it with the correct UoM.

Changing the line in itself would not work, as the kit itself is not tracked by lots, so we would not enter https://github.com/odoo/odoo/blob/e0d84c7fbb270d0d1f82572daefa96c2978d3785/addons/point_of_sale/models/stock_picking.py#L284 
and the move line would not be correctly created.

opw-6153000

Forward-Port-Of: odoo/odoo#273775
Forward-Port-Of: odoo/odoo#262551

# 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#272916
Forward-Port-Of: odoo/odoo#265781

The Thread component mirrors `thread.isLoaded` into the `state.mountedAndLoaded` flag that gates, in the template, whether the real messages are rendered. That mirroring effect both read `mountedAndLoaded` as one of its dependencies and wrote it.

`useEffect` records its dependency array before running the body, so right after the effect sets `mountedAndLoaded` to true the recorded dependencies still hold the pre-write `[isLoaded=true, mountedAndLoaded=false]` pair; that update only settles on a later, microtask-deferred patch. When a second reload runs `reset()` in that window it drives `mountedAndLoaded` back to false while `isLoaded` stays true, and the settling patch then computes the very `[true, false]` pair already recorded. The effect never re-runs, so `mountedAndLoaded` is stranded at false and no message is rendered.

Depend on a monotonic `resetCount` instead. Reading it in the effect dependency array subscribes the render to it (OWL subscribes a `useState` proxy's render callback on every read, wherever it happens), so a `reset()` bump re-renders and re-runs the mirror to re-sync `mountedAndLoaded` with `isLoaded`. Bump it only when `isLoaded`: while loading, `applyScroll` resets on every patch, so an unconditional bump would spin the render loop; the guard re-arms only in the case that heals. `reset()` still clears `mountedAndLoaded` (the false dip is needed for the reload scroll handshake), so behaviour is otherwise unchanged.

The race is not deterministically reproducible with this version's test tooling, which cannot advance the render loop a single frame, so no test is added here; the fix is covered by tests on later versions.

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

Forward-Port-Of: odoo/odoo#274059

The Thread component mirrors `thread.isLoaded` into the `state.mountedAndLoaded` flag that gates, in the template, whether the real messages are rendered. That mirroring effect both read `mountedAndLoaded` as one of its dependencies and wrote it.

`useEffect` records its dependency array before running the body, so right after the effect sets `mountedAndLoaded` to true the recorded dependencies still hold the pre-write `[isLoaded=true, mountedAndLoaded=false]` pair; that update only settles on a later, microtask-deferred patch. When a second reload runs `reset()` in that window it drives `mountedAndLoaded` back to false while `isLoaded` stays true, and the settling patch then computes the very `[true, false]` pair already recorded. The effect never re-runs, so `mountedAndLoaded` is stranded at false and no message is rendered.

Depend on a monotonic `resetCount` instead. Reading it in the effect dependency array subscribes the render to it (OWL subscribes a `useState` proxy's render callback on every read, wherever it happens), so a `reset()` bump re-renders and re-runs the mirror to re-sync `mountedAndLoaded` with `isLoaded`. Bump it only when `isLoaded`: while loading, `applyScroll` resets on every patch, so an unconditional bump would spin the render loop; the guard re-arms only in the case that heals. `reset()` still clears `mountedAndLoaded` (the false dip is needed for the reload scroll handshake), so behaviour is otherwise unchanged.

The race is not deterministically reproducible with this version's test tooling, which cannot advance the render loop a single frame, so no test is added here; the fix is covered by tests on later versions.

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

Forward-Port-Of: odoo/odoo#274059

Steps To Reproduce
------------------
1- Create a product (Goods):
- Select track inventory in General Information
- Go to inventory and set Routes to Replenish on Order (MTO)

2- Create an Sales Order for 10 units of the product and confirm.
3- Deliver 5 on the first picking, validate, and create the backorder.
4- Print the delivery slip.

Issue
-----
1- MTO: Ordered = 5, Delivered = 5, Remaining = 5.
2- Normal product: Ordered = 10, Delivered = 5, Remaining = 5.
The ordered quantity for MTO products is wrong, it shows the delivered amount instead of the original order total.

Cause
-----
The delivery report calculates the "Ordered" quantity by adding what we just delivered to what is left in the backorders. I found that the code was looking for move lines in the backorders to count what is left. When I checked a backorder that is waiting for stock (like MTO), there is no reserved stock yet, so no move lines exist. Because of this, the report thought the backorder was empty and ignored the remaining quantity.

Fix
---
I changed the calculation of `qty_ordered` to correctly handle split moves and unreserved backorders.
1. In the main loop, `qty_ordered` is now the sum of the done quantity and the demand of any linked backorders. This correctly reconstructs the total order for split moves and MTO scenarios by using `move_ids` to include unreserved moves.
2. In the secondary loop for empty moves, I added a check to skip backorders if they were already counted in the main loop. This avoids double-counting while still catching any items that were missed by the main loop.

opw-5112467


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

When an orderpoint fails during a portal user's transaction (e.g., eCommerce checkout), the system catches the `Procurement Exception` and logs a warning activity on the product template. The exception handler uses `.sudo().activity_schedule()`, which bypasses the write access restriction but leaves `env.uid` as the portal user.

Therefore, the restricted portal user permanently becomes the `create_uid` (Author) of the activity.

System exception activities should always be authored by the system (OdooBot), never by a portal or public user. This context leak corrupts the activity metadata by injecting an external user ID into internal backend logs. Chain `.with_user(SUPERUSER_ID)` to the `.sudo()` call in `stock_orderpoint.py` when scheduling the exception activity.

This ensures the environment context is stable and the activity is authored by OdooBot, which transcends multi-company record rules.

Steps to Reproduce on Runbot/Fresh Database on version 17.0:
1. Enable Multi-Company with Company A and Company B. Set Company B as the active company for the website.
2. Restrict the main Admin (Runbot) user strictly to Company A.
3. Create a Shared Product (Company field left blank).
4. Set a Reordering Rule (Orderpoint) for the product that is guaranteed to fail routing.
5. Navigate to the frontend website and sign up as a new user (this creates a Portal User in Company B).
6. As the newly signed-up Portal User, complete an eCommerce checkout for the shared product.
7. The checkout succeeds, but the backend triggers the orderpoint failure and logs the exception activity on the product template.
8. Check the chatter for this product: the `create_uid` is incorrectly set to the Portal User instead of OdooBot (1).
9. (In 19.0 Upgrade) Log in as the Admin user (set strictly to view Company A), navigate to the product, and the AccessError for reading will appear due to this leaked id.

[opw-6253978](https://www.odoo.com/odoo/my-support-tasks/6253978?debug=assets)


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

Forward-Port-Of: odoo/odoo#269395

Description of the issue/feature this PR addresses:
When grouping datetime fields by hour, `read_group` formats the group display label using `hh:00 dd MMM`.

In Babel/LDML formatting, `hh` represents a 12-hour clock. Since the format does not include an AM/PM marker, afternoon/evening hours are displayed ambiguously in grouped views.

Current behavior before PR:
A datetime value in the afternoon is grouped under a 12-hour label without AM/PM.

For example, records around `13:50` are displayed under:

    01:00 20 Mar

Similarly, a datetime value around `16:20` may be grouped under:

    04:00 26 Mar

This is ambiguous because the group header does not indicate whether the hour is AM or PM.

Example screenshot showing records around 13:xx grouped under `01:00`:
<img width="310" height="240" alt="image" src="https://github.com/user-attachments/assets/8768f2e8-9aaa-436b-af9f-40055a6032e9" />


Desired behavior after PR is merged:
Hour-based datetime group labels should be unambiguous.

The hour grouping format now uses `HH:00 dd MMM`, so grouped datetime labels render using a 24-hour clock.

For example:

    13:00 20 Mar
    16:00 26 Mar

This fixes the datetime hour grouping label shown in grouped list views and other `read_group` consumers.

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