### [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

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

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/4836743b29 [REL] 18.3.42 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/8dea05219d [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/f805024e56 [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/29ff649f02 [FIX] renderer: rendering tests are wrong [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/eefd1535f5 [IMP] tests: update jest to v30 [Task: 5933130](https://www.odoo.com/odoo/2328/tasks/5933130)
https://github.com/odoo/o-spreadsheet/commit/66bda8d726 [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/e33b14cf0c [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/0226237dd2 [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>

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

### [IMP] databases: remove xmlrpc fallback for odoo.com

Since odoo.com migrated to 19.0, it will always support the json2 API, and XMLRPC support will be dropped on the next version.

In order to simplify the code and avoid subsequent requests in case of errors on the json2 API, the XMLRPC fallback is stripped off from `databases.api`.

In this commit, we only adapt the tests so that they don't test the fallback to XMLRPC when calling odoo.com. In the next commit, we will remove the dead code.

The configuration parameter `databases.odoocom_apiuser` is removed, as well as the corresponding field in the Settings page.

### [IMP] databases: remove xmlrpc fallback for odoo.com (fixup!)

With this second commit, we remove the dead code concerning the fallback to XMLRPC when calling odoo.com.

### [IMP] databases: use multidb routes to fetch KPIs on SaaS

When synchronizing KPIs from databases in the new Databases application, it takes a long time to make a RPC call to each database in the list.

With this commit, in the case of the SaaS, these calls are grouped by server to a dedicated route that will process the information faster, like the databases dashboard odoo.com/my/databases already does to fetch mail activities summary.

Task-id: [5167731](https://www.odoo.com/odoo/project.task/5167731)

… 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 reproduce**
- Create a first partner (name: "Partner", email: "partner@mail.com", phone: "123").
- Go to the website form of a helpdesk team, and submit a ticket using "Partner@mail.com" as email (notice the different capitalization) and "456" as phone number.

Behavior without this fix: a new partner is created, but the ticket is assigned to the orignal partner ("partner@mail.com") and its phone number is updated.

Behavior after this fix: no partner is created.

**Causes**
- the partner search was case sensitive
- the created partner was not used as the `partner_id` of the ticket as it was added to the params but needs to be in the kwargs passed to `handle_website_form` in order to be found used by `extract_data`. The original partner was found in `_find_or_create_partner` by the call to
`_mail_find_partner_from_emails` (case-insensitive)

Note: this commit also ensures consistency between the partner's company and the ticket's company (same as in `_find_or_create_partner` of `helpdesk.ticket`).
Also, avoid allowing modifying existing partner's phone via this form.

opw-5914064

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

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