## The Problem

Validating receipts with a large number of operations by creating a backorder was timing out due to $O(N*M)$ filtering inside `_get_qty_received_without_self`, where N is the number of moves in the picking, and M is the number of moves being processed for valuation.

This happened while computing price units for moves one by one: each move filtered all picking moves to find the ones with the same `product_id`.

Another issue was a PostgreSQL `"memory exhausted"` error caused by generating a large number of OR'ed conditions, equal to the number of processed moves.

## The Solution

The massive filtering was fixed by filtering moves of the `purchase_line` instead of the `picking`, which is typically associated with only a few moves. This is still correct as the loop just after already ignores moves that don't have the same `purchase_line_id` of `self` anyways.


The PostgreSQL error was fixed by grouping moves by `location_dest_id` and generating one condition per location using an `in` clause, which is typically much smaller than generating one condition per move.

## Benchmark

Benchmark on a customer database, validating a receipt with 10k+ operations by creating a backorder:

```text
Time: timeout -> 6 min
```

OPW-6272667

Forward-Port-Of: odoo/odoo#273555
Forward-Port-Of: odoo/odoo#269350

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

Issue
-----
When using Sendcloud batch deliveries, users get a traceback if the transfer is split into multiple packages.

Steps to reproduce
-----
- Setup Sendcloud
	- Enable batch delivery
- Create a delivery for 2 units of a product
	- Delivery method set to sendcloud
- Put each unit in a separate package
- Validate the delivery

> Traceback

Cause
-----
Bug introduced by #90302 (so only present in 19.3+).

When using the batch deliveries option, the packages are sent in a single list. This means that, in `_prepare_parcel`, when we iterate over the packages, `pkg` can be a list

https://github.com/odoo/enterprise/blob/2c89c8e5da7dcb83d5a60c9616de4d5d07f0b9ab/delivery_sendcloud/models/sendcloud_service.py#L462

This means that `pkg.name` will fail

https://github.com/odoo/enterprise/blob/2c89c8e5da7dcb83d5a60c9616de4d5d07f0b9ab/delivery_sendcloud/models/sendcloud_service.py#L481

Considering that a batch delivery uses the same reference number on all labels, we can pass `None` as a fallback to `_get_unique_order_number_reference` (it is an accepted value)

https://github.com/odoo/enterprise/blob/2c89c8e5da7dcb83d5a60c9616de4d5d07f0b9ab/delivery_sendcloud/models/sendcloud_service.py#L388-L393

-----
Ticket:
opw-6267928

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

`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

Currently when a shopfloor operator modifies the operator, operator images are not visible and only place holder images are visible.

## Steps to produce:
- Install Manufacturing with demo data
- Login as Marc Demo
- Open shopfloor

## Observed Behavior:
Operator is unable to see their own profile picture and when you press the Edit Operator the operator is not able to see their as well as other operators images as well.

## Root cause:
This issue occurs because by default an operator's user does not have access right for `Employees` in Human Resources section as they are not an HR officer nor an administrator.

So when the user tries to access the image url that is meant for users with those access rights (HR officer / Administrator) at [1] and at [2].

The system returns a placeholder image instead of the employee image since the operator does not have access to hr employee model but does have access to hr employee public as per this [commit](https://github.com/odoo/odoo/commit/c9ca3761464413327d2beb697553a3ccd7eef4d1)

[1]-
https://github.com/odoo/enterprise/blob/5fe2fb44f4c8a938390343f7cdc90674cbf09391/mrp_workorder/static/src/mrp_display/dialog/mrp_employee_dialog.js#L16 
[2]-
https://github.com/odoo/enterprise/blob/5fe2fb44f4c8a938390343f7cdc90674cbf09391/mrp_workorder/static/src/mrp_display/employees_panel.xml#L9-L10 

## Solution:
Allowing operators to see images can be done by modifying the links to use the public model instead of the private model.

This will allow operators see other operators based on images and should improve user experience.

| Before |
|--------|
| <img width="1865" height="844" alt="image" src="https://github.com/user-attachments/assets/c28f4209-0a60-486a-bfec-2a4db39cd946" /> |
| <img width="995" height="899" alt="image" src="https://github.com/user-attachments/assets/7541edd9-6cc9-42d1-b5c5-39e0740d9a93" /> | 

| After |
|--------|
| <img width="1881" height="903" alt="image" src="https://github.com/user-attachments/assets/df3f8357-5cc2-4688-83dd-9a009fd56957" /> |
| <img width="1221" height="862" alt="image" src="https://github.com/user-attachments/assets/c9d72b07-e1ad-43e4-85f5-00d8f1db9095" /> | 



opw-6321989

Forward-Port-Of: odoo/enterprise#121751

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

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

Steps to reproduce:
---------------------------------------
1. Install Subscription Module
2. Create and Confirm SO with no recurring plan and a non-recurring product
3. Add a recurring product > Save SO > Observe the User Error
4. Now add the same recurring product through Catalog View

Observation:
---------------------------------------
No User Error raised stating
'You cannot save a sale order with recurring product and no subscription plan.'

Issue:
---------------------------------------
When you manually add a line and click 'Save', the constraint (`_constraint_subscription_plan`) is triggered and raised `UserError` https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/sale_subscription/models/sale_order.py#L176-L177

When you add a product via the catalog view, it calls `_update_order_line_info` which directly creates/updates order lines, Which do not trigger the python constraint.
https://github.com/odoo/odoo/blob/ef9772bba1515bdaf5410c3af5a3e395f562d513/addons/sale/models/sale_order.py#L1926-L1933

Solution:
---------------------------------------
Two private helpers are introduced:
* `_is_exempt_from_subscription_plan_check`: single source of truth for all exempt states (draft, cancelled, upsell, and legacy upgrade orders).
* `_check_recurring_plan_mismatch`: raises a `UserError` when the order has or will have a recurring product but no subscription plan, reusing the exemption helper so both call sites stay in sync.

`_constraint_subscription_plan` is refactored to delegate to these helpers, and `_update_order_line_info` is overridden to call `_check_recurring_plan_mismatch` before the catalog update is applied, ensuring consistent validation across both entry points.

opw-6194865

Forward-Port-Of: odoo/enterprise#122799
Forward-Port-Of: odoo/enterprise#117879

When scanning a package then a package type, from the point of view of the user nothing happend, and in the backend it will created a new package but it will not link it to the products nor will it show any warning.

Steps to reproduce:
-------------------
* Install barcode and stock
* Enable packages in settings
* Open Inventory
* Create a product,
* Create a Package Type -> barcode PACKTYPE,
* Create a Package linked to this package type -> PACK,
* Add at least 2 unit of product to this package,
* Create a delivery for 2 unit of the product,

Open Barcode
* Operation > Delivery orders > your delivery
* Erase the destination package from the first line
* Scan PACK
( don't click on the green line)
* Scan PACKTYPE

**Actual behavior**
create a new package but does not link it to the new products

**Expected behavior**
create a new package and set it as destination package.

Observation:
-------------
When scanning the package (PACK), we will go through ```_processPackage``` -> ```async _processPackage``` where in the end the line is unselected:
https://github.com/odoo/enterprise/blob/39d8a473fe03038ca0494a6a8165e3eb75bd8492/stock_barcode/static/src/models/barcode_picking_model.js#L2090

When we scan our package type (PACKTYPE), we will go to ``` _processPackage``` -> ```_processPackage```->```_processPackageType```  
where we will obtains packagesIds checking that we have a source package:
https://github.com/odoo/enterprise/blob/7cd9834d1d918f12dec43844cae6f112309e5772/stock_barcode/static/src/models/barcode_picking_model.js#L2123-L2132
and will send us to ```_putPackInPack```:
https://github.com/odoo/enterprise/blob/7cd9834d1d918f12dec43844cae6f112309e5772/stock_barcode/static/src/models/barcode_picking_model.js#L2133-L2136

Where we will avoid the empty packageIds since we checked on the source package and not the destination package:
https://github.com/odoo/enterprise/blob/2b887d094c66be7aebd92fbf735b1852f5dde4b5/stock_barcode/static/src/models/barcode_picking_model.js#L2296-L2299
and will call ```action_put_in_pack``` from the packaging model:
https://github.com/odoo/enterprise/blob/2b887d094c66be7aebd92fbf735b1852f5dde4b5/stock_barcode/static/src/models/barcode_picking_model.js#L2301-L2306

In ```action_put_in_pack``` will create a new packaging and put it as a the new destination package, but since the ```previous_dest_package``` (saved in db) was itself, he will [erase the link](https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/stock/models/stock_package.py#L354-L363) he just made.

Which means that in our case, we created a package without linking it to anything.

Even if we avoid the function to erase the destination package, since the destination package shown in barcode is the one from move line :
https://github.com/odoo/enterprise/blob/d0d0a3cf4a02bf24cf502b533e494fe7ca155eb3/stock_barcode/static/src/components/line.js#L115-L117
It will not show the new package in barcode


opw-5449729

Forward-Port-Of: odoo/enterprise#119758
Forward-Port-Of: odoo/enterprise#104876

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

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

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

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

**Issue**
In subcontracting, deleting a raw move line and adding a new one in the same editing flow can lead to a validation error during production recording.

**Steps to reproduce**
- Create a subcontracting product with a comp A
- Create and confirm a purchase order of that product (with the subcontracting partner)
- Open the associated delivery
- Open the move details (hamburger button)
- Delete the move line linked to the comp A
- Create a new move line for a comp B with a quantity of 1
- Record the production
-> A validation error occurs: the mandatory field `product_uom_id` is not set.

**Cause**
The regression comes from this commit: https://github.com/odoo/odoo/commit/54f10b56f577ad9ed5575bd396dba7d20d22fc2e

While assigning `move_raw_ids`, the inverse method is triggered:
https://github.com/odoo/odoo/blob/9267b2d1a9b2d2d6a33eceab07d572406c68c723/addons/mrp_subcontracting/models/mrp_production.py#L34
At this stage, newly added lines are still virtual records (`line`):
https://github.com/odoo/odoo/blob/9267b2d1a9b2d2d6a33eceab07d572406c68c723/addons/mrp_subcontracting/models/mrp_production.py#L38
The previous implementation directly unlinked removed move lines (see commit https://github.com/odoo/odoo/commit/54f10b56f577ad9ed5575bd396dba7d20d22fc2e):
https://github.com/odoo/odoo/blob/9267b2d1a9b2d2d6a33eceab07d572406c68c723/addons/mrp_subcontracting/models/mrp_production.py#L40-L43
Which will eventually flush and invalidate all the cache:
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/odoo/models.py#L4666
And since `line` is a virtual record (not in db), its associated values will be reset, among those, `product_uom_id`.
Later, when the move line is reassigned:
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/addons/mrp_subcontracting/models/mrp_production.py#L49
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/odoo/models.py#L5223-L5228

the validation fails because the virtual line no longer contains the required values.

**Additional note**
An alternative could have been using Command but since this line:
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/addons/mrp_subcontracting/models/mrp_production.py#L42
can not be converted to:
`Command.set([line.id for line in lines])`
because `lines` may also contain virtual records.
This causes an invalid quantity for the move. Indeed, even if the command operator would update the quantity
on the `move_line` correctly, it won't for the quantity of the `move` because of its associated compute method:
https://github.com/odoo/odoo/blob/26ba95ac1c5bbb24975efb1a6f53c1ab47b61532/addons/stock/models/stock_move.py#L399-L400
that relies on `.ids`, which is `[]` on virtual records.
Therefore, keep the change minimal.

opw-6133281

Forward-Port-Of: odoo/odoo#270436
Forward-Port-Of: odoo/odoo#263058