### [FIX] website_sale: keep preview data of dynamic category snippet

Commit 08c41255d70ccbb35eff20e0a12671ffdfba3dfe loads the interaction for dynamic category snippet to show its dynamic content in snippet preview dialog.

Commit 5cd8ba3b5abcad5a119bb879a9892e0bcfe27d9f changed the condition to avoid replacing the preview data.

The dynamic category snippet's preview data does not have the class `s_dialog_preview` to mark them as preview data. Thus the interaction was started and cleared the content (but could not fill it as the snippet does not have a valid configuration yet).

This commit uses a `html_builder.snippetsPreprocessor` to add the class on the preview data of that specific snippet in the loaded snippets.

Steps to reproduce:
- Open website builder
- Click on "Catalog" snippets category
- Bug: the dynamic snippet containing categories is missing its preview data part

task-6088029

### [FIX] website_sale: scale down height of dynamic category snippet's item

Commit 08c41255d70ccbb35eff20e0a12671ffdfba3dfe enables preview of custom dynamic category snippets.

But the height of the item is not adapted to the downscaling of the iframe. Thus they looked 3 times too tall.

This commits adds a patch to the interaction when loaded in this context to adapt the computed value for the height.

Steps to reproduce:
- Open website builder
- Click on "Catalog" snippets category
- Add the dynamic category snippet
- Select the added snippet
- Save this snippet as a custom snippet
- Click on "Custom" snippets category
- Bug: the items int the snippet looks way too big

task-6088029

Forward-Port-Of: odoo/odoo#257026

Steps to reproduce:
1. Create a currency with a non-1 exchange rate with the company's
currency (e.g. VEF with a rate of 0.000005 against USD).
2. Create a pricelist in that currency.
3. Create an event.
4. Create a sale order with the new pricelist.
5. Add a sale order line with a ticket of the event and confirm
the order.
6. Go to the event's page and check the total sales smart button.
7. Check the total sales of the event: it should be equal to the sale
order's total price converted to the company's currency, but it is not,
because of the wrong conversion (it used the inverse of the correct
exchange rate, which is 200000 instead of 0.000005 in our example).

Problem:
The total sales smart button in an event's page shows wrong totals when
sales are in a currency other than the company's currency.

Cause:
The code converts the sale price from the event's currency (which is the
same as the company's currency) to each sale order's currency, while it
should be the other way around (from each sale order's currency to the
event's currency).
https://github.com/odoo/odoo/blob/3cd709172e997f5a726cf3ae85ffcb9965619fcb/addons/event_sale/models/event_event.py#L38

opw-5494790

Forward-Port-Of: odoo/odoo#258000
Forward-Port-Of: odoo/odoo#253605

Currently, when a user creates a quotation from the Opportunities available in Contacts, archived warehouses are also considered for the quotation.

## Steps to replicate:
- Install Sales, CRM, and Inventory.
- Create a new Warehouse and move it to the first position in the warehouse list view (highest priority).
- Archive the newly created warehouse.
- Navigate to Contacts > Acme Corporation > Opportunities >Office Design Project
- New Quotation > Other Info > Delivery and check the Warehouse field.

## Observed behavior
The archived warehouse is still assigned to the Warehouse field in the Delivery section. This issue does not occur when the user creates a quotation directly from the CRM app, it only happens when the quotation is created through the Contacts apps.

## Root cause:
This unintentional behavior was introduced after commit [1]. When a user opens 'Opportunities' from the contacts view, the function `action_view_opportunity` [2] is triggered, which sets `active_test` to False in the context.

Later, when a new quotation is created, the compute method [3] is executed. This method calls `_get_default_warehouse_id` [4], which performs a search. Because `active_test` is already set to False in the context, the search also includes archived warehouses, causing them to be fetched unintentionally.
[2]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/crm/models/res_partner.py#L39-L53 [3]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/sale_stock/models/sale_order.py#L194-L204 
[4]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/stock/models/res_users.py#L9-L12

## Solution:
Explicitly set `active_test=True` in the context when preparing the quotation for an opportunity. This ensures that archived warehouses are excluded from the search and prevents them from being selected.

**Alternate Solution:**
We could also make `active_test` to true when searching for warehouse directly as well.
```py
 def _get_default_warehouse_id(self): 
     # !!! Any change to the following search domain should probably 
     # be also applied in sale_stock/models/sale_order.py/_init_column. 
     return self.env['stock.warehouse'].with_context(active_test=True).search([('company_id', '=', self.env.company.id)], limit=1)
```
[1]:
https://github.com/odoo/odoo/commit/59feed9f26937ae8e2cab5cd7d2b6743ab6c0717 

opw-5999034

Forward-Port-Of: odoo/odoo#252166

Issue:
--
The query created by the function '_compute_sale_order_ids' takes
around 20-40 seconds since its doing "WHERE" searches on millions
of stock.picking records

Fix:
--
Added an index to the "lot_id" field of the stock.move.line model.
(Already existing databases can be fixed by using the webshell)

Steps to recreate the issue:
--
1. Have around a million stock.picking records
2. Go to "Inventory/Products/Lots/Serial Numbers"
3. Select any existing record or create and save a new one
4. These actions will take around 20-40 seconds to complete

Before this commit:
--
Selecting or saving any 'stock.lot' takes around 20 seconds

After this commit:
--
Selecting or saving any 'stock.lot' takes around 1-4 second

Benchmark:
--
Benchmark test was done one a database with ~4000 stock.move records and
1.74 million stock.picking records
Opw-5459842
| Before this Commit | ~20 seconds
| After this Commit | **~1-4 seconds & Memory usage just a little bit higher

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

Forward-Port-Of: odoo/odoo#255255

### Issue before this commit:
After generating a stock valuation closing entry from the Inventory Valuation report, reopening the report raised an access rights error. Users with Accounting permissions could no longer access the report.

### Steps to reproduce the issue:
1. Access the database with a user having Accounting Admin rights.
2. Go to the Inventory Valuation report.
3. Click to generate a closing entry.
4. Try to open the Inventory Valuation report again.
5. Result: System shows an access rights error.

### Cause of the issue:
The method _get_last_closing_date() retrieves the field state of the model account.move by querying the technical model ir.model.fields. However, accounting users do not have read access to this model. When the report tries to compute the last closing date after a closing entry exists, this lookup triggers an error.

### Reason to introduce the fix:
The lookup of account.move.state is only used internally to inspect tracking values in the chatter and determine the posting date of the closing entry. Since this requires reading a technical metadata model, the query is executed with sudo() to bypass the restriction while keeping the functional access to accounting data unchanged.

opw-5998151

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

Forward-Port-Of: odoo/odoo#254188

Steps to produce:
---
- Install `website_sale` module.
- Go to `website > shop`.
- Open the `Customizable Desk` product page.
- From the website editor, `enable the search bar` for the product page.
- Now search for `drawer`.

Issue:
---
- Searching from a product page always scopes results to the product's category, even when the user navigated directly to the product without selecting any category.

Root cause:
---
- The issue occurs because `_prepare_product_values()`[1] always assigns a category using the fallback `product.public_categ_ids[:1]` when no category is explicitly provided. As a result, the `keep` object is generated with `_get_shop_path(category)`[2], which produces a category-based shop URL. Since the search form action is defined as `keep(search=0)` [3] in the template, the generated search URL always includes `/shop/category/<slug>`, even when the user accessed the product page directly. This unintentionally scopes all searches to the product’s first public category instead of performing a global `/shop` search.

Solution:
---
- Separate the breadcrumb logic from the search context logic. Before automatically assigning a default category for breadcrumb display, store the originally requested category (which is None when navigating directly to a product).
- Use the auto-assigned category only for breadcrumb display.
- Use the originally requested category to build the keep QueryURL

[1]https://github.com/odoo/odoo/blob/242afb9ca3a76e3628260ac81a9f5ddcd5d445dd/addons/website_sale/controllers/main.py#L796-L799 
[2]https://github.com/odoo/odoo/blob/242afb9ca3a76e3628260ac81a9f5ddcd5d445dd/addons/website_sale/controllers/main.py#L806-L812
[3]https://github.com/odoo/odoo/blob/242afb9ca3a76e3628260ac81a9f5ddcd5d445dd/addons/website_sale/views/templates.xml#L360-L372

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

Forward-Port-Of: odoo/odoo#257375
Forward-Port-Of: odoo/odoo#251751

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/d5e0025755 [REL] 19.2.7 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/e86b78a411 [IMP] tests: add image snapshots for renderer store tests [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/fd39d34c4b [FIX] renderer: rendering tests are wrong [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/431e9d922c [IMP] tests: update jest to v30 [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/7c9bce6e6f [FIX] zoom: gauge chart rendering with zoom [Task: 5942124](https://www.odoo.com/odoo/2328/tasks/5942124)
https://github.com/odoo/o-spreadsheet/commit/c590219132 [FIX] uuid: remove useless `require` [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/9c325eeb5a [FIX] cf: add sanity checks on conditional format type/operator [Task: 6106092](https://www.odoo.com/odoo/2328/tasks/6106092)
https://github.com/odoo/o-spreadsheet/commit/75d4ee520e [FIX] live-server: specify host to avoid issues with some browsers [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/17b79f4ff5 [FIX] locked sheet: see pivot menu item on locked sheet [Task: 6033269](https://www.odoo.com/odoo/2328/tasks/6033269)
https://github.com/odoo/o-spreadsheet/commit/0e217bc9d3 [FIX] spreadsheet: chart side panel content should use full height [Task: 6080680](https://www.odoo.com/odoo/2328/tasks/6080680)
https://github.com/odoo/o-spreadsheet/commit/a9e3ba06af [FIX] xlsx: export formula that returns an error [Task: 6008904](https://www.odoo.com/odoo/2328/tasks/6008904)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

### Issue:

In certain flows, basic mrp users (mrp.group_mrp_user) can not mark MO's as done or split production due to the associated automatic creation of accounting analytics.

As concrete examples, the tests:
- test_automatic_backorder_no_redirect
- test_change_qty_produced can not be performed with a user with basic mrp access rights.

### Steps to reproduce:
- Incarnate a user with only mrp user rights
- Create and confirm an MO for 2 units with an operation
- Click on the cog wheel icon > Split production > split
#### > Access Error: You are not allowed to access 'Analytic Line' (account.analytic.line) records.

### Cause of the issue:

To begin with, members of the `mrp.group_mrp_user` do not and should not have read nor create access rights with respect to the `account.analytic.line` model. However, as soon as `mrp_account` is installed the `button_mark_done` can end up requiring such access.

1. The `_split_productions` fails for multiple reasons:

This line:
https://github.com/odoo/odoo/blob/master/addons/mrp/models/mrp_production.py#L2000 fails because of the assignment since this call:
https://github.com/odoo/odoo/blob/0c2ad21773d4a7b23038b9bed19d64952d841fa1/addons/mrp_account/models/mrp_production.py#L27-L35 requires write and read access on the `account.analytic.line` model.

This line:
https://github.com/odoo/odoo/blob/master/addons/mrp/models/mrp_production.py#L2002 fails because the `copy_data` now checks that the user has the `read` access rights of the comodel when copying `many2many` data's: https://github.com/odoo/odoo/blob/0c2ad21773d4a7b23038b9bed19d64952d841fa1/odoo/orm/models.py#L4781-L4783 This is an issue for instance for the `wip_move_ids` field that can not be copied since mrp users do not have a read access to the `account.move` comodel:
https://github.com/odoo/odoo/blob/0c2ad21773d4a7b23038b9bed19d64952d841fa1/addons/mrp_account/models/mrp_production.py#L15

This line:
https://github.com/odoo/odoo/blob/0c2ad21773d4a7b23038b9bed19d64952d841fa1/addons/mrp/models/mrp_production.py#L2017 will fail since it checks the read access right on the comodel `account.move` of the `wip_move_ids` fields.

2. The `_post_inventory`:

https://github.com/odoo/odoo/blob/afc6f4b41c63800efaa8e3ca15afe5cff5cfa0f9/addons/mrp/models/mrp_production.py#L2221 Fails as it sets the duration:
https://github.com/odoo/odoo/blob/afc6f4b41c63800efaa8e3ca15afe5cff5cfa0f9/addons/mrp/models/mrp_production.py#L1922 which calls the `_create_or_update_analytic_entry`: https://github.com/odoo/odoo/blob/afc6f4b41c63800efaa8e3ca15afe5cff5cfa0f9/addons/mrp_account/models/mrp_workorder.py#L18-L21 which it self creates and update `account.analytic.lines` to which you do not have any read access.

backport of b5c7d5fed2d893bcd5ea2c2c5ed1cb9d8dfa2424

opw-6066674

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

Forward-Port-Of: odoo/odoo#257350

Steps to Reproduce:
-
1. In the Project app, create a new project and enable "Timesheets".
2. Create a parent task with allocated hours (e.g., 20h).
3. Create one or more sub-tasks under the parent, also with allocated hours (e.g., 8h and 5h).
4. Log in to the portal and navigate to the project's task list.
5. Observe the "Total" allocated time shown in the list header.

Issue:
-
- The total allocated time displayed in the portal incorrectly sums the hours of the parent task and all its sub-tasks (e.g., 20h + 8h + 5h = 33h). This leads to an inflated and confusing total for the customer.

Cause:
-
- The `_get_portal_total_hours_dict` method calculated the sum of `allocated_hours` on the entire recordset of tasks passed to it, without distinguishing between parent tasks and their children when both were present.

Fix:
-
- This commit excludes sub-task hours from the total allocated time computation if their parent task is also present in the view.
- The total time spent now uses parent `total_hours_spent` which includes both time spent on parent and sub-task.

task-4939234

Forward-Port-Of: odoo/odoo#258485
Forward-Port-Of: odoo/odoo#221563

[FIX] html_editor: undo link autoconvert before space insertion

When adding a space after an URL, the URL text is converted to an URL.
When pressing undo, first the space is undone, then the link is undone.
This is wrong because if the user did not want a link, after undoing the
link, inserting a new space will again convert to a link.

This commit splits `handleAutomaticLinkInsertion` into two parts:
determining if a link must be created, and actually inserting the link.
This makes it possible to execute code within the condition before and
after the insertion.
To fix the similar behavior for enter and shift-enter, another before
input handler is also added in order to let the default before input be
executed before creating the link.

Steps to reproduce:
- Go to a "To do" note
- Type "odoo.com"
- Press space/enter/shift-enter
- Undo a single time

=> The insertion was undone instead of the link transform.

task-5936310


[FIX] html_editor: not include surrounding backtick in pasted URL

When pasting an URL surrounded by backticks, the ending backtick is included inside the link's HREF.

This commit fixes the regex for URL to also exclude backticks (like it did with `"` and `'`).

Steps to reproduce:
- Copy the following text in the clipboard:
```
`odoo.com`
```
- Go to a "To do" note
- Paste

=> The link's URL was
```
odoo.com`
```

task-5936310

Forward-Port-Of: odoo/odoo#258472
Forward-Port-Of: odoo/odoo#248619

### Issues:

Cancelling the move dest of a manufacturing order does not cancel the MO nor log's an activity warning for the responsible to update the manufacturing demand manually.

Additionally, when selling MTO manufactured products, cancelling the delivery and then changing the sol's demand will update the MO for an incorrect amount.

### Steps to reproduce:

- In the settings: Enable Multi-Steps Routes
- Inventory > Configuration > Warehouse Management > Routes
- Unarchive the MTO route
- Create an MTO product with BOM
- Create and confirm an SO for 3 units of that product
- Cancel the delivery of 3 units
> There is no notification on the unrelevant MO linked to the SO
- Adapt the quantity of the SOL from 3 to 10
#### > A Delivery is created for 8 units and the MO's demand is updated from 3 to 11

### Expected behavior:

Since the the SOL demand is updated to 10 units and none are currently delivered, a delivery for 10 units should be created and the MTO behavior should therefore add 10 units to be manufactured.

### Cause of the issue:

Adapting the quantity on the sale order from 3 to 10 will launch a call of the `_action_launch_stock_rule` with a `previous_product_uom_qty` of 3. The purpose of this call being to create and run a procurement to fulfill the new demand:
https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/sale_stock/models/sale_order_line.py#L388-L402
The demand of this procurement is therefore matching the new quantity of the sol minus the qty that is already handled by other procurements (determined by the `_get_qty_procurement` method): https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/sale_stock/models/sale_order_line.py#L310-L320
Note that this `_get_qty_procurement` call should determine the qty that is already planned to be delivered to and returned by the customer. In particular, this `_get_qty_procurement` call should return a value of 0.0 because the entire delivery has been cancelled and nothing is expected to be returned from the customer. However, the call will return an unexpected value of `-3.0` units which will in turn provide a procurement to the customer location for `5 - (-3) =  8` units and hence lead to the creation of a delivery for 8 units and adapt the MO by MTO for 8 additional units.

The discrepancy happening in the `_get_qty_procurement` is due to two recent changes. To begin with, since the 19.0 version the `move_finished_ids` of the production is linked to the sol (part of its `move_ids`) because of these lines:
https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/sale_stock/models/stock.py#L134-L139 This change ensuring that MO created by MTO is linked to the SO see 2713876dbc70d3984e584a9037a2206dcda4e84a for more details.

As such, the move of the produced product can now be part of the moves initially considered in the `_get_outgoing_incoming_moves` and that should be filtered out to not be accounted in the qty handled by the current sol:
https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/sale_stock/models/sale_order_line.py#L322-L331

Now, the reason this production move is not excluded from the incoming move pool is because of the change of this other fix: 37f1377344864770cd2a745dd4cb6999af07bbdf https://github.com/odoo/odoo/blob/b9845f693af28e1d9fac773ae391b29f6831e982/addons/sale_stock/models/sale_order_line.py#L353-L358 To be more precise, while the move is not not a refund, it satisfies the second part of the condition that `move.rule_id.id in triggering_rule_ids` for the incorrect reason that the move has no `rule_id` so that and that `move.rule_id.id` is False and the `triggering_rule_ids` contains the False value but this key is irrelevant and should never have been added as the purpose of the `triggering_rule_ids` list is to keep track of rules starting a push chain.

### Additional Note 

The `setUpClass` of the `TestSaleMrpFlowCommon` test class fails since https://github.com/odoo/odoo/commit/8bbdc99b565b3f678e11cd8889c47dad8944608f because the `tracking`
field is not present in the product form view if if the user does not have the `stock.group_production_lot` group:
https://github.com/odoo/odoo/blob/58fb55defee005beb44edb60d2abe044fc99121a/addons/stock/views/product_views.xml#L189
But it is suppose to be reset in the setup:
https://github.com/odoo/odoo/blob/58fb55defee005beb44edb60d2abe044fc99121a/addons/sale_mrp/tests/test_sale_mrp_flow.py#L145-L149

opw-6010109
opw-5885741
runbot-240920

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

Forward-Port-Of: odoo/odoo#254636

**Steps to reproduce:**
* Install `account_iso20022` and `hr_expense`  module.
* Create an expense with `Paid by Company` and `SEPA credit transfer` as the payment method.
* Leave the `Vendor` field empty.
* Submit, approve, and post the expense.

**Observed behavior:**
* The expense is posted successfully without a vendor, creating a payment with `partner_id = False`.
* The payment cannot be reset to draft due to the missing vendor, and SEPA XML generation fails because the creditor name (`<Cdtr><Nm>`) requires a partner.

**Cause:**
* The `hr_expense` module overrides `_compute_show_require_partner_bank`. to set `require_partner_bank_account = False` for expense payments, bypassing the partner bank validation in `account.payment.action_post`.
* `_prepare_payments_vals` uses `self.vendor_id.id` for `partner_id`, which evaluates to `False` when no vendor is set.
* The `_post` method on `account.move` only validates partner presence for invoices (sale/purchase documents), not for `entry` type moves, which payments use.

**Fix:**
* Add a validation in `hr.expense.action_post` that checks whether the payment method is `sepa_ct`. If so, `vendor_id` must be set before posting.
* This catches the issue early in the expense flow, before the payment and journal entry are created.

opw-5930687

Forward-Port-Of: odoo/odoo#252384

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

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

=> A traceback is raised.

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

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

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

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

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

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

Task-5977962

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

Forward-Port-Of: odoo/odoo#255134

### [FIX] website_sale: keep preview data of dynamic category snippet

Commit 08c41255d70ccbb35eff20e0a12671ffdfba3dfe loads the interaction for dynamic category snippet to show its dynamic content in snippet preview dialog.

Commit 5cd8ba3b5abcad5a119bb879a9892e0bcfe27d9f changed the condition to avoid replacing the preview data.

The dynamic category snippet's preview data does not have the class `s_dialog_preview` to mark them as preview data. Thus the interaction was started and cleared the content (but could not fill it as the snippet does not have a valid configuration yet).

This commit uses a `html_builder.snippetsPreprocessor` to add the class on the preview data of that specific snippet in the loaded snippets.

Steps to reproduce:
- Open website builder
- Click on "Catalog" snippets category
- Bug: the dynamic snippet containing categories is missing its preview data part

task-6088029

### [FIX] website_sale: scale down height of dynamic category snippet's item

Commit 08c41255d70ccbb35eff20e0a12671ffdfba3dfe enables preview of custom dynamic category snippets.

But the height of the item is not adapted to the downscaling of the iframe. Thus they looked 3 times too tall.

This commits adds a patch to the interaction when loaded in this context to adapt the computed value for the height.

Steps to reproduce:
- Open website builder
- Click on "Catalog" snippets category
- Add the dynamic category snippet
- Select the added snippet
- Save this snippet as a custom snippet
- Click on "Custom" snippets category
- Bug: the items int the snippet looks way too big

task-6088029

Forward-Port-Of: odoo/odoo#257026

Steps to reproduce:
1. Create a currency with a non-1 exchange rate with the company's
currency (e.g. VEF with a rate of 0.000005 against USD).
2. Create a pricelist in that currency.
3. Create an event.
4. Create a sale order with the new pricelist.
5. Add a sale order line with a ticket of the event and confirm
the order.
6. Go to the event's page and check the total sales smart button.
7. Check the total sales of the event: it should be equal to the sale
order's total price converted to the company's currency, but it is not,
because of the wrong conversion (it used the inverse of the correct
exchange rate, which is 200000 instead of 0.000005 in our example).

Problem:
The total sales smart button in an event's page shows wrong totals when
sales are in a currency other than the company's currency.

Cause:
The code converts the sale price from the event's currency (which is the
same as the company's currency) to each sale order's currency, while it
should be the other way around (from each sale order's currency to the
event's currency).
https://github.com/odoo/odoo/blob/3cd709172e997f5a726cf3ae85ffcb9965619fcb/addons/event_sale/models/event_event.py#L38

opw-5494790

Forward-Port-Of: odoo/odoo#258000
Forward-Port-Of: odoo/odoo#253605

### Issue:

In certain flows, basic mrp users (mrp.group_mrp_user) can not mark MO's as done or split production due to the associated automatic creation of accounting analytics.

As concrete examples, the tests:
- test_automatic_backorder_no_redirect
- test_change_qty_produced can not be performed with a user with basic mrp access rights.

### Steps to reproduce:
- Incarnate a user with only mrp user rights
- Create and confirm an MO for 2 units with an operation
- Click on the cog wheel icon > Split production > split
#### > Access Error: You are not allowed to access 'Analytic Line' (account.analytic.line) records.

### Cause of the issue:

To begin with, members of the `mrp.group_mrp_user` do not and should not have read nor create access rights with respect to the `account.analytic.line` model. However, as soon as `mrp_account` is installed the `button_mark_done` can end up requiring such access.

1. The `_split_productions` fails for multiple reasons:

This line:
https://github.com/odoo/odoo/blob/master/addons/mrp/models/mrp_production.py#L2000 fails because of the assignment since this call:
https://github.com/odoo/odoo/blob/0c2ad21773d4a7b23038b9bed19d64952d841fa1/addons/mrp_account/models/mrp_production.py#L27-L35 requires write and read access on the `account.analytic.line` model.

This line:
https://github.com/odoo/odoo/blob/master/addons/mrp/models/mrp_production.py#L2002 fails because the `copy_data` now checks that the user has the `read` access rights of the comodel when copying `many2many` data's: https://github.com/odoo/odoo/blob/0c2ad21773d4a7b23038b9bed19d64952d841fa1/odoo/orm/models.py#L4781-L4783 This is an issue for instance for the `wip_move_ids` field that can not be copied since mrp users do not have a read access to the `account.move` comodel:
https://github.com/odoo/odoo/blob/0c2ad21773d4a7b23038b9bed19d64952d841fa1/addons/mrp_account/models/mrp_production.py#L15

This line:
https://github.com/odoo/odoo/blob/0c2ad21773d4a7b23038b9bed19d64952d841fa1/addons/mrp/models/mrp_production.py#L2017 will fail since it checks the read access right on the comodel `account.move` of the `wip_move_ids` fields.

2. The `_post_inventory`:

https://github.com/odoo/odoo/blob/afc6f4b41c63800efaa8e3ca15afe5cff5cfa0f9/addons/mrp/models/mrp_production.py#L2221 Fails as it sets the duration:
https://github.com/odoo/odoo/blob/afc6f4b41c63800efaa8e3ca15afe5cff5cfa0f9/addons/mrp/models/mrp_production.py#L1922 which calls the `_create_or_update_analytic_entry`: https://github.com/odoo/odoo/blob/afc6f4b41c63800efaa8e3ca15afe5cff5cfa0f9/addons/mrp_account/models/mrp_workorder.py#L18-L21 which it self creates and update `account.analytic.lines` to which you do not have any read access.

backport of b5c7d5fed2d893bcd5ea2c2c5ed1cb9d8dfa2424

opw-6066674

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

Forward-Port-Of: odoo/odoo#257350

[FIX] html_editor: undo link autoconvert before space insertion

When adding a space after an URL, the URL text is converted to an URL.
When pressing undo, first the space is undone, then the link is undone.
This is wrong because if the user did not want a link, after undoing the
link, inserting a new space will again convert to a link.

This commit splits `handleAutomaticLinkInsertion` into two parts:
determining if a link must be created, and actually inserting the link.
This makes it possible to execute code within the condition before and
after the insertion.
To fix the similar behavior for enter and shift-enter, another before
input handler is also added in order to let the default before input be
executed before creating the link.

Steps to reproduce:
- Go to a "To do" note
- Type "odoo.com"
- Press space/enter/shift-enter
- Undo a single time

=> The insertion was undone instead of the link transform.

task-5936310


[FIX] html_editor: not include surrounding backtick in pasted URL

When pasting an URL surrounded by backticks, the ending backtick is included inside the link's HREF.

This commit fixes the regex for URL to also exclude backticks (like it did with `"` and `'`).

Steps to reproduce:
- Copy the following text in the clipboard:
```
`odoo.com`
```
- Go to a "To do" note
- Paste

=> The link's URL was
```
odoo.com`
```

task-5936310

Forward-Port-Of: odoo/odoo#258337
Forward-Port-Of: odoo/odoo#248619

Currently, when a user creates a quotation from the Opportunities available in Contacts, archived warehouses are also considered for the quotation.

## Steps to replicate:
- Install Sales, CRM, and Inventory.
- Create a new Warehouse and move it to the first position in the warehouse list view (highest priority).
- Archive the newly created warehouse.
- Navigate to Contacts > Acme Corporation > Opportunities >Office Design Project
- New Quotation > Other Info > Delivery and check the Warehouse field.

## Observed behavior
The archived warehouse is still assigned to the Warehouse field in the Delivery section. This issue does not occur when the user creates a quotation directly from the CRM app, it only happens when the quotation is created through the Contacts apps.

## Root cause:
This unintentional behavior was introduced after commit [1]. When a user opens 'Opportunities' from the contacts view, the function `action_view_opportunity` [2] is triggered, which sets `active_test` to False in the context.

Later, when a new quotation is created, the compute method [3] is executed. This method calls `_get_default_warehouse_id` [4], which performs a search. Because `active_test` is already set to False in the context, the search also includes archived warehouses, causing them to be fetched unintentionally.
[2]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/crm/models/res_partner.py#L39-L53 [3]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/sale_stock/models/sale_order.py#L194-L204 
[4]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/stock/models/res_users.py#L9-L12

## Solution:
Explicitly set `active_test=True` in the context when preparing the quotation for an opportunity. This ensures that archived warehouses are excluded from the search and prevents them from being selected.

**Alternate Solution:**
We could also make `active_test` to true when searching for warehouse directly as well.
```py
 def _get_default_warehouse_id(self): 
     # !!! Any change to the following search domain should probably 
     # be also applied in sale_stock/models/sale_order.py/_init_column. 
     return self.env['stock.warehouse'].with_context(active_test=True).search([('company_id', '=', self.env.company.id)], limit=1)
```
[1]:
https://github.com/odoo/odoo/commit/59feed9f26937ae8e2cab5cd7d2b6743ab6c0717 

opw-5999034

Forward-Port-Of: odoo/odoo#252166

Steps to reproduce
1. Create a to-do from the To-do app (no project set, appears as "Private")
2. Open the Project app, go to My Tasks, open the to-do
3. The "Private" label shows correctly
4. Refresh the page

Issue
After refresh, the "Private" label vanishes and the project field becomes required (red), making the record unsavable.

The web client merges (ORs) the `required` attribute of fields sharing the same name across view nesting levels. Commit 46adf760a3a33 introduced `required="1"` on the sub-task `project_id` inside the `child_ids` One2many list: https://github.com/odoo/odoo/blob/46adf760a3a33e48d34fe99c565a8c6c1194fb65/addons/project/views/project_task_views.xml#L479

This causes the main form's `project_id` required expression (`parent_id or child_ids or is_template`) to be ORed with `1`, always evaluating to true. On initial navigation the sub-task list is not yet loaded so it works, but on a full page refresh all field attributes are merged at once, making the main task's project field unconditionally required.

Solution
Change the sub-task's `project_id` required expression to `parent_id or child_ids or is_template`, matching the main form's field. This still evaluates to true for sub-tasks (they always have a `parent_id`) while no longer forcing true on standalone to-dos that have no project.

opw-6008266

Issue:
--
The query created by the function '_compute_sale_order_ids' takes
around 20-40 seconds since its doing "WHERE" searches on millions
of stock.picking records

Fix:
--
Added an index to the "lot_id" field of the stock.move.line model.
(Already existing databases can be fixed by using the webshell)

Steps to recreate the issue:
--
1. Have around a million stock.picking records
2. Go to "Inventory/Products/Lots/Serial Numbers"
3. Select any existing record or create and save a new one
4. These actions will take around 20-40 seconds to complete

Before this commit:
--
Selecting or saving any 'stock.lot' takes around 20 seconds

After this commit:
--
Selecting or saving any 'stock.lot' takes around 1-4 second

Benchmark:
--
Benchmark test was done one a database with ~4000 stock.move records and
1.74 million stock.picking records
Opw-5459842
| Before this Commit | ~20 seconds
| After this Commit | **~1-4 seconds & Memory usage just a little bit higher

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

Forward-Port-Of: odoo/odoo#255255

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

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

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

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

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

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

opw-5881976

Forward-Port-Of: odoo/odoo#256486

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/dfe248143f [REL] 19.1.14 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/4ffd4dcb57 [IMP] tests: add image snapshots for renderer store tests [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/8e47b01f6f [FIX] renderer: rendering tests are wrong [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/ac3c47f78a [IMP] tests: update jest to v30 [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/80781d1730 [FIX] zoom: gauge chart rendering with zoom [Task: 5942124](https://www.odoo.com/odoo/2328/tasks/5942124)
https://github.com/odoo/o-spreadsheet/commit/45a6362d99 [FIX] uuid: remove useless `require` [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/1832943a61 [FIX] cf: add sanity checks on conditional format type/operator [Task: 6106092](https://www.odoo.com/odoo/2328/tasks/6106092)
https://github.com/odoo/o-spreadsheet/commit/aa16066e98 [FIX] live-server: specify host to avoid issues with some browsers [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/3dd022cec7 [FIX] spreadsheet: chart side panel content should use full height [Task: 6080680](https://www.odoo.com/odoo/2328/tasks/6080680)
https://github.com/odoo/o-spreadsheet/commit/053f945858 [FIX] xlsx: export formula that returns an error [Task: 6008904](https://www.odoo.com/odoo/2328/tasks/6008904)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

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

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

=> this opens message actions in bottom sheet

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

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

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

Task-6008171

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

Steps to Reproduce:
-
1. In the Project app, create a new project and enable "Timesheets".
2. Create a parent task with allocated hours (e.g., 20h).
3. Create one or more sub-tasks under the parent, also with allocated hours (e.g., 8h and 5h).
4. Log in to the portal and navigate to the project's task list.
5. Observe the "Total" allocated time shown in the list header.

Issue:
-
- The total allocated time displayed in the portal incorrectly sums the hours of the parent task and all its sub-tasks (e.g., 20h + 8h + 5h = 33h). This leads to an inflated and confusing total for the customer.

Cause:
-
- The `_get_portal_total_hours_dict` method calculated the sum of `allocated_hours` on the entire recordset of tasks passed to it, without distinguishing between parent tasks and their children when both were present.

Fix:
-
- This commit excludes sub-task hours from the total allocated time computation if their parent task is also present in the view.
- The total time spent now uses parent `total_hours_spent` which includes both time spent on parent and sub-task.

task-4939234

Forward-Port-Of: odoo/odoo#258485
Forward-Port-Of: odoo/odoo#221563

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

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

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

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

task-6038029

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

### Issue before this commit:
After generating a stock valuation closing entry from the Inventory Valuation report, reopening the report raised an access rights error. Users with Accounting permissions could no longer access the report.

### Steps to reproduce the issue:
1. Access the database with a user having Accounting Admin rights.
2. Go to the Inventory Valuation report.
3. Click to generate a closing entry.
4. Try to open the Inventory Valuation report again.
5. Result: System shows an access rights error.

### Cause of the issue:
The method _get_last_closing_date() retrieves the field state of the model account.move by querying the technical model ir.model.fields. However, accounting users do not have read access to this model. When the report tries to compute the last closing date after a closing entry exists, this lookup triggers an error.

### Reason to introduce the fix:
The lookup of account.move.state is only used internally to inspect tracking values in the chatter and determine the posting date of the closing entry. Since this requires reading a technical metadata model, the query is executed with sudo() to bypass the restriction while keeping the functional access to accounting data unchanged.

opw-5998151

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

Forward-Port-Of: odoo/odoo#254188

---
When in the chatter, we can create an activity. If we add
an attachment to the notes of this activity and save it, the
overview of the attachment won't show in the chatter.

1. Open an app that gives you access to the chatter, for
 instance, an invoice in Accounting.
2. Click on Activity. Click on Log a Note... and on the
button Upload a file. Upload an attachment and save.

The overview of the file (blue box with the name of the
attachment) should appear.

The overview doesn't appear

Since 19.0, we want to replace static rendering with
embedded components everywhere for rendering attachments, but
this creates issues for the rendering of the overview in the
chatter. Therefore, after internal discussion, we agreed
to keep rendering overviews statically.

Backport of: https://github.com/odoo-dev/odoo/commit/4a2412b93bcac9e71826f7c0101243cdb882ddf6

opw-6035026

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

Forward-Port-Of: odoo/odoo#254814

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

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

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

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

opw-6099340

Forward-Port-Of: odoo/odoo#258006

**steps to reproduce:**
1. Create a contact
2. On the accounting tab, add one bank account
3. Change the name of the contact
4. The record's name updates automatically the field "Account Holder Name"

**problem:**
When changing a profile's name in the contacts app, the account holder name changes to be the same as the profile's name.

**expected behaviour:**
"Make the account holder name update if partner.name is changed ONLY if they were the same before the change. Otherwise keep the account holder name as is." - Referenced from the feature ticket: 5222712

That means if contact's name is the same as the account holder name, then any change to the contact's name, should as well update 'account holder name' accordingly, but if you changed the account holder name itself, then you change contact's name (if they're not the same) then the account holder name shouldn't be updated to match the contact's name.

**cause:**
The account holder name depends on `partner_id.name`
https://github.com/odoo/odoo/blob/2394a9a7f0ece2d5a2185fa4e715d943fc044733/odoo/addons/base/models/res_bank.py#L104-L107

So whenever you change the contact's name, the account holder name changes accordingly.

**Fix:**
Upon creation, the account holder name is set to the partner name if no name is provided. Additionally, when the partner name changes, the account holder name is updated only if it previously matched the partnername; otherwise, it is left unchanged.

**NOTE:**
This is a backport of this PR: https://github.com/odoo/odoo/pull/233965

opw-5913464

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

Forward-Port-Of: odoo/odoo#256439
Forward-Port-Of: odoo/odoo#248886

… sheet

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

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

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

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

opw-5883505

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

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

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

As a result, the check is bypassed.

opw-6041241

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

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

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

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

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

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


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

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

opw-6061568

Forward-Port-Of: odoo/odoo#255735

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

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

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

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

opw-5955875

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

Forward-Port-Of: odoo/odoo#254833

__

## Short functional explanation of the error
When printing labels of lot or serial products with a custom paper format, the obtained pdf contains several empty pages.

## Reproduction Steps
1. Enable Debug Mode. In Settings, click on the Technical tab. In the reporting section, click on Paper Format.
2. Click on New. Give a name to your paper format. In the Paper Size field, select Custom. For Page Height and Page Width, make sure that they're smaller than A4 measurements. For example, set the Page Height at 57 and Page Width at 35. Set Margins at 0. In the Associated Reports field, select `lot/Serial Number (PDF)`.
3. Go to Inventory. Click on the Products tab > Lots / Serial Numbers. Click on any Serial Number. Click on the Cog on the top left > Print > Lots / Serial Number (PDF).

### Expected behavior
We obtain a PDF of only one page containing the barcode of the serial number.

### Unexpected behavior
We obtain a PDF of 5 pages, including 4 blank pages and only one page holding the barcode.

## Origin of the issue
In the XML of the label reports, we use the css class `o_label_sheet`: https://github.com/odoo/odoo/blob/ec2300456599e2b3bed5ba130badb63bb9bf15b3/addons/stock/report/report_lot_barcode.xml#L9 In this class, the height and width of sheets are hardcoded to A4 dimensions:
https://github.com/odoo/odoo/blob/ec2300456599e2b3bed5ba130badb63bb9bf15b3/addons/product/static/src/scss/report_label_sheet.scss#L5-L6 Therefore, if we set the dimensions of the custom paper format to be smaller than an A4 page, we'll obtain several blank pages, until the dimensions of an A4 pages are met.
Moreover, the dimensions of the padding are also hardcoded, which can be an issue in the case of very small custom dimensions. Finally, we nest barcodes in an HTML table:
https://github.com/odoo/odoo/blob/ec2300456599e2b3bed5ba130badb63bb9bf15b3/addons/stock/report/report_lot_barcode.xml#L10 for which we hardcode the dimensions:
https://github.com/odoo/odoo/blob/ec2300456599e2b3bed5ba130badb63bb9bf15b3/addons/stock/report/report_lot_barcode.xml#L6-L7 This will result in always printing the same amount of barcodes per row in the case of batch printing, even if the dimensions are too small to hold them all. This will also result in always nesting 12x4 barcodes, even when only printing one, while hiding the others, which also produces additional unrequired blank pages.

Therefore, we need the dimensions indicated in the paper format of the report to dynamically compute
the dimensions of the padding and the rows/columns of the HTML table.
__
opw-6071885

## Issue
When logged as a portal user, clicking the *Edit* button on a message in the chatter does not do anything.

## Steps to reproduce
1. Install *Project* (`project`)
2. Create a Project P and a Task T
3. In the Setting of Project P, click *Share Project* and select a portal user
4. Logged as a portal user, open Task T, send a message in the chatter, then try to edit it by clicking the *Edit* (pencil) button.
5. **Nothing happens, but a traceback appears in the console: _Caused by: TypeError: Cannot read properties of null (reading 'id')_**

## Cause
The condition causing this error is the following:

https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L9-L13

where `this.thread` is not defined yet. Other conditions in this patch check for `this.thread` before trying to read its `id` [[1](https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L25), [2](https://github.com/odoo/odoo/blob/5cfdc9260653a2b22eb79b16702769928d450932/addons/project/static/src/project_sharing/chatter/composer_patch.js#L32)], which leads to believe that the check was simply forgotten in this condition.

opw-6072570

Starting version 2.1.4 of markupsafe, they decided to adapt the `striptags` function to use in-python-loops instead of the original implemenation that relied on pre-compiled regex.

A problem has been spotted with qweb templates that used `striptags` with large inputs, which led to the investigation of this function and it was found that the old implementation is actually faster. In fact, the PR introducing this change in Markupsafe, made these claims with no benchmarks whatsoever: https://github.com/pallets/markupsafe/pull/413/changes 

The new implementation of markupsafe is O(N x M), where n is the number of tags and M being the length of the input string. The old regex approach does a single c-level scan to check the existence of the regex which is performing much better for varying input size.

The benchmark cases below are in the form `<case_description>_<number_of_tags>`. We can see that in the cases where the current implementation is slightly faster is when there are no tags in the input which can be explained by the fact that the while loops will simply exit early. The time lost in the regex implementation is likely due to the deeper call stack to scan for the regex. Apart from that, in the case of an unclosed tag, the regex implementation is also slower because it still needs to scan the entire line. However, in that case the time taken is a handful of milliseconds, so it's not really a performance regression there either.

Apart from that, the old implementation is consistently much more performant, for both small and large inputs.

Benchmarks:

| Case                                      | Regex ms | Current ms | Speedup |
|----------------------------------------------|----------|------------|---------|
| plain_text_50k_words                         | 3.020    | 2.627      | 0.9x ← current_implementation |
| unclosed_tag_then_50kb_text                  | 0.367    | 0.032      | 0.1x ← current_implementation |
| unclosed_tag_then_500kb_text                 | 3.787    | 0.273      | 0.1x ← current_implementation |
| multiple_unclosed_open_tags_then_50kb_text   | 18.912   | 0.371      | 0.0x ← current_implementation |
| multiple_unclosed_open_tags_then_500kb_text  | 189.007  | 8.209      | 0.0x ← current_implementation |
| unclosed_comment_then_500kb_text             | 7.276    | 0.412      | 0.1x ← current_implementation |
| 5k_small_tags                                | 0.986    | 22.096     | 22.4x ← regex_old_implementation |
| 20k_small_tags                               | 4.125    | 492.186    | 119.3x ← regex_old_implementation |
| 50k_small_tags                               | 12.658   | 5499.602   | 434.5x ← regex_old_implementation |
| 1k_nested_divs                               | 0.155    | 0.923      | 5.9x ← regex_old_implementation |
| 10k_nested_divs                              | 1.648    | 48.410     | 29.4x ← regex_old_implementation |
| 2k_tags_with_attrs                           | 1.058    | 12.013     | 11.4x ← regex_old_implementation |
| 20k_tags_with_attrs                          | 13.185   | 6068.755   | 460.3x ← regex_old_implementation |
| 2k_multiline_tags                            | 0.815    | 10.819     | 13.3x ← regex_old_implementation |
| 20k_multiline_tags                           | 8.939    | 4231.768   | 473.4x ← regex_old_implementation |
| 1k_comments                                  | 0.222    | 1.292      | 5.8x ← regex_old_implementation |
| 1k_comments_hiding_tags                      | 0.163    | 1.121      | 6.9x ← regex_old_implementation |
| 2k_mixed                                     | 0.278    | 2.392      | 8.6x ← regex_old_implementation |
| 10k_mixed                                    | 1.400    | 50.959     | 36.4x ← regex_old_implementation |
| qweb_shop_200_products                       | 0.907    | 7.880      | 8.7x ← regex_old_implementation |
| qweb_shop_1000_products                      | 4.296    | 194.647    | 45.3x ← regex_old_implementation |


This PR is needed because requirements.txt in Odoo specifies the following dependency:
`MarkupSafe==2.1.5 ; python_version >= '3.12' \# (Noble)`

This means that all versions running Ubuntu Noble, will be having the same issue introduced in version 2.1.4 of markupsafe.

opw-5999688

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

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

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

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

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

opw-6099340

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

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

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

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

opw-6088424

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/74d5391b59 [REL] 18.0.63 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/3070d45ea6 [IMP] tests: add image snapshots for renderer store tests [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/2b5930f24e [FIX] renderer: rendering tests are wrong [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/936b957cbd [IMP] tests: update jest to v30 [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/8a7a1a8985 [FIX] format: keep negative accounting suffix in large number [Task: 6068834](https://www.odoo.com/odoo/2328/tasks/6068834)
https://github.com/odoo/o-spreadsheet/commit/e3bb0e35e4 [FIX] cf: add sanity checks on conditional format type/operator [Task: 6106092](https://www.odoo.com/odoo/2328/tasks/6106092)
https://github.com/odoo/o-spreadsheet/commit/3591e31de4 [FIX] live-server: specify host to avoid issues with some browsers [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

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

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

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

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

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

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

task - 6006693

Step to reproduce:
- have two pos, both trust each other, pos  A and B
- open pos A , create a order and save it
- go to backend , open pos B
- process the order, go to backend
- open pos A (notice, last save order is still loaded)
- removed older lines, and add new ones and save this again
- go to backend and open pos B
- notice that order is not loaded in other pos

Cause:
- Draft orders are stored in local storage.
- When shared with another POS, `pos.order` is created via `create_from_ui` and receives a `server_id`.
- If that order is later processed from another POS, the backend state changes.
- When the original POS is reopened, the local data still treats the order as draft.
- Saving the order again does not create a new order because it already has a `server_id`.
- This causes inconsistency with the backend and prevents the order from appearing in other POS sessions.

Fix:
- Before loading orders from JSON, verify that orders with `server_id` are still in `draft` state on the server.
- Discard orders whose backend state is no longer `draft`. 
 
opw-5946355

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

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

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

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

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

opw-6075119

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

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

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


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


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

→ The composer is not accessible.

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

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

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

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

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/3b0f1d2600 [REL] 17.0.89 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/7abf8f9dd0 [REM] doc: remove tsdoc [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/208f0e8511 [IMP] tests: add image snapshots for renderer store tests [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/c3eca65cdc [FIX] renderer: rendering tests are wrong [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/a1d9f1bb45 [IMP] tests: update jest to v30 [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/148bd3c9d8 [FIX] cf: add sanity checks on conditional format type/operator [Task: 6106092](https://www.odoo.com/odoo/2328/tasks/6106092)
https://github.com/odoo/o-spreadsheet/commit/6a0f89d792 [FIX] live-server: specify host to avoid issues with some browsers [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>