For Jordan E-invoicing, the reason for return of a credit note is mandatory in the XML. Before this commit, if the return reason (`ref`) was empty in a credit note, an error from JoFotara pops up during validation. This commit makes sure the user is notified of missing `ref` before submitting the XML to JoFotara. task-4869028 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215542

For Jordan E-invoicing, the reason for return of a credit note is mandatory in the XML.

Before this commit, if the return reason (`ref`) was empty in a credit note, an error from JoFotara pops up during validation.
This commit makes sure the user is notified of missing `ref` before submitting the XML to JoFotara.

task-4869028



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

Forward-Port-Of: odoo/odoo#215542

Before this commit, when plain text (e.g., "Some tax") was imported from a CSV file into the HTML field `description`, the system wrapped it in a `<p>` tag during normalization via `html_normalize`, since plain text is not valid HTML. After this commit, we add a check before record creation: - If the value is plain text without any HTML, we wrap it in a `<div>` to make it valid HTML. - If it already contains HTML, we leave it untouched. This avoids unintended `<p>` wrapping by `html_n

Before this commit, when plain text (e.g., "Some tax") was imported from a CSV
file into the HTML field `description`, the system wrapped it in a `<p>` tag
during normalization via `html_normalize`, since plain text is not valid HTML.

After this commit, we add a check before record creation:
- If the value is plain text without any HTML, we wrap it in a `<div>` to make it
valid HTML.
- If it already contains HTML, we leave it untouched.

This avoids unintended `<p>` wrapping by `html_normalize`.

Note: if content is wrapped in a `<div>`, `html_normalize` will strip it out.
This ensures consistent HTML formatting for the description field during
create/write operations and prevents unexpected automatic wrapping by
the system.

task-4862728

Forward-Port-Of: odoo/odoo#215469
Forward-Port-Of: odoo/odoo#214113

<b>Steps to reproduce :</b> 1) Install the Purchase module 2) Create and confirm a Purchase Order with a product and quantity 3) From the Purchase Order, open the product and archive it <b>Issue:</b> Before archiving the product, the `Purchased` smart button correctly displays the total purchased quantity. However, after archiving the product template, this smart button displays `0.0`, even though purchases exist. Additionally, clicking the button opens a blank purchase order

<b>Steps to reproduce :</b>

1) Install the Purchase module
2) Create and confirm a Purchase Order with a product and quantity 
3) From the Purchase Order, open the product and archive it

<b>Issue:</b>
Before archiving the product, the `Purchased` smart button correctly displays 
the total purchased quantity.

However, after archiving the product template, this smart button displays `0.0`, 
even though purchases exist.

Additionally, clicking the button opens a blank purchase order line view instead 
of showing related records if the product is archived.

<b>Cause:-</b>
Archiving a product template sets active=False on the template and its variants. 
The computed field `purchased_product_qty` relies on the variants to calculate the total. 
Because the variants are inactive post-archival, the compute method sees no records, 
resulting in a displayed value of 0.0.

Similarly, the smart button action uses the active variants in its domain, 
so it fails to find any related purchase order lines.

<b>Solution:</b>

The context is now explicitly set with active_test=False when computing 
the purchased_product_qty and when generating the domain for the smart button action.

This ensures that even inactive variants are included in the calculation and the view logic, 
preserving the correct purchased quantity and showing the relevant purchase lines after archival.

opw-4781578

Forward-Port-Of: odoo/odoo#213484
Forward-Port-Of: odoo/odoo#209955

In lxml from 4.6.0 to 5.2.0: [1] introduces an issue where "style" tags will always be cleaned if there is more than one data url inside it (the regex is too greedy) in 4.6.0 [2] fixes the issue in the lxml_html_clean module version 0.1.1 which is the dependency that replaces lxml.html.clean from lxml 5.2.0 and up We apply the fix from [2] in odoo directly. With many checks to ensure we don't override any potential deviation from the original regex. The issue only appear from 18.

In lxml from 4.6.0 to 5.2.0:

[1] introduces an issue where "style" tags will always be cleaned if
there is more than one data url inside it (the regex is too greedy) in
4.6.0

[2] fixes the issue in the lxml_html_clean module version 0.1.1 which is
the dependency that replaces lxml.html.clean from lxml 5.2.0 and up

We apply the fix from [2] in odoo directly. With many checks to ensure
we don't override any potential deviation from the original regex.

The issue only appear from 18.0 onwards, as that's when "email_outgoing"
sanitation started being applied [3]

[1]: https://github.com/lxml/lxml/commit/73778681f14359fe6d16644e69aaca276eba525a
[2]: https://github.com/fedora-python/lxml_html_clean/commit/97402b5f6e94583c8f1c3f6070ef19ce1df90da8
[3]: https://github.com/odoo/odoo/commit/24731938f75358fd3c72b91465b72ab80d62d208

runbot-105525

Forward-Port-Of: odoo/odoo#213393

When there is invalid characters in the field, sending may lead to unexpected behaviour. normalize and keep only the first one Task-id: 4894083 Forward-Port-Of: odoo/odoo#215784 Forward-Port-Of: odoo/odoo#215580

When there is invalid characters in the field, sending may lead to unexpected behaviour.
normalize and keep only the first one

Task-id: 4894083

Forward-Port-Of: odoo/odoo#215784
Forward-Port-Of: odoo/odoo#215580

Allow batch write on model using the `HtmlFieldHistory` mixin. task-4852381 task-4731389 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215010 Forward-Port-Of: odoo/odoo#213116

Allow batch write on model using the `HtmlFieldHistory` mixin.

task-4852381
task-4731389


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

Forward-Port-Of: odoo/odoo#215010
Forward-Port-Of: odoo/odoo#213116

In this commit, we add a step to ensure that the popover comparator is visible in the DOM before moving on to the next check step. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215810

In this commit, we add a step to ensure that the popover comparator is visible in the DOM before moving on to the next check step.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#215810

The "Alert Date Reached" activity was not correctly assigning the activity to the "Default User" specified in the `mail.activity.type` settings. This did not align with user expectations that the activity type's default user should be primarily considered. To reproduce the issue: 1. Configure a "Default User" (e.g., User A) for the Alert Date Reached activity type. 2. Create a product tracked by lots. Ensure its "Responsible User" (on the product's Inventory tab) is either not set or is a d

The "Alert Date Reached" activity was not correctly assigning the activity to the "Default User" specified in the `mail.activity.type` settings. This did not align with user expectations that the activity type's default user should be primarily considered.

To reproduce the issue:
1. Configure a "Default User" (e.g., User A) for the Alert Date Reached activity type.
2. Create a product tracked by lots. Ensure its "Responsible User" (on the product's Inventory tab) is either not set or is a different user (e.g., User B).
3. Receive the product with a lot number and set its alert date to be in the past.
4. Trigger the scheduler for checking lot expirations (via Operations > Run Scheduler).
5. The generated "Alert Date Reached" activity would be assigned to User B (if set) or the superuser, incorrectly ignoring User A.

This commit rectifies this behavior by modifying the user assignment logic for these lot expiry alerts. The new priority for determining the assignee is:
1. The "Default User" configured on the "Alert Date Reached" activity type.
2. If no default user is set on the activity type, then the "Responsible User" defined on the related product.
3. If neither is set, the activity is assigned to SUPERUSER.

[opw-4640027](https://www.odoo.com/odoo/project.task/4640027)

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

Forward-Port-Of: odoo/odoo#214165
Forward-Port-Of: odoo/odoo#212154

This commit adds the the unit e.g. 'kg' to each orderline next to the quantity. The reason for this change was to satisfy the requirements of the LNE to allow Odoo to be certified for weighing scales in the EU. task-4869128 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214430 Forward-Port-Of: odoo/odoo#214335

This commit adds the the unit e.g. 'kg' to each orderline next to the quantity. The reason for this change was to satisfy the requirements of the LNE to allow Odoo to be certified for weighing scales in the EU.

task-4869128

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

Forward-Port-Of: odoo/odoo#214430
Forward-Port-Of: odoo/odoo#214335

This PR https://github.com/odoo/odoo/pull/214829 caused a Runbot error. The test introduced in the PR is failing because it compared a list converted from a set to a hardcoded list, leading to inconsistent order. Using a sorted list when converting the set fixes the issue. Forward-Port-Of: odoo/odoo#215773

This PR https://github.com/odoo/odoo/pull/214829 caused a Runbot error.
The test introduced in the PR is failing because it compared a list
converted from a set to a hardcoded list, leading to inconsistent order.

Using a sorted list when converting the set fixes the issue.

Forward-Port-Of: odoo/odoo#215773

To adapt to the merge of `hw_drivers` and `hw_posbox_homepage` into `iot_drivers`, we need to update the `odoo.conf` file to change the modules to load. Task: 4860513 Forward-Port-Of: odoo/odoo#215725 Forward-Port-Of: odoo/odoo#215536

To adapt to the merge of `hw_drivers` and `hw_posbox_homepage` into `iot_drivers`, we need to update the `odoo.conf` file to change the modules to load.

Task: 4860513

Forward-Port-Of: odoo/odoo#215725
Forward-Port-Of: odoo/odoo#215536

The `s_numbers_charts` snippet had two main issues: - The progress bar within `s_numbers_charts` visually appeared as 45% on initial rendering, despite its actual configured value being 25%. This was due to a mismatch between its `aria-valuenow` attribute and its style `width` property. The display would correct itself when the user manually changed the value. - A crash would occur when attempting to select the "Label" option after dropping the `s_numbers_charts` snippet. This happe

The `s_numbers_charts` snippet had two main issues:
- The progress bar within `s_numbers_charts` visually appeared as 45% on
  initial rendering, despite its actual configured value being 25%. This
was due to a mismatch between its `aria-valuenow` attribute and its
style `width` property. The display would correct itself when the user
manually changed the value.

- A crash would occur when attempting to select the "Label" option after
  dropping the `s_numbers_charts` snippet. This happened because
`s_progress_bar_text` was forgotten during the initial implementation of
`s_numbers_charts` [1].

This commit addresses these problems by:
- Adding the missing `s_progress_bar_text` to the `s_numbers_charts` template.
- Including `s_progress_bar_text` in `_computeSnippetTemplates` to
  ensure that existing databases also receive this fix, as snippets are
stored in the database.
- Adding a check in the `progress` option to prevent the aforementioned crash.

Steps to reproduce the crash:
- Drop the `s_numbers_charts` snippet.
- Click on a progress bar within the snippet.
- Select the option `Label`.
- Hover over "Hide" without any other prior interactions.
- A crash will occur.

[1]: https://github.com/odoo/odoo/commit/6c94fd66c1db75d74588ce670fb6cf1e960cf8bd

Forward-Port-Of: odoo/odoo#215834
Forward-Port-Of: odoo/odoo#214318

Before this commit, several invisible fields were present in the views, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed. The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031 This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views. We will removes the unnecessary invisible fields in master. --- I co

Before this commit, several invisible fields were present in the views, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed.

The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031

This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views.

We will removes the unnecessary invisible fields in master.



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

Forward-Port-Of: odoo/odoo#215675
Forward-Port-Of: odoo/odoo#206026

Currently, when a loyalty program has expired, loyalty card are still getting created even though points are not granted. Steps to reproduce: ------------------- * Create a loyatly program and make it sot that is has already expired * Open pos and make an order selecting any customer * Go to the backend and check the loyalty program > Observation: 1 card has been created with 0 points Why the fix: ------------ Not loading the expired programs prevent the creation of loyalty cards.

Currently, when a loyalty program has expired, loyalty card are still getting created even though points are not granted.

Steps to reproduce:
-------------------
* Create a loyatly program and make it sot that is has already expired
* Open pos and make an order selecting any customer
* Go to the backend and check the loyalty program
> Observation: 1 card has been created with 0 points

Why the fix:
------------
Not loading the expired programs prevent the creation of loyalty cards.

Using the same logic as module `sale_loyalty`
https://github.com/odoo-dev/odoo/blob/5acb89b8ba9be0e18bca65e26c03f47199fcfb4b/addons/sale_loyalty/models/sale_order.py#L461-L465

opw-4671522

Forward-Port-Of: odoo/odoo#208701
Forward-Port-Of: odoo/odoo#208134

Problems: The error message for unbalanced journal entries in the "Miscellaneous Operations" journal was unnecessarily complex and misleading. It suggested setting a default account on the journal to automatically balance entries, but this auto-balancing was intended only for lines with taxes. Furthermore, the method _get_automatic_balancing_account in account.move was ignoring any default account set on the journal itself when auto-balancing because of taxes. It was instead always taking th

Problems:
The error message for unbalanced journal entries in the "Miscellaneous Operations" journal was unnecessarily complex and misleading. It suggested setting a default account on the journal to automatically balance entries, but this auto-balancing was intended only for lines with taxes.

Furthermore, the method _get_automatic_balancing_account in account.move was ignoring any default account set on the journal itself when auto-balancing because of taxes. It was instead always taking the company suspense account.

How to reproduce the issue:

- Add a default account to the miscellaneous journal.
- Create a journal entry manually, and add a line with any account of 100 debit.
- Attempt to save.

Finally, this commit also set the account_id of new account move lines to the default account id of the journal if it exists when creating a journal entry.

enterprise pr: https://github.com/odoo/enterprise/pull/86987

opw-4751270



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

Forward-Port-Of: odoo/odoo#215393
Forward-Port-Of: odoo/odoo#211443

Steps to reproduce: 1. Set company warehouse to two-step manufacturing. 2. Create products: X, A, B, C. 3. Add on-hand quantities: A = 10, C = 5. 4. Create a BOM for X with A and B as components. 5. Create and confirm a MO for X in the two-step warehouse. 6. Check product B's forecast report → shows -1. 7. Add a reordering rule for B → forecast shows -1. 8. Edit X’s BOM: remove B and add C instead. 9. Update the MO using the `update_bom` button. 10. Check MO components. 11. Check WH/P

Steps to reproduce:
1. Set company warehouse to two-step manufacturing.
2. Create products: X, A, B, C.
3. Add on-hand quantities: A = 10, C = 5.
4. Create a BOM for X with A and B as components.
5. Create and confirm a MO for X in the two-step warehouse.
6. Check product B's forecast report → shows -1.
7. Add a reordering rule for B → forecast shows -1.
8. Edit X’s BOM: remove B and add C instead.
9. Update the MO using the `update_bom` button.
10. Check MO components.
11. Check WH/Preprod transfer → B is still there.
12. Re-check steps 6 and 7.

**Issue**:
In two-step manufacturing, two stock moves are created:
- move1: WH/Stock → WH/Preprod
- move2: WH/Preprod → Virtual/Production

The forecast report uses the company warehouse (WH) as the
location domain and includes move2. It calculates:
  forecast = qty_available - demand = 0 - 1 = -1

The reordering rule uses WH/Stock (its default location) and
includes move1, resulting in the same forecast: -1.

After updating the BOM to remove B:
- move2 is deleted correctly.
- move1 remains on the pre-production transfer.

This causes an inconsistency:
- Forecast report (based on move2) → shows 0
- Reordering rule (based on move1) → still shows -1

We set the product_uom_qty to 0 of the prepoduction moves
so procurement runs with negative qty move and it is merged
with the existing ones in the preproduction picking.
This will make the moves in the preprod picking be 0 and not
deleted to avoid deleting manually added moves from the client
in the preproduction picking.

**Limitation**
The current setup will update the pre_prod_pick moves with
0 demand, but for the post_prod_pick moves there is no pull rule
that will trigger a procurement with -ve old demand to update
the post_prod_pick move leaving it not updated to the bom changes.

This will not be an issue in 18.0+ because of changing to push rules
as the post_prod_pick will not be there unless the MO is done, so
BoM updates will not be needed to be reflected.

opw-4746230

Forward-Port-Of: odoo/odoo#215693
Forward-Port-Of: odoo/odoo#209642

@moduon MT-10568 MT-10569 MT-10567 MT-10566 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214739

@moduon MT-10568 MT-10569 MT-10567 MT-10566

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#214739

<b>Steps to reproduce:</b> 1. Go to Sales > Configuration > Product Categories 2. Select All / Saleable, and set Costing Method to FIFO 3. Go to Products > New 4. Fill in Name , set Track Inventory True and add Cost, then save the product 5. Change the Category to All / Saleable 6. Navigate to Attributes & Variants, add attribute Leg, and add values Steel and Aluminium <b>Issue :</b> - When modifying a product template with FIFO costing by adding multiple attributes, the system may d

<b>Steps to reproduce:</b>
1. Go to Sales > Configuration > Product Categories 
2. Select All / Saleable, and set Costing Method to FIFO 
3. Go to Products > New
4. Fill in Name , set Track Inventory True and add Cost, then save the product
5. Change the Category to All / Saleable
6. Navigate to Attributes & Variants, add attribute Leg, and add values Steel and Aluminium

<b>Issue :</b>
- When modifying a product template with FIFO costing by adding multiple attributes, the system may delete and recreate product variants. This causes "missing record" error during stock valuation replenishment, as the code tries to access  deleted product variants.

<b>Solution :</b>
- After calling super().write(vals), the original products recordset may contain deleted records due to variant regeneration.
  A check was added to verify if the variants still exist, If not, then continues.

<b>opw-4741530</b>

Forward-Port-Of: odoo/odoo#215394
Forward-Port-Of: odoo/odoo#209513

Prior to this commit, when a sale order was created with some service products configured to generate projects at SO confirmation, we would generate an analytic account per project instead of just one for all the generated projects. As a result, we would get redundant analytic accounts, which is not desirable. This is because we were creating the new projects without specifying the analytic account that would be set to it (because we would assume that the project would be first created withou

Prior to this commit, when a sale order was created with some service products configured to generate projects at SO confirmation, we would generate an analytic account per project instead of just one for all the generated projects. As a result, we would get redundant analytic accounts, which is not desirable.

This is because we were creating the new projects without specifying the analytic account that would be set to it (because we would assume that the project would be first created without AA, then we would populate it later). The issue is that if `hr_timesheet` is installed, every new project is by default timesheetable, so that it generates an AA automatically at creation of the project (see `create()` method of `hr_timesheet`) To mitigate that, we now specify the analytic account to be used when creating the projects that have to be generated from `_timesheet_create_project()`.

version-18.0
task-4854817

Forward-Port-Of: odoo/odoo#215616

Before this commit, there could be a race condition where the peer connection gets closed while an offer is being negotiated. This could happen for example when offers are being sent to establish a p2p connection and the fallback to the SFU kicks in and clears the connection. This would lead to a traceback but no functional issue. Forward-Port-Of: odoo/odoo#215995

Before this commit, there could be a race condition where the peer connection gets closed while an offer is being negotiated.

This could happen for example when offers are being sent to establish a p2p connection and the fallback to the SFU kicks in and clears the connection.

This would lead to a traceback but no functional issue.

Forward-Port-Of: odoo/odoo#215995

When printing a report with an IoT Box, we send a longpolling request from the client. The UI was not blocking doing so, so a fast user could leave the view before the request ended, resulting in a traceback: Component is destroyed. opw-4812421 Forward-Port-Of: odoo/enterprise#88566 Forward-Port-Of: odoo/enterprise#88493

When printing a report with an IoT Box, we send a longpolling request from the client. The UI was not blocking doing so, so a fast user could leave the view before the request ended, resulting in a traceback: Component is destroyed.

opw-4812421

Forward-Port-Of: odoo/enterprise#88566
Forward-Port-Of: odoo/enterprise#88493

Before this commit, when one tries to upload a file to a document request for the first time it does nothing. This is caused by an async memoize call which causes the file to be cleared between the memoize rpc call and the file processing after that call... After that first call the user can upload a new file without issue but it's still annoying. This commit fix this issue by storing the file in a variable before doing the memoize rpc call. Task-4778429 Forward-Port-Of: odoo/enterpri

Before this commit, when one tries to upload a file to a document request for the first time it does nothing. 
This is caused by an async memoize call which causes the file to be cleared between the memoize rpc call and the file processing after that call... After that first call the user can upload a new file without issue but it's still annoying.
This commit fix this issue by storing the file in a variable before doing the memoize rpc call.
    
Task-4778429

Forward-Port-Of: odoo/enterprise#86002

This commit removes the default account set in the setup of test_payroll_expense. Because of 67b5fc47ca4aa1abb60f198a87d7784ef400f796 the filter in get_all_amls_to_be_reconciled would get multiples amls instead of only one. community pr: https://github.com/odoo/odoo/pull/211443 opw-4751270 Forward-Port-Of: odoo/enterprise#86987

This commit removes the default account set in the setup of test_payroll_expense. Because of 67b5fc47ca4aa1abb60f198a87d7784ef400f796 the filter in get_all_amls_to_be_reconciled would get multiples amls instead of only one.

community pr: https://github.com/odoo/odoo/pull/211443

opw-4751270

Forward-Port-Of: odoo/enterprise#86987

## Issue When there are heavy (or a lot of) documents in a folder, the user cannot archive this folder as it would trigger a `MemoryError`. ### Analysis The `write` override could unnecessarily fetch the `datas` field (binary file content). This happened because a condition checking `record.datas` was evaluated before checking if `datas` or `url` was actually present in the values being written. This could lead to slowness when e.g. archiving/unarchiving documents, as the ORM would fetch t

## Issue
When there are heavy (or a lot of) documents in a folder, the user cannot archive this folder as it would trigger a `MemoryError`.

### Analysis
The `write` override could unnecessarily fetch the `datas` field (binary file content).
This happened because a condition checking `record.datas` was evaluated before checking if `datas` or `url` was actually present in the values being written. This could lead to slowness when e.g. archiving/unarchiving documents, as the ORM would fetch the binary content even when it was not needed.

## Solution
We leverage Python's boolean short-circuiting to ensure that this behavior is avoided.

### Benchmarks
Profiling peak memory consumption when moving 8 documents (66 Mb each) to the trash:
| Before  | After  | % |
|------------|------------| --- |
|  1.3 GiB | 96 Mb  |  - ~93% |



Query count when unlinking account.move (using Runbot data):
| Before  | After  |
|------------|------------|
|  66 | 72  |

(we may avoid these additional queries by prefetching the fields beforehand, let me know your thoughts)

```
[0.564 ms] query: SELECT "ir_attachment"."id", "ir_attachment"."name", "ir_attachment"."description", "ir_attachment"."res_model", "ir_attachment"."res_field", "ir_attachment"."res_id", "ir_attachment"."company_id", "ir_attachment"."type", "ir_attachment"."url", "ir_attachment"."public", "ir_attachment"."access_token", "ir_attachment"."store_fname", "ir_attachment"."file_size", "ir_attachment"."checksum", "ir_attachment"."mimetype", "ir_attachment"."create_uid", "ir_attachment"."create_date", "ir_attachment"."write_uid", "ir_attachment"."write_date", "ir_attachment"."original_id", "ir_attachment"."key", "ir_attachment"."website_id", "ir_attachment"."theme_template_id" FROM "ir_attachment" WHERE "ir_attachment"."id" IN (3398) 

[0.713 ms] query:  UPDATE "ir_attachment"
SET "res_id" = "__tmp"."res_id"::int4, "res_model" = "__tmp"."res_model"::VARCHAR, "write_date" = "__tmp"."write_date"::timestamp, "write_uid" = "__tmp"."write_uid"::int4
FROM (VALUES (3398, 117, 'documents.document', '2025-06-17T15:24:12.867699'::timestamp, 22)) AS "__tmp"("id", "res_id", "res_model", "write_date", "write_uid")
WHERE "ir_attachment"."id" = "__tmp"."id"
                 
[0.305 ms] query: SELECT "ir_attachment"."id", "ir_attachment"."res_model", "ir_attachment"."res_id", "ir_attachment"."res_field", "ir_attachment"."public", "ir_attachment"."create_uid" FROM "ir_attachment" WHERE ("ir_attachment"."id" IN (3397)) 

[0.666 ms] query: SELECT "account_move"."id" FROM "account_move" WHERE ("account_move"."id" IN (255)) AND ("account_move"."company_id" IN (10)) ORDER BY "account_move"."date" DESC , "account_move"."name" DESC , "account_move"."invoice_date" DESC , "account_move"."id" DESC  

[0.436 ms] query: SELECT "ir_attachment"."id", "ir_attachment"."name", "ir_attachment"."description", "ir_attachment"."res_model", "ir_attachment"."res_field", "ir_attachment"."res_id", "ir_attachment"."company_id", "ir_attachment"."type", "ir_attachment"."url", "ir_attachment"."public", "ir_attachment"."access_token", "ir_attachment"."store_fname", "ir_attachment"."file_size", "ir_attachment"."checksum", "ir_attachment"."mimetype", "ir_attachment"."create_uid", "ir_attachment"."create_date", "ir_attachment"."write_uid", "ir_attachment"."write_date", "ir_attachment"."original_id", "ir_attachment"."key", "ir_attachment"."website_id", "ir_attachment"."theme_template_id" FROM "ir_attachment" WHERE "ir_attachment"."id" IN (3397) 

[0.436 ms] query: SELECT "documents_document"."id", "documents_document"."attachment_id", "documents_document"."active" FROM "documents_document" WHERE ("documents_document"."attachment_id" IN (3397)) ORDER BY "documents_document"."id" DESC  
```

### References
opw-4552436
Memory flamegraphs available on the ticket

Forward-Port-Of: odoo/enterprise#85020

When generating the German tax report, field Kz83 was included in the XML even when the value was 0.00. This caused the exported file to be rejected by the ELSTER platform. This fix removes Kz83 from the XML when its value is null or zero. The ELSTER platform automatically calculates this field if it's missing. source: https://help.deltek.com/product/maconomy/documentation/BPMReporting/CountryReports/Appendix_Germany.html opw-4783544 Forward-Port-Of: odoo/enterprise#86978

When generating the German tax report, field Kz83 was included in the XML even when the value was 0.00. This caused the exported file to be rejected by the ELSTER platform.

This fix removes Kz83 from the XML when its value is null or zero. The ELSTER platform automatically calculates this field if it's missing.

source: https://help.deltek.com/product/maconomy/documentation/BPMReporting/CountryReports/Appendix_Germany.html

opw-4783544

Forward-Port-Of: odoo/enterprise#86978

This commit solves the following bugs in Norwegian saft as per customer feedback: 1. Removed the StandardAccountID 2. Added the CreditAmount tag value to the XML file if the both debit and credit values is 0 for an entry The latter point in needed because the SAF-T XML validator expects CreditAmount/DebitAmount tag even if the entry is empty. This case may happen if, for example, we have an exchange rate entry = $0.000001. Since the journal entry is approximating to only 2 decimal places,

This commit solves the following bugs in Norwegian saft as per customer feedback:
1. Removed the StandardAccountID
2. Added the CreditAmount tag value to the XML file if the both debit and credit values is 0 for an entry

The latter point in needed because the SAF-T XML validator expects CreditAmount/DebitAmount tag even if the entry is empty.
This case may happen if, for example, we have an exchange rate entry = $0.000001.
Since the journal entry is approximating to only 2 decimal places, the amounts on the entry end up being 0s.

task-4714764

Forward-Port-Of: odoo/enterprise#88580
Forward-Port-Of: odoo/enterprise#83963

Before this commit, several invisible fields were present in the views, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed. The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031 This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views. We will removes the unnecessary invisible fields in master. Forward-Port-Of

Before this commit, several invisible fields were present in the views, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed.

The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031

This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views.

We will removes the unnecessary invisible fields in master.

Forward-Port-Of: odoo/enterprise#88405
Forward-Port-Of: odoo/enterprise#83421

Before this commit, we had the capability to view the current scale checksum by visiting `/scale_checksum`, but no way to automatically flag to the user if it had changed. After this commit, we keep track of the expected checksum and compare it to the current checksum. If they differ, the POS is no longer certified and we show an error to the user. task-4873162 Forward-Port-Of: odoo/enterprise#87785 Forward-Port-Of: odoo/enterprise#87726

Before this commit, we had the capability to view the current scale checksum by visiting `/scale_checksum`, but no way to automatically flag to the user if it had changed.

After this commit, we keep track of the expected checksum and compare it to the current checksum. If they differ, the POS is no longer certified and we show an error to the user.

task-4873162

Forward-Port-Of: odoo/enterprise#87785
Forward-Port-Of: odoo/enterprise#87726

This commit will change the condition of display of the coda_split_transactions allowing users to choose whether transactions are imported individually or in batch. opw-4873108 Forward-Port-Of: odoo/enterprise#88370

This commit will change the condition of display of the coda_split_transactions allowing users to choose whether transactions are imported individually or in batch.

opw-4873108

Forward-Port-Of: odoo/enterprise#88370

**Error:** `ValueError: Wrong value for whatsapp.template.lang_code: 'es_CO'` **Before:** Some language codes that are officially supported by WhatsApp were missing from the module's language list, leads to an error during template synchronization. **After:** This commit adds missing language codes, which are supported by WhatsApp to prevent errors during synchronization. Reference: https://developers.facebook.com/docs/whatsapp/business-management-api/message-templates/supported-la

**Error:**
`ValueError: Wrong value for whatsapp.template.lang_code: 'es_CO'`

**Before:**
Some language codes that are officially supported by WhatsApp were missing from
the module's language list, leads to an error during template synchronization.

**After:**
This commit adds missing language codes, which are supported by WhatsApp
to prevent errors during synchronization.

Reference: https://developers.facebook.com/docs/whatsapp/business-management-api/message-templates/supported-languages

Sentry – 6704097351

Forward-Port-Of: odoo/enterprise#88329

when clicking the next button in the pager of the tour, it was causing issues with the report editor not being ready yet with the updated page. so added a delay after clicking n next button in the pager of the tour to avoid issues with the report editor not being ready with the updated page. build_error-163405 Forward-Port-Of: odoo/enterprise#87302

when clicking the next button in the pager of the tour, it was causing issues with the report editor not being ready yet with the updated page.

so added a delay after clicking n next button in the pager of the tour to avoid issues with the report editor not being ready with the updated page.

build_error-163405

Forward-Port-Of: odoo/enterprise#87302