Before this commit: When a user in Odoo uses the dialog box to send a message to a WhatsApp number and inserts a line break with "Shift+Enter," it creates a <br> tag. In the WhatsApp module, these tags are stripped, causing the word before and the word after the <br> tag to be joined together without a space or a line break to separate them. How to reproduce: Send a message via the dialog box to a WhatsApp number and insert a line break using Shift+Enter. On the phone, the line break will

Before this commit: When a user in Odoo uses the dialog box to send a message to a WhatsApp number and inserts a line break with "Shift+Enter," it creates a <br> tag. In the WhatsApp module, these tags are stripped, causing the word before and the word after the <br> tag to be joined together without a space or a line break to separate them.

How to reproduce:

Send a message via the dialog box to a WhatsApp number and insert a line break using Shift+Enter.
On the phone, the line break will not be present anymore because the tag <br> is removed with the other tags.

After this commit: the line break is there and the words are not join together anymore.

OPW-4079729

Forward-Port-Of: odoo/enterprise#73727

### Steps to reproduce: - Install 'l10n_es' and switch to Spanish company - Go in Accounting > Tax Report and select the report "Mod 390" - Click on the button to download the BOE - Fill the information in the wizard - Click on generate BOE - An error pops up ### Cause: The report Mod 390 is composed of several sections. The method `dispatch_report_action` is called on the first section instead of the entire report. As the first section has no custom handler, an error is raised when tr

### Steps to reproduce:
- Install 'l10n_es' and switch to Spanish company
- Go in Accounting > Tax Report and select the report "Mod 390"
- Click on the button to download the BOE
- Fill the information in the wizard
- Click on generate BOE
- An error pops up

### Cause:
The report Mod 390 is composed of several sections. The method `dispatch_report_action` is called on the first section instead of the entire report. As the first section has no custom handler, an error is raised when trying to read on it.

When exporting a report with sections, `dispatch_report_action` is called on the first section, it detects that this is a section and calls the same method on the parent report. This commit (https://github.com/odoo/enterprise/commit/8213813e68f02d88934285a44a3413505f6ca187) removed the line getting the options for the parent report call to keep the specific options of each section. Specifically, the "report_id" key in the options is the id of the first section, causing the method to be called on the

### Solution:
Setting the key "report_id" in the options of the parent report.
This way the fix of the commit introducing the bug is still active.

opw-4501376

Forward-Port-Of: odoo/enterprise#78185

If "Unfold All" is not selected and "Group by Account" is, printing the Depreciation Schedule won't print the unfolded lines. Furthermore, if you unfold some lines and then refresh, all the lines are refolded. This behaviour is different than the other reports, where the lines you unfold are printed and remembered during a refresh. The fix is to mark the parent lines generated by `group_by_account` as unfolded if the line is present in `options['unfolded_lines']`. task-4507580 F

If "Unfold All" is not selected and "Group by Account" is,
printing the Depreciation Schedule won't print the unfolded lines.

Furthermore, if you unfold some lines and then refresh, all the lines
are refolded.

This behaviour is different than the other reports, where the lines you
unfold are printed and remembered during a refresh.

The fix is to mark the parent lines generated by `group_by_account` as
unfolded if the line is present in `options['unfolded_lines']`.

task-4507580

Forward-Port-Of: odoo/enterprise#78074

Steps to reproduce: 1. Preview a document without selecting it. 2. Change the folder in the inspector. 3. The document is still in the current folder. 4. All the selected documents will be gone. This commit fix that UI issue, now only the previewed document if not selected will be moved. The preview will also be closed to emphasize the move. Task-4492621 Forward-Port-Of: odoo/enterprise#77762

Steps to reproduce:
  1. Preview a document without selecting it.
  2. Change the folder in the inspector.
  3. The document is still in the current folder.
  4. All the selected documents will be gone.

This commit fix that UI issue, now only the previewed document if not selected will be moved. The preview will also be closed to emphasize the move.

Task-4492621

Forward-Port-Of: odoo/enterprise#77762

- -i helpdesk - create company named in Arabic, Chinese or something - BUG: can't create alias -> can't install helpdesk opw-4420662 Forward-Port-Of: odoo/enterprise#76564

- -i helpdesk
- create company named in Arabic, Chinese or something
- BUG: can't create alias -> can't install helpdesk

opw-4420662

Forward-Port-Of: odoo/enterprise#76564

Problem ---------- With low values of Gross, the PAYE can be negative. The must be always positive or equals to 0 Objective ---------- Make the PAYE computation positive. Check the PAYE computation. Solution ---------- It will be now the maximum between the previous computation and 0. To be always >= 0. Order the Gross Taxable with the sequence number. PAYE computation is correct, check the task for more details. task-4255918 Forward-Port-Of: odoo/enterprise#76189

Problem
----------
With low values of Gross, the PAYE can be negative. The must be always positive or equals to 0

Objective
----------
Make the PAYE computation positive.
Check the PAYE computation.

Solution
----------
It will be now the maximum between the previous computation and 0. To be always >= 0. Order the Gross Taxable with the sequence number.
PAYE computation is correct, check the task for more details.

task-4255918

Forward-Port-Of: odoo/enterprise#76189

When moving a document from a folder to another, the tags are not removed, this leads to wrong behavior, for example when grouping by tags in the destination folder because we have invisible records linked to the documents. With this commit, we clear the `tag_ids` from the vals if there is no `tag_ids` in the write values, this way we don't interfer with eventual workflow rules that might set tags while moving the document. Steps: - With demo data, select the document mail.png in t

When moving a document from a folder to another, the tags are
not removed, this leads to wrong behavior, for example when grouping
by tags in the destination folder because we have invisible records
linked to the documents.

With this commit, we clear the `tag_ids` from the vals if there is no
`tag_ids` in the write values, this way we don't interfer with
eventual workflow rules that might set tags while moving the document.

Steps:

- With demo data, select the document mail.png in the 'Internal' folder
- Change its folder to 'Finance' via the select input on the right side window
- Go to 'Finance' folder, and filter the documents by tag (tag_ids
  contains 'Inbox')
-> The document mail.png appears in the list although there is no tag
   set on it

opw-4347910

Forward-Port-Of: odoo/enterprise#78304
Forward-Port-Of: odoo/enterprise#75001

Switch to XE's API for currency rates: - Replaced web scraping of XE's website with integration to their paid API. - Updated codebase to handle API authentication and responses. - Updated documentation to reflect the use of XE's API instead of web scraping. IAP: https://github.com/odoo/iap-apps/pull/970 task-4461343 Forward-Port-Of: odoo/enterprise#78226 Forward-Port-Of: odoo/enterprise#77517

Switch to XE's API for currency rates:

- Replaced web scraping of XE's website with integration to their paid API.
- Updated codebase to handle API authentication and responses.
- Updated documentation to reflect the use of XE's API instead of web scraping.

IAP: https://github.com/odoo/iap-apps/pull/970

task-4461343

Forward-Port-Of: odoo/enterprise#78226
Forward-Port-Of: odoo/enterprise#77517

Steps to reproduce: 1. Go to appointments 2. Select any appointment with resources. 3. Change from the gantt view to the calendar view. 4. Create a new event from the calendar view with resource_id set. Issue: Since in this form we are using the `resource_id` and not the `appointment_resource_id` the inverse computation from `_inverse_appointment_resource_id_or_capacity` will think that we have removed the linked resource_id from the appointment so we will remove the booking line. So

Steps to reproduce:

1. Go to appointments
2. Select any appointment with resources.
3. Change from the gantt view to the calendar view.
4. Create a new event from the calendar view with resource_id set.

Issue: Since in this form we are using the `resource_id` and not the `appointment_resource_id` the inverse computation from `_inverse_appointment_resource_id_or_capacity` will think that we have removed the linked resource_id from the appointment so we will remove the booking line.

Solution: We might assume that when having only 1 `resource_id`, this one will be the one to be used for the appointment, the `appointment_resource_id` and we should not get rid of the booking line.

opw-4440569

Forward-Port-Of: odoo/enterprise#76653

When opening a new (virtual) 'stock.move' to create a 'stock.move.line' and directly validating the picking afterward, the created 'stock.move.line' was not directly associated to the picking_id. This happens because the virtual record does not have the picking_id because this field is not present on the tree view. One impact of this issue has is that the stock.move.line created doesn't show on the Delivery Slip report. ## HOW TO REPRODUCE https://github.com/odoo/odoo/assets/29302288/5c

When opening a new (virtual) 'stock.move' to create a 'stock.move.line' and directly validating the picking afterward, the created 'stock.move.line' was not directly associated to the picking_id. This happens because the virtual record does not have the picking_id because this field is not present on the tree view.

One impact of this issue has is that the stock.move.line created doesn't show on the Delivery Slip report.

## HOW TO REPRODUCE

https://github.com/odoo/odoo/assets/29302288/5c17e601-4d67-4515-8d5a-286460b9a9cd

- On TODO picking, do the following steps WITHOUT CLICKING ON SAVE
- Operations -> Add a line: (demand 0, quantity 0)
- Click on 'Open Move' button (fa-list icon)
- Popup 'Open: Stock move': Add a line
- Popup 'Add line: <product>': click on 'New'
- Popup 'Create Move Line': click on 'Save & Close'
- Popup 'Open: Stock move': set Quantity = 1, click on 'Save & Close'
- Validate picking -> Create backorder => Check picking move_line_ids = EMPTY

## Solution
Add picking_id field on view_picking_form -> move_ids_without_package tree view (Operations list).

OPW-3974109

Forward-Port-Of: odoo/odoo#171766

### Steps to reproduce: - Create a storable product tracked by lot/serial - Click on "On Hand" - Create a new line with 10 "On Hand Quantity" WITHOUT lot/serial - Go back to the product: The "On Hand" quantity is still at 0. - Click back to the "On Hand": the quantity of the line is back to 0. ### Cause of the issue: When a new line is created and the "On Hand Quantity" is edited from the `view_stock_quant_tree` view, we actually performs a create of the stock.quant followed by a wr

### Steps to reproduce:

- Create a storable product tracked by lot/serial
- Click on "On Hand"
- Create a new line with 10 "On Hand Quantity" WITHOUT lot/serial
- Go back to the product: The "On Hand" quantity is still at 0.
- Click back to the "On Hand": the quantity of the line is back to 0.

### Cause of the issue:

When a new line is created and the "On Hand Quantity" is edited from the `view_stock_quant_tree` view, we actually performs a create of the stock.quant followed by a write on the `inventory_quantity_auto_apply`. At this point the 'quantity' field of the new quant is not set and the `action_apply_inventory` of the `inventory_quantity_auto_apply` is expected to create and validate a move line in order to update our quant quantities here:
https://github.com/odoo/odoo/blob/e041e890b91e5bc515e1827683f073781788f253/addons/stock/models/stock_quant.py#L230-L235 However, this steps will never be performed as we return the call before the `_apply_invetory` because our quant is set without lots: https://github.com/odoo/odoo/blob/e041e890b91e5bc515e1827683f073781788f253/addons/stock/models/stock_quant.py#L447-L449 https://github.com/odoo/odoo/blob/e041e890b91e5bc515e1827683f073781788f253/addons/stock/models/stock_quant.py#L465-L477

### Fix:

Since the return value of the `action_apply_inventory` is only expected to be used in the `view_stock_quant_tree_editable` (Inventory adjustment ) where it is not possible to set the `inventory_quantity_auto_apply` inventory, we skip this return in case the calls has been performed from setting the `inventory_quantity_auto_apply` and proceed with the `_apply_inventory`.

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

Forward-Port-Of: odoo/odoo#194068

Since commit [1], the test "snippets_all_drag_and_drop" is failing randomly on the runbot. This is due to the fact that it is now possible to drop an "inner snippet" next to the "phone number" in the "header". Since the "phone number" is in the middle of the "header" (horizontally), its drop zone overlaps with the one of the "#wrap" during the test. As a result, "inner snippet" is being dropped in the "header" instead of the "#wrap". This happens because the "drag_and_drop" function in the test

Since commit [1], the test "snippets_all_drag_and_drop" is failing randomly on the runbot. This is due to the fact that it is now possible to drop an "inner snippet" next to the "phone number" in the "header". Since the "phone number" is in the middle of the "header" (horizontally), its drop zone overlaps with the one of the "#wrap" during the test. As a result, "inner snippet" is being dropped in the "header" instead of the "#wrap". This happens because the "drag_and_drop" function in the test by default drops at the middle and top of the drop zones.

To avoid this kind of situation, in this commit, we add a step at the beginning of the test to hide the header.

[1]: https://github.com/odoo/odoo/commit/e0c16bb9a90dfb378b75e0de059e71f0aebd84fb

opw-4494945

Forward-Port-Of: odoo/odoo#195768
Forward-Port-Of: odoo/odoo#195554

Description of the issue/feature this PR addresses: I can't reproduce the error in Runbot, but the error is real. Try opening the project settings.   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

Description of the issue/feature this PR addresses:
I can't reproduce the error in Runbot, but the error is real.
Try opening the project settings.
![image](https://github.com/user-attachments/assets/8a36063b-a60e-44ca-b0a8-2d2131b6b193)

![image](https://github.com/user-attachments/assets/13b6362e-8619-4eb1-9174-543831cba61a)

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

Since the class `s_searchbar_input` was translated into Dutch by a translator on Transifex. _{See screenshot of the Website `nl.po` file}↓ <kbd></kbd> It is no longer possible to drop the searchbar block onto a webpage when Odoo's language is set to Dutch. In this PR, we add `t-translation="off"` in the xpath that adds this class to the list of droppable element selectors, so it won't be

Since the class `s_searchbar_input` was translated into Dutch by a
translator on Transifex.
<sub>See screenshot of the Website `nl.po` file </sub>↓
<kbd>![image](https://github.com/user-attachments/assets/053f084b-30cf-42d3-9c13-7387b777b88f)</kbd>

It is no longer possible to drop the searchbar
block onto a webpage when Odoo's language is set to Dutch.

In this PR, we add `t-translation="off"` in the xpath that adds
this class to the list of droppable element selectors, so it won't be
translated anymore. We also do the same for other xpath-ed classes that
don’t have `t-translation="off"`, to prevent the same issue elsewhere.

Since the class is already translated in the existing databases, in
stable versions, we add the class a second time to the list of droppable
element selectors. This second class won't be translated, which will fix
the issue for Dutch users.

[opw-4461785](https://www.odoo.com/web#id=4461785&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form)

-----------
Note: This PR also fix 2 minor bugs:
- The text on the button to install a block overflows when translated into certain languages that make it longer.
<kbd>![image](https://github.com/user-attachments/assets/0532c186-c081-4e95-a853-1873e50005ff)</kbd>
- The `Embed code` block "Click on Edit..." message is not visible on dark background.
<kbd>![image](https://github.com/user-attachments/assets/16510ffb-7a2e-4eaa-b5f7-40f0e9d9a943)</kbd>

Forward-Port-Of: odoo/odoo#195854
Forward-Port-Of: odoo/odoo#193819

Description of the issue/feature this PR addresses: Fix a traceback with the partner merging wizard. Current behavior before PR: Currently, the partner merging wizard doesn't support fields of type `reference`, because this type of field is never used by Odoo on model `res.partner`. This will never happend in native Odoo, but some external addons can trigger this traceback. Desired behavior after PR is merged: The traceback is fixed and reference fields are treated like any other

Description of the issue/feature this PR addresses:

Fix a traceback with the partner merging wizard.

Current behavior before PR:

Currently, the partner merging wizard doesn't support fields of type `reference`, because this type of field is never used by Odoo on model `res.partner`.
This will never happend in native Odoo, but some external addons can trigger this traceback.

Desired behavior after PR is merged:

The traceback is fixed and reference fields are treated like any others field types.

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

Forward-Port-Of: odoo/odoo#195432

Some labels in the website editor's sidebar were not translatable, while all the others were. In this commit we make the following parts translatable: - The header of the "Field" options - The "Custom Text" new field name - The "Existing field" header in the selection list of existing field - "Option", "Radio", "Checkbox", and "List" for list-type fields [opw-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/odoo#195818 Forward-Port-Of: odoo/odoo#194014

Some labels in the website editor's sidebar were not translatable, while all the others were.

In this commit we make the following parts translatable:
- The header of the "Field" options
- The "Custom Text" new field name
- The "Existing field" header in the selection list of existing field
- "Option", "Radio", "Checkbox", and "List" for list-type fields

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

Forward-Port-Of: odoo/odoo#195818
Forward-Port-Of: odoo/odoo#194014

[FIX] l10n_hu_edi: price include tax Price unit was not properly calculated: * Didn't remove the discount. * Didn't take into account price included taxes. We also removed a test use case that didn't make sense. Task-id: 4236755 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190095

[FIX] l10n_hu_edi: price include tax

Price unit was not properly calculated:
* Didn't remove the discount.
* Didn't take into account price included taxes.

We also removed a test use case that didn't make sense.

Task-id: 4236755

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

Forward-Port-Of: odoo/odoo#190095

At two different places, we try to determine if the value of an html field is empty. To do so, we create a node on the fly and set its innerHTML to that value. Then, we check if the element has a non-empty innerText. However, this doesn't work as expected if the given value is a text instead of a markuped html. This commit fixes the issue. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have s

At two different places, we try to determine if the value of an html field is empty. To do so, we create a node on the fly and set its innerHTML to that value. Then, we check if the element has a non-empty innerText. However, this doesn't work as expected if the given value is a text instead of a markuped html. This commit fixes the issue.

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#196036
Forward-Port-Of: odoo/odoo#195909

## Versions: 17.0+ No fix needed in 16.0 as the discount was not displayed this way. ## Issue: Discount descriptions contain long string floats while it should be truncated for human reading. ## Steps to reproduce: - Activate `Discounts` through settings; - Create a new sale order for any client with at least 1 product; - Click the `Discount` button on the form; - Apply a 7% `Global Discount`; - Read the `Discount` product's description. ## Cause: Some numbers cannot be represe

## Versions:
17.0+
No fix needed in 16.0 as the discount was not displayed this way.

## Issue:
Discount descriptions contain long string floats while it should be truncated for human reading.

## Steps to reproduce:
- Activate `Discounts` through settings;
- Create a new sale order for any client with at least 1 product;
- Click the `Discount` button on the form;
- Apply a 7% `Global Discount`;
- Read the `Discount` product's description.

## Cause:
Some numbers cannot be represented correctly in Python (including 7, 3.3 etc.).

opw-4485316

Forward-Port-Of: odoo/odoo#195328

After commit ddda5d4a2623d03699d5cb6860d5c984807b6e3d public users were allowed to tokenize their payments with the exception of donation the tokenize field was forced to be False. However Stripe threw an error when the received intent was different than the one on the frontend. Fix: Hide option to tokenize for unlogged in users for donations. opw-4389881 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195001

After commit ddda5d4a2623d03699d5cb6860d5c984807b6e3d public users were allowed to tokenize their payments with the exception of donation the tokenize field was forced to be False.
However Stripe threw an error when the received intent was different than the one on the frontend.

Fix:
Hide option to tokenize for unlogged in users for donations.

opw-4389881



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

Forward-Port-Of: odoo/odoo#195001

**Current behavior:** With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation: Making a purchase order in some foreign currency, having some exchange rate for today, receiving the product, then dating the vendor bill to some future date with a different exchange rate will result in exchange difference journal entries when the bill is posted. **Expected behavior:** We shouldn't see exchange difference entries, as there are pending corrective valuation entr

**Current behavior:**
With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation:

Making a purchase order in some foreign currency, having some exchange rate for today, receiving the product, then dating the vendor bill to some future date with a different exchange rate will result in exchange difference journal entries when the bill is posted.

**Expected behavior:**
We shouldn't see exchange difference entries, as there are pending corrective valuation entries which have simply not been posted yet.

Reconciliation should be deferred until these moves are no longer in draft.

**Steps to reproduce:**
1. Activate another currency, define some rate for today and another (different) rate for tomorrow

2. Create a product with FIFO and real-time costing & valuation

3. Create an initial purchase for the product, receive then bill normally

4. Create another purchase order and receive the product

5. Create the invoice, set the invoie date for tomorrow

6. Post the invoice -> Open the `Exchange Difference` journal to see the entries which should not have been generated

**Cause of the issue:**
After creating the AMLs which represent the difference in reception/bill unit price of the product, they are caught here: https://github.com/odoo/odoo/blob/971400771a31c05641a8672f6b1d85afaa9c4a19/addons/account/models/account_move.py#L3575 and designated as future moves, not to be posted at this time.

At the end of the `_post()` stack: https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/addons/stock_account/models/account_move.py#L229 where there would normally be some `correction_amls`, they weren't created here because the AMLs for the price diff were not posted- so the price diff entry is generated.

**Fix:**
Wait for pending (`state == 'draft'`) AMLs that are part of some `AccountMove`'s valuation to be no longer in draft before allowing reconciliation with a currency exchange difference.

opw-4266652

Forward-Port-Of: odoo/odoo#195073
Forward-Port-Of: odoo/odoo#193971

On a server with low activity, the log is bloated with messages containing `[...] Closed 0 connections`. It is only useful to know if a connection was closed, so we skip logging otherwise. 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#196012

On a server with low activity, the log is bloated with messages containing `[...] Closed 0 connections`.

It is only useful to know if a connection was closed, so we skip logging otherwise.

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

In case of manipulations with new records, ensure the computation of bank_partner_id field is well recomputed if company is changed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195962

In case of manipulations with new records, ensure the computation of bank_partner_id field is well recomputed if company is changed.



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

Forward-Port-Of: odoo/odoo#195962